If you call your file name as .c, then when you will try to compile with ppc-amigaos-gcc , you will fail, as a compiler will think it pure C and will not include CPP includes (if at the end of include there are no .h, then its cpp includes).
So, you have 2 solutions :
1). rename the file so it will be .CPP, and then you can build it and with "gcc" and with "g++" binaries. Through when you will build it with "gcc" you must add at the end -lstdc++
2). didn't rename it, keep as .C, but then build it with g++ binary.
Is it safe to switch to -O3? Will ther be drawbacks, maybe inconsistencies on AmigaOS4?
-O3 will bring you problems only if the code has bugs. Usual practice enables full optimization. Those who sort the bugs by switching to lower optimization level not fixing bugs, but hide them.
Fundamental question about the difference of newlib and clib2.
1) If I wanted to compile for clib2, would the switch -mcrt=clib2 be sufficient or fo i have to introduce more changes? 2) Does clib2 also make use of libstdc++.so or does it use something else? 3) If I have used third party libs, like libsdl, libflac, libmpeg etc., with newlib, do I need to use a special clib2 build of those libs or can I simply recycle them for clib2? 4) Are shared builds possible with clib2? 5) is there something like clib2.library available? Just like newlib.library?
1) If I wanted to compile for clib2, would the switch -mcrt=clib2 be sufficient or fo i have to introduce more changes?
Just -mcrt=clib2 enough. By default we have -mcrt=newlib , you just didn't see it when run gcc, but if you do "ppc-amigaos-gcc -v test.c -o test", then you will see :
2) Does clib2 also make use of libstdc++.so or does it use something else?
It have its own libstdc++.so (and others), check in sdk/ppc-amigaos/lib/clib2/ directory
Quote:
3) If I have used third party libs, like libsdl, libflac, libmpeg etc., with newlib, do I need to use a special clib2 build of those libs or can I simply recycle them for clib2?
For clib2 programs, all the libs should be as clib2 ones. You can't mix newlib build with clib2 libs (i.e. you can, sometime it will even compile, but will cause all sort of issues). That another issue for big projects: some of our 3d party libs compiled only for newlib.
Quote:
4) Are shared builds possible with clib2?
As i know clib2 do not support .so as expected, clib2 is not threadsafe, so how it all will works is unclear (i.e. bugs)
Quote:
5) is there something like clib2.library available? Just like newlib.library?
Time increases is a factor of around 1.45 to compile it.
It might be really noticeable on larger project, with horrible makefiles, but on smaller project you should not notice any different.
-O0 Is standard does no optimization, there also fastest to compile.
-O3 used to be buggy in some conditions, it invokes more optimizing tricks, so if there is bug in the compiler it can result in buggy exe file.
So, people removed -O3 if did not work, not sure if that’s true anymore.
Anyway, if you like to find bugs you should compile with -Wall, code can be messy sometimes, often unused variables are left behind, or there some casting that is ignored, that can result in signs bugs, its better to have enabled to begin with, then having to clean up your code, after few 1000 lines of code.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Compiling times only matter if you compile on a1200. What is the matter: bug-free app, and not how long and fast it compiles on developers' machines. My removing -O3 you hide bugs in the app.
Quote:
-O3 used to be buggy in some conditions, it invokes more optimizing tricks, so if there is a bug in the compiler it can result in a buggy exe file.
No, if -O3 show you bugs, it means your code buggy.
Quote:
So, people removed -O3 if did not work, not sure if that’s true anymore.
They hide their own bugs by that, -O3 is very well tested by millions of ppls already for a years.
-O3 used to be buggy in some conditions, it invokes more optimizing tricks, so if there is bug in the compiler it can result in buggy exe file.
I wouldn't call it tricks. The main difference between O2 and O3 is that O3 sacrifices a bit of memory to run faster. This might not always succeed due to decreases in code density (resulting in cache misses). To find out how it affects your code you need to do some benchmarking. It could be that projects used O2 for performance reasons, not because the compiler is buggy.
I am nowhere near my amiga right now but I remember reading the readme from new GCC builds and always wanted to ask.
There is a snippet about shared obhects/builds in there that says to avoid shared builds due to some planned restructuring.
What is needed for this restructuring? Has this restructuring already started and messed up shared builds...what may cause the many issues we are having? Would it be possible to revert these changes to get an outdated, but working, shared support back?