I'm currently working on an upgrade DVD that will allow to upgrade a Mandriva Flash 2007 4G to Mandriva Flash 2007 Spring. Sounds great, right?

But it's not as easy as it seemed, I had a bunch of i18n-related problems. For example, OpenOffice.org would only "see" the English language. Quite bad for a distribution that aims to support as many languages as possible.

So, what's wrong? Missing packages? Missing files? I'm doing some not-really-kosher things with the rpm packages, breaking the rpm database by splitting files from the same rpm in different compressed loopbacks, it could explain. But no, everything looks ok.

I tried to reproduce with a Mandriva One 2007 Spring live CD, but there was no problem there. Stracing it (strace -e file) showed that it runs stat("/live/distrib/usr/lib/ooo-2.1/share/registry/modules/org/openoffice/Setup/Langpack-fr.xcu") at some point. Which is fine in the One live CD, since there was only one loopback containing all compressed files (mounted as /live/distrib), mounted by UnionFS together with a writable tmpfs. But in the new Flash version, we have split lang files into different loopbacks, to easily build different regions of Mandriva Flash. So, for example, the french translation files are mounted in the /live/modules/i18n-fr root, which obviously is not contained in /live/distrib.

But why is it looking in the /live/distrib root, shouldn't that be plain /? Looking for first occurence of this root in strace output shows that readlink("/proc/self/exe") returns /live/distrib/usr/lib/ooo-2.1/program/soffice.bin. Actually, there is a known misfeature in old unionfs, it does not handle /proc/self/exe correctly.

Hmm, but who tries to do that with /proc/self/exe? Let's see OpenOffice source code. Our rpm source package looks weird, it contains plenty of tarballs (and a unowinreg.dll file ??), and untaring them takes a dozen of minutes. But no luck grepping for /proc/self/exe in the code...

After looking more closely at strace output, it shows that right after using /proc/self/exe, it runs access("/etc/ld.so.preload"). Ok, so it's a glibc thing. (excuse-me someone? I just wanted to have translations in OOo!)

Grepping through glibc source code shows that the "culprit" is _dl_get_origin() from sysdeps/unix/sysv/linux/dl-origin.c. So, someone is trying to use the $ORIGIN DST (which reminds me I have to write some notes about Dynamic String Tokens), substituted by the glibc ELF loader.

Back to OpenOffice source code, we can find that most Makefiles for Unix set LINKFLAGSRUNPATH*=-Wl,-rpath,\''$$ORIGIN'\' as link flags. Oh, brilliant.

$ objdump -p /usr/lib/ooo-2.2/program/soffice.bin | grep RPATH
RPATH       $ORIGIN

But you don't exactly need a rpath here, since the /usr/lib/ooo-2.1/program/soffice wrapper already exports LD_LIBRARY_PATH to its basename. Let's check that by removing the rpath:

chrpath -d /usr/lib/ooo-2.1/program/soffice.bin

At this point, I could have expected quite more trouble, but finally some luck here, OpenOffice gets translated \o/

God (if you exist), what did I do to deserve this? I mean, seriously?!