@TheSlash

Well, first is what "program" should I use for compiling, in the SDK:gcc/bin directory is there a lot of files, and what's the difference between the "g++" and "ppc-amigaos-g++"?

If you are on aos4 , then just use gcc/g++ (that just symlinks to ppc-amigaos-g++ and ppc-amigaos-gcc). But if you on crosscompiler, then you should of course use ppc-amigaos-g++ and ppc-amigaos-gcc , because on crosscompiler setup plain gcc/g++ will create a host-system bins, but not target (aos4) ones.

The file "cpp" and "ppc-amigaos-cpp", what's that, the C++ compiler? I have searched in the GNU doc, but can't find some explanations of all files.

ppc-amigaos-cpp, its just an amigaos version of cpp (just different name, and cpp are just symlink to ppc-amigaos-cpp). And it have the same purposes as everythere - preprocessing. You can easy live without (gcc/g++ by default use cc1 instead, which kind of the same by logic).

When you run gcc or g++, you run just a wrappers, which do preproccesing, object creating and linking. I.e. it use "cc1" for preprocessing and making assemble listing, then it use "as" to make a object (on aos4 "as" are symlink to ppc-amigaos-as), and then final linkage by "ld" (symlink to ppc-amigaos-ld). But when you use gcc/g++ wrappers that all done for you automatically, and you not need to worry about cpp/cc1/as/ld at all. You can check the full listing of really called programms and options which spawned to gcc/g++ wrappers via "-v" flag, i.e.:

gcc -v test.c -o test

Also for more detailed help you can use "-save-temps" , like:

gcc -save-temps test.c -o test

That will keep for you all files which done in the middle by gcc/g++ wrappers, and which used on the way from source file to executable one.

test.i - that one are preprocessed (by cc1, the same as cpp by logic)
test.s - assembly listing
test.o - object

When I try to compile, I get these messages

Upload your code somethere, so we can check.

@Salas00

cpp is AFAIK just the C preprocessor used by gcc (you can use "gcc -E" also if you just want to see what the output from the preprocessing stage is).

As far as i can see, i can just remove cpp and ppc-amigaos-cpp from SDK at all, and all still will works fine. What make me think, that by default only cc1/cc1plus are used for preprocessing, but not cpp.

Hi,
As said before, just use g++ to compile a C++ source on amiga.
Use C++ coding :
Well it is not mandatory, but it is cleaner. The C code from lights is not appropriate too much for C++ at last for me.
An another example is how the libraries pointer are passed to getLibIface (C method).

The Makefile use INLINE, I don't like to use it and write all the call, i.e:
IExec->MethodofIExec() in place of MethodofIExec(). So you will avoid conflict names sometimes.

For me, you must initialize each variable BEFORE using it (except if you calculate a new value). So float c=0 is NORMAL as you do a bit later c+=0.2.
If that worked without that, the memory was initialized during compiling (?) with gcc (compiling C). You should never let the compiler choose your starting values.

In general, coding from C to C++ on amiga is not difficult, little changes must me made because C++ is more "delicate" than C. Use warning option of g++ to debug your code and your code will be more perfect.

Good luck
YesCop

Wall -Werror warn you about potential errors (not always right, i.e. if you have uint t,u; t=u-2; u-2 could be negative so you have be warned). It is not a problem if you know what you do as always when you code !!
About initialized variable, I didn't understand your answer. Let's repeat my ealier explanation.
IN the code you have :
float c;
...
c+=0.2 <- this is equal to c=c+2 as you know, then as c is not initialized by you, you could have c equal to anything and not 0 as you expected.

When I reserved memory, I prefer to use new (remember to initialize it after ! :) )when I use C++ objects and allocvec or whatever specific amiga function when I use amiga objects.

Your error about multiple definitions of IExec seem to be normal, I had the same but at the moment, I don't remember what solutions I found. PM to me your last version of code and I will test it for you.
This error is not due to multiple files or suffix of filenames.
During compling, the compiler does not know what function to choose because of multiple definitions. If I remember well, my first tests had this error when compiling in C++ but not in C.

@TheSLASH

lights.o:(.sbss+0x18): multiple definitions of 'IExec'
lights.o:(.sbss+0x1c): multiple definitions of 'IDos'

IExec and IDOS are initialised by startup code so you don't have to open/close them in your own code unless you're writing something special like a .library, .device or a filesystem that can't use standard startup code. It is exactly as the error messages state, i.e. the IExec and IDOS global variables are defined both in lights.o and in the standard startup code which is automatically linked in by the compiler.

@TheSlash

I download demo/misc/lights.lha, and all what i do, its check makefile, and then just do in the shell:

gcc lights.c -o lights

All fine, no errors, programm works.

Then, i do compilation via c++ (as is that what you need), and:

g++ lights.c -o lights

And have:

lights.c: In function 'BOOL init()':
lights.c:76: warning: deprecated conversion from string constant to 'char*'
lights.c:77: warning: deprecated conversion from string constant to 'char*'
lights.c:78: warning: deprecated conversion from string constant to 'char*'
lights.c:91: error: invalid conversion from 'void*' to 'int*'

