Author: remi

Funny how sometimes different people try to fix the same issues at the same time.

First, I’d like to provide a little insight into Libtool and Dolt because a few people have been talking about it for a week or so, but not that many people know what libtool really does, yet everybody agrees on hating it. 😀

Libtool started as a brilliant idea to have one script that could be used to compile C files and link the resulting object files into whatever we want : executables, static libraries or dynamic libraries. That’s what /usr/bin/libtool does. It’s a cross platform LIBrary TOOL, all in a 218KB shell script. All that code knows about all the C compilers out there, all the linkers and all the subtleties in the command line arguments each and every one supports.

The problem with libtool is that it’s a 218KB shell script. Everytime you build something with an Autotooled project that uses libtool (so basically, all projects that build libraries), for every C file in that project, libtool gets called.

For C++ files, it’s not that big a deal since g++ is quite slow. But for plain C, it’s a whole other issue, as running libtool can sometimes be slower than the actual compiling of the C code it’s used for.

That’s where Dolt kicks in. Basically, Dolt is set up during ./configure and will create a small shell script that takes the same arguments that libtool does. But instead of being 218KB, it’s only going to be a few dozens of lines because ./configure did all the hard work of knowing which compiler and linker are going to be used. Dolt is basically a caching system for libtool. And that’s good.

Now, libtool 2.2 is supposed to be much faster than 1.5.26, and that’s a good thing too because Dolt doesn’t speed up all the operations. Dolt only kicks in for the compiling, not the linking. So all in all, Dolt + libtool-2.2 should be a very good thing for Gentoo users. Let’s hope both gain wide acceptance by upstream projects.

Let’s move on to .la files. Those are text files that everybody has on their systems. Just take a look in /usr/lib, there’s one for almost every .so file. Those are again something libtool creates for the following reasons :

• .la files contain information about both dynamic (.so) and static (.a) libs. .a files unlike ELF .so files do not contain dependencies, so .la files contains those deps. So this is an interesting feature, but mostly aimed for those who need static binaries.
• Dynamic libraries have different naming conventions on different operating systems. .la files make it somewhat easier to be cross-platform.

In theory, .la files are a very good thing… In practice, they hurt us more than they do help solve problems.

• When building applications with dynamic libraries, .la files contain redundant information and therefor are quite useless.
• When using --as-needed in your LDFLAGS, .la files won’t benefit from the work done by the linker to prune unneeded libraries because .la files are generated by libtool and not the linker. Diego said he would try to write a script that could clean up .la files, but it’s still not a good long-term solution.
• File system pollution… I have 1096 .la files on a “standard” Gentoo systems with Gnome and a few other apps. ‘Nuf said.

“Well, why don’t you remove them? Can’t libtool work correctly without .la files?”

The simple answer is Yes, libtool can work without .la files, but there are exceptions. Basically those include any app that use libtool’s dlopen wrapper library. libltdl expects .la files to work properly, so that’s a PITA. Apps in that category include PulseAudio, Dia (although I’ve fixed it in upstream, awaiting for a new release), … and KDE.

Yep, KDE 3 really sucks on that very point because if you remove KDE’s .la files, it will just not work anymore. I truly hope KDE 4 doesn’t have that flaw (could anyone let me know?).

I have a plan for the Gnome Herd, which I will probably explain when I have some time to work on it 🙂 Hopefully, it should make everyone happy.

Update: I’ve been reminded (and how could I ever forget!) that KDE 4 uses CMake, so it’s thankfully immune to that problem. 🙂

Yesterday night, Gilles finished moving Gnome 2.22 to portage. Left in the Gnome Overlay are :

• swfdec and friends, Doug and Mart will be working on it.
• metacity-2.23, yes you read that right. Upstream has already branched for Gnome 2.24 but we’ll stick with metacity 2.22 of course.
• pkgconfig, Saleem had created a special ebuild that would make pkgconfig use the system’s glib. But Gilles and I feared this might introduce a circular dependency hell, so we erred on the safe sides of things and just bumped the old ebuild for pkgconfig-0.22. We’ll have to sort this out though.
• libsigc++, we’ve bumped it in the overlay (versions 2.1.1 and 2.2.2) but they broke cdrdao which used the old “SigC” c++ namespace. So this one might break other packages. Again, this one will have to be sorted out at some point.

Now, back to the good news! Gnome 2.22 is in the tree!

If you want to try it out here’s what you should do :

1. Sync your portage tree and emerge -DuNa world
2. Copy-paste the “The Great GNOME 2.22 Mask ™” from /usr/portage/profiles/package.mask into /etc/portage/package.unmask
3. Update your system again using emerge -DuNa world

WARNING #1 !

Do not try this on a stable Gentoo system. Is this clear enough? If you open a bug and we see that you have a stable system, we will close the bug WONTFIX. You have all been warned.

WARNING #2 !

We have not yet written the Upgrade Guide (which I’ll start today), so we don’t yet really know all of what might break during the upgrade. This is a work in progress.

But if anything breaks for you, please report it to bugzilla, we need feedback so that we can write a better Upgrade Guide, which will help everyone in return.

Other than that, enjoy Gnome 2.22 😀

PS, big props to Mart and Gilles who did almost all of the grunt work in the past few days to move everything from the overlay to portage.

Update: We still have to take care of the various Gnome bindings too, I plan to take on the gnome-mm ones really soon, but I don’t know for the others.

Oh, we are working on a major update for the gnome-python packages, but since I’m not fully up to date on the subject, I’ll leave that up for another post.

Saturday morning started really quietly, so quietly in fact that I actually missed the opening keynotes… That’ll teach me not to look at the schedule before the event starts.

Over the 2 days, I mostly stayed around the Xorg dev room. I had the chance to talk to a lot of really cool people: Fr

Short blurb before the first Xorg talk starts :

I arrived on Friday morning, way before the first event was set to start. That gave me the opportunity to walk around Brussels for a couple hours. Nice city, I’ll definitely have to come back later for a proper visit.

I also took an hour to finish my talk for sunday morning.

Around 7:00PM, I set out to find the FOSDEM Beer Event, which as it turned out, was about 4 blocks away from my hotel. Rock on!

So I finally had the chance to meet a few non-French Gentoo devs : Wolfram (wschlich), Santiago (coldwin) and later in the night Daniel (dsd) and Peter (welp). I’m really glad to be able to link names with actual faces now.

We had a few really nice conversations, some concerning directly Gentoo and what we want to do or see being done, but that probably requires another post of its own.

Beer wise, I remember drinking Chimay Bleue and Delirium Tremens. As for the quantity, the headache I had this morning wasn’t too bad – considering the little food I had eaten – I’d say I had something like 5 or 6 glasses, but I can’t remember :>>

More later