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...

edelib on SunOS 5.7

Just putting a first impressions after compiling edelib on SPARC powered Ultra-1 SunOS 5.7. This should be, according to this page, Solaris 7 or Solaris 2.5; I never managed to get into this naming scheme.

Ultra-1 always associated me with durability, a feature not known for today's computers. Just when I remember what we did with those few pieces in our lab, how much they were forcefully shutdowned (by plugging out power cable) and how much data they crunched with 200 MHz cpu's... and they still happily running today. Without a problem. That is a quality!

For those unlucky who have no clue what I'm talking about, here are detail specs with images. In short, a very old computer, powered with 64-bit UltraSPARC 200MHz processor and cca. 32 MB or RAM. A perfect piece and platform to test against.

To be honest, some time before I checked edelib status on this computer (ChangeLog says December, 2007) and things changed a bit since that time.

So what we have here? First of all, D-BUS compilation was disabled; I neither don't have nerves to compile it and, most important, I'm lacking space on hard drive (just another indicator how modern software is bloat). I had to disable it manually (commenting parts in Jamfiles and removing checks for pkg-config, because it was not present), but that was 1-2 minute job.

This gave me a nice TODO: some option to disable D-BUS in edelib (during configure phase) would be nice and, when given, should only skip compiling Edbus code much like --without-x does. edelib also utilize --without-x and when given, all code with FLTK involvement will be omitted during compilation (with X11 parts of course). And was used here.

After these preparations, configure script did it's job, reporting small syntax error during XDG mime database presence detection; some csh quirk and should be fixed soon. Compilation then died on regex.h (GNU regex library copy used internally) due some gcc extension (nothing that #ifdef can't fix), which was pretty good; I thought things will be a lot worse :)

Next target was to run tests. Here is the result:

Tests: 55 Passed: 52 Failed: 3 (time: 0.26)

Those 3 failed tests were:

• test for mime types since database wasn't installed
• test for directory functions; check was for "/root" and Solaris does not have it
• and test for binary presence; there are some hardcoded values in test which are standard for Linux systems; Solaris places binaries somehow differently

So, nothing critical. The last thing was to try some tests with the new IPC code I added and after few linker Undefined... errors, additional linking with libxnet was solution (in this library Solaris keeps networking primitives). Test worked as charm :)

ADDON: I just modified build system so shared library could be created too.

Now, the real job would be to compile and run current EDE 2.0 code here. That will be left for the future ;)

Libtool, oh libtool

...goes bye bye from edelib. At last :)

I never liked this tool, but I put it in use, thinking it would save me from messing with shared library creation. And it saved me, indeed, taking my full focus from shared libraries to libtool's own quirks.

For example, those command line options does not work. Or at least, does not do what their names suggests or what documentation said. And, after few tunings those things started to work, going to another computer with another libtool version, everything crashed so nicely yielding very sweet error reports that only libtool can give you.

Maybe I made a mistake using libtool directly, not via AC_PROG_LIBTOOL macro (that does some wizardy behind), but why program exists anyway if you can't use it directly? And in my case, there is no Makefiles nor Automake and AC_PROG_LIBTOOL will be happy if they are used (or you will have to play a little bit with $top_builddir).

Now, a third rewrite of SharedLibrary rule (in edelib Jamrule) finally starts to show some maturity behind ;). Symbolic links will be created, soname will be correctly set (actually not as libtool prescribes but it is easy to "fix" that) and in last commit, even .la files will be created. It is good to be libtool friendly, even if you don't use it.

The only thing left is to see how this will behave on other unix platforms (and other compilers) :P