First 3 are problems-less, but you can removing warning by small change in code, but the most logical way for understanding, just write it from scratch, like this:

 // if( !getLibIFace( (struct Library **)&IntuitionBase, "intuition.library", 50, (struct Interface **)&IIntuition ) ) return FALSE;
  IntuitionBase = IExec->OpenLibrary("intuition.library",50L);
  IIntuition = (struct IntuitionIFace *) IExec->GetInterface (IntuitionBase,"main",1,NULL);
 
 //  if( !getLibIFace( (struct Library **)&GfxBase, "graphics.library", 48, (struct Interface **)&IGraphics ) ) return FALSE;
  GfxBase = IExec->OpenLibrary("graphics.library",48L);
  IGraphics = (struct GraphicsIFace *) IExec->GetInterface (GfxBase, "main",1,NULL);
 
 
 // if( !getLibIFace( &P96Base, "Picasso96API.library", 2, (struct Interface **)&IP96 ) ) return FALSE;
  P96Base = IExec->OpenLibrary("Picasso96API.library",2L);
  IP96 = (struct P96IFace *) IExec->GetInterface (P96Base,"main",1,NULL);

Code without errors checking, but that not matter here. Then i try to compile it again, and only one warning left, about void* to int* conversion. And the line are:

roots = IExec->AllocVec(WWIDTH*WWIDTH*2*sizeof( int ), MEMF_ANY);

So, as it about invalid conversion from some to some, then i check "roots" value, and that is:

int *roots

Then just add cast to the code:

roots = (int *)IExec->AllocVec(WWIDTH*WWIDTH*2*sizeof( int ), MEMF_ANY);

The compilation again via g++, and as result no warning, no errors, but on compiling stage its say the same as you describe before: multiple definition of 'IExec' and of 'IDos'. So then i check again source, and see at top of file:

struct ExecIFace *IExec;
struct DOSIface *IDOS;

So, as linker say about multiply defination, that mean, that when c++ are used, then in startup libs (which adds automatically on building as i describe before) some code which already define IExec and IDos (by some reassons, for plain C compilation, startup code does not have those defines, or even if have, somehow get rid of those errors). So then i just comment them out, and then compilation was succesefull, linking was fine as well, and programm runs and works.

There is modifed code, compile it "g++ lights.c -o lights".

Anyway, prepare that you will have all the times problems of such kinds : i.e. no definations at all, or multiply ones, or wrong includes, or not all includes, or some warnings when migrate from c to c++, and you of course need to understand just whole idea of how all that compilators works, and then it all will be the same as i do: just step by step solving error by errror.

As for your other questions:

Shouldn't C++ be backward compatible

or isn't the C++ part of the Amiga so complete that it could really be used (only if you are a C++ expert) and most people uses C for that reason?

It's a bit hard to start coding for the Amiga, as it seems...

No. Its hard because you do not know how gcc works, you do not know aos api, and you (seems) never migrate C to C++. Because casting problems are usuall, the same as words about multiply definations pretty common and on linux, and on win32, and everythere, if you by some reassons write that kind of code.

Maybe you choice bad code as first try, i told you before to get those ones from blog-posts (those reaction based hello-worlds).

The OS is beta, have multiple GUI's and the C++ is not fully complete and there's no simple OS4+ examples to be found anywhere (what I found) and there's no IDE with simple debug capabilities.

If you expect to see modern OS, with full-blown IDE+Debuggers+A-lot-of-uber-cool-documentation, its wrong choice. OS is small, developers not many and you for sure will have problems and limitations which you not have on win32 or even macos.

Gui toolkits are 2: reaction (official) and mui (3d party, but used on all the others amiga like oses, what can help if you want to make cross-compile app beetwen all amiga-like oses).

It's hard to know if it's my fault or some "incomplete stuff" that have to be worked around - and who know these secrets?

No secrets, just need to read what warning and erros say, then do google on them, and fix them in rigth way.

Better just try to write your own code, from scratch. All those "examples" which uploads everythere usually will give you problems, because of different reassons (like old version of SDK was used on moment of writing of example, or like old version of GCC was used, or old versions of startup libs). Example what you choice, are from 2004, so its luck that it still works.

Could i just remove these lines and the code that opens the libraries?

Exec library contain all the stuff which you use from Exec library. If you want to use AllocVec, which are in exec, then you of course can't remove includes, or how compiler will know where to get that functions ? To be note: that the same on all the oses, on all the compilators : if you want to use some function, you should add necessary includes.

And as i removed the openlibrary of IExec, how do i get access to SetSignal()?

You do know that OpenLibrary and GetInterface are both exec.library functions? So opening exec.library is totally nonesense because to do so you would have to already have access to exec.library.

Anyway the way it's traditionally been solved in AmigaOS < 4.0 is that address 4 (AKA AbsExecBase) contains the pointer to exec.library's library base.

struct Library *SysBase;
SysBase = *(struct Library **)4;

In AmigaOS >= 4.0 the "main" interface pointer is stored inside SysBase and can be accessed like so:

struct ExecIFace *IExec;
IExec = (struct ExecIFace *)((struct ExecBase *)SysBase)->MainInterface;

Also in AmigaOS >= 4.0 direct access to address 4 although it works is discouraged and not necessary as the exec.library base pointer is provided as a parameter to the entry point of processes as well as the LibInit function of a .device or .library.

But this is all handled by startup code so you don't have to worry about it at all. Just include the relevant proto/ include files (proto/exec.h for exec and proto/dos.h for dos) and you will be able to use the library functions.