Last night I decided to take things thoroughly: to put edelib on test with this compiler. The truth is that gcc spoiled us a lot. At least on everything except Windows.
Things are pretty consistent across the versions (sans ABI changes): switches and flags are mostly the same, errors and warnings too. Almost every person who was using it more than a few monts will immediately grasp what was wrong by just quickly scanning a few first words of the error report.
Now, taking part with Sun's compiler reminded me on those Windows days when you wanted your application be compiled with as much compilers as possible; so you could stick "extremely portable" on it. And those days were painful. You would spend most of the time reading compiler documentation, fixing build system to support special flags that should made your program runs faster and, at the same time, be smaller.
To the present time: after few obscure error messages (" mister, you are implicitly casting from void* to char*") I started to question my knowledge about type promotion in C, until I found that I was compiling a C code with a C++ compiler (in a Sun's vocabulary, " cc" is C compiler and " CC" is C++ compiler); actualy, during some play I left CC and CXX environment variables to point to "CC" and configure script happily picked it.
After fixing that, things started to roll with some strange " Warning (Anachronism)" and " Warning: i hides Fl_Window::i" (where first "i" is local variable and second is private Fl_Window member; different types of course) and, at the end, things failed in the linking stage with " undefined reference to __mangled-junk-names__".
Aaaaahhh, I'm compiling with a different compiler and it should provide own C/C++/whatever startup and standard libraries. So, adding Sun's "libCstd" and "libCrun" fixed it. After this, things finished successfully, at my suprise.
Hm, it shouldn't be this way; it should be much harder.
Going through the build scripts, I found thing I missed: programs would, by default, link with libstdc++ (gcc's C++ standard library). Why would I want to link with it, when Sun's compiler comes with it?
Removing that and linker went crazy with "undefined reference to new and delete operator family"; a common error in gcc if you miss to link either with libstdc++ or libsupc++ (libsupc++ have only these operators and is perfect if you don't want all that STL stuff with you). So, after putting libsupc++, I get another monster: this time undefined reference to gcc's internal functions like " _Unwind_Resume" and such. Huh boy.
This error will pop up usualy when you feed gcc with -nostdlib or -nodefaultlibs flags; they will omit all libraries gcc secretly put behind your back. Usually no one should mess with above flags except they feels masochistic or know their business. One of those secret libraries is libgcc (guess) and there are _Unwind_xxx functions.
After addition, linkage went fine. Hm... again I'm missing something: why would I still link with gcc libraries? Then came up: FLTK was compiled with gcc!
Now, FLTK rebuild with Sun's compiler and another edelib rebuild (this time without libsupc++ and libgcc) yielded correct linkage.
And, at the end, a small comparison of sizes generated binaries. First of all I didn't use advanced options for both compilers and I just put " -O2" for gcc and " -xO3" for sunCC so this comparison should not be used as the final word; out there exists a much deeper comparisons.
I compared sizes of libedelib library, efile and elinks from examples and run_test, a program that links a bunch of tests.
And here are they, with all sizes in bytes:
gcc:
- libedelib.a 331794
- run_tests 367824
- efile 95459
- elinks 73617
- libedelib.a 384330
- run_tests 498964
- efile 106045
- elinks 85863
gcc:
- run_test: 0.17/0.03/0.02
- elinks: 0.09/0.07/0.00
sunCC:
- run_test: 0.19/0.04/0.04
- elinks: 0.11/0.09/0.00
At the end, it is nice to know that both FLTK and edelib compiles nicely on Sun's compiler. This makes (almost a clear) path to port existing EDE 2.o code on it.
BTW I was using SunStudio 12.