SunStudio journey

Some time ago I managed to get (read as "downloaded") a SunStudio toolchain; it is always nice to see what alternatives could look like and/or to prove how badly gcc sucks these days. Unforunately, lack of time left only few "Hello worlds" compiled with Sun's product, a quick usage and compilation speed test.

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

sunCC:

• libedelib.a 384330
• run_tests 498964
• efile 106045
• elinks 85863

I quickly "time-ed" run_test and elinks (elinks against a larger html file) and here they are (results are in form real/user/sys):

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

Results are pretty similar, favoring gcc. Of course, exploring and putting specific options from both would yield faster and/or smaller code. I'll have to play more with the sunCC's options.

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.

New naming scheme

As a product of few requests and a longer discussion on forum (small part was on ede-devel, but looks like the web interface is not refreshed yet), EDE will soon addopt a new naming scheme for applications.

At first sight it looks pretty GNOME-ish, but it is for the reason. Or maybe there are more than a single reason :)

All our applications started with "e" denoting part of EDE (in the KDE style). It was fine until you install applications starting with "e" too, like applications from Enlightenment folks. And you suddenly get: eiconman, edewm, eet... a pretty confusing list where you don't know what is what and what belongs to whom. If you want to reuse all the beauty of the shell completion using "e" as the starting character... things becomes pretty messy.

Adding to this confusing names inherited from 1.x version, this new naming scheme comes as rescue.

Let say you do "ps -ef" to list all the processes and just to check what is eating you memory or cpu, and suddenly you see something like "eiconman". "What the hell is eiconman?", I'm hearing already. Sounds like "superman". Actually it sounds like everything except "desktop" (as desktop with icons in your background).

Yes, "eiconman" is short name of "icon manager" (omitting "e") but icon manager is very broad name and the first thing it associates me is some daemon that manages all visible icons on all opened applications, no matter was that FLTK or Qt or GTK+.

Now, you replace it with "ede-desktop" and things becoms much better. When you see it in that "ps" list, you definitely don't want to kill it or, when it crashed, you'll know how to start it (if you decided to go little bit deeper and help us ;)).

As Ralf commented, shell completion comes free in this case. Of course, there is other side of all this goodness: things could become too verbose, like "ede-do-this-do-that-daemon" and will not be pleasant to type without some shell help. But, you can't have everything.

So things will be keept much more flexible than consistent; e.g. "efiler" sounds better that boring "ede-file-manager" or "evoke" is much more practical than "ede-session-holder-app-starter-and-shutdown-manager".

Btw. things are not changed on the repo yet; hopefully, I will change that during the next few days.

Fixing other's mistakes

In a recent discussion with eNjoy (yep, there should be some media player and I'm hoping it will be usable soon) developer, I found that Ubuntu does not installs FLTK correctly or at least packager missed few important things.

FLTK keeps header names under .H extension; I'm not sure why is this, maybe legacy stuff or due some strange platforms that likes C++ header files ending with .H and source files ending with .C (FLTK uses .cxx here). And since everyone expects .h extension for headers no matter used C or C++, FLTK plays fair here too: installation procedure will create .h symbolic links to those .H files (I'm aware of attempt from C++ purists to keep C++ headers under .hpp extension or no extension at all, like headers from STL, but I'm finding this practice little bit disgusting).

Now, as you guessed, I used .h for FLTK normally as for any other header file all over the code (edelib and ede 2.0), not thinking that some packager will mess things up. Maybe they see this as perfectly normal, but shouldn't distro package resemble the state "make install" or whatever created?

So, latest revisions of edelib and ede2 modules have fixed this "issue". Hopefully, things are less distro dependent now, but, as usually, you never know...