blogs > andrew > software > java-gnome > gcj-4.0.0-linking-problem

Tue, 31 May 2005

GCJ linker problem?

gcj-4 (ld?) appears to have a problem passing arguments correctly embedding library paths — it’s ignoring -rpath arguments.

I’ve avoided it until now, but the mission critical procedures application I’ve been working on finally needed to move up to depending on Java 1.4.2. That’s no problem as far as Real Java VMs go, but I’ve worked hard to ensure xseq runs under Free Java, and so having raised the Java version requirement means depending on the newly released GCJ-4. It runs great under GCJ’s gij Java runtime, but I’ve run into a serious problem trying to use gcj to build the app to a native executable.

My system compiler is GCC 3.4.3 - that’s pretty modern, but I run Gentoo and so I really need gcc to work and upgrading the system compiler to >= GCC 4.0.0 just isn’t prudent yet. So I built and installed GCJ-4 and put it in /opt/gcj-4.

GCJ-4, of course, has a new runtime, libgcj.so.6, so if I wanted to build xseq with GCJ-4, I couldn’t use the java-gnome libraries that were installed on the system that had been compiled by GCJ-3.4.x. So I quickly built the current java-gnome from CVS stable with a prefix of /opt/java-gnome and installed it.

When I configured xseq and build it to native with the GCJ-4 and the new java-gnome, it segfaulted. Great. Long story short (and many iterations hidden for brevity) I ran ldd on the xseq binary and was really confused:

linux-gate.so.1 =>  (0xffffe000)
libgtkjava-2.6.so => /usr/lib/libgtkjava-2.6.so (0xb7c09000)
libgladejava-2.10.so => /usr/lib/libgladejava-2.10.so (0xb7bf0000)
libgcc_s.so.1 => /opt/gcj-4/lib/libgcc_s.so.1 (0xb7be5000)
libgcj.so.6 => /opt/gcj-4/lib/libgcj.so.6 (0xb6d25000)
libm.so.6 => /lib/libm.so.6 (0xb6ced000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6cdb000)
libdl.so.2 => /lib/libdl.so.2 (0xb6cd8000)
libc.so.6 => /lib/libc.so.6 (0xb6bc2000)
libgcj.so.5 => /usr/lib/libgcj.so.5 (0xb62a0000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6292000)
libgnomejava-2.10.so => /usr/lib/libgnomejava-2.10.so (0xb61e8000)
/lib/ld-linux.so.2 (0xb7feb000)

Why the hell was libglade-java being sourced from /usr/lib and not /opt/java-gnome/lib? (and note that the “wrong” libgtkjava-2.6.so pulled wants to pull in libgcj.so.5, which clearly conflicts with .6).

Before you start telling me to use LD_LIBRARY_PATH to solve all my issues, I’m ahead of that. I used -rpath to embed the library paths. Read the Makefile fragment that built that executable:

xseq: build/native-libs build/native-dist build/native-tests
    $(GCJ) \
        -Wl,-rpath=/opt/gcj-4/lib \
        -Wl,-rpath=/opt/java-gnome/lib \
        -L/opt/gcj-4/lib \
        -L/opt/java-gnome/lib \
        -lgtkjava-2.6 -lgladejava-2.10 \
        -classpath $(CLASSPATH):lib:src:tests \
        -fjni -O \
        --main=xseq.ui.WindowRunner -o xseq \
        [all the .o files]

Here’s the rub: the first -rpath argument took, as it found the right libgcj.so.6 but the second -rpath argument appears to have been ignored. According the the ld man page, multiple rpath arguments should be aggregated together to compose a library search path. This seems to be not happening.

I sat with Dalibor Topic and Mark Wielaard for several hours working through this, and we discovered that its not just my app — when libgladejava-2.10.so was linked during the build of java-gnome’s libglade-java, it would only take 0 or 1 -rpath arguments, and also appears to have ignored subsequent ones. Note, however, that having reviewed carefully the output of --verbose (passed to the linker with -Wl,), ld does find the correct libraries - it’s just not embedding the paths properly. If the java-gnome libraries you’re using are installed to a prefix of /usr (ie, in /usr/lib), then things “just work”, but if you install to a non-standard (ie not in ld.so.conf) place things thunder in.

I’ve asked Dalibor to pick this up from here, as I really don’t know what to do about it. My code is available, and you can try this yourself, though. See the downloads page to see how to get the code. Once you’ve got it, and installed gcj and java-gnome somewhere non-standard, then do something like:

$ ./configure gcj_home=/opt/gcj-4 java-gnome_home=/opt/java-gnome
$ V=1 make

Then compare the output of

$ ldd ./xseq

against

$ LD_LIBRARY_PATH=/opt/gcj-4/lib:/opt/java-gnome/lib ldd ./xseq

and wonder why the first one isn’t correct.

Oh, lastly, even with LD_LIBRARY_PATH set to avoid the -rpath bug, when I ran the program it said (as windows were freezing, and other exceptions were blowing out) this:

GObject:finalize() of: org.gnu.gdk.Pixbuf
  Handle32Bits - pointer = 136749256
  nativeFinalize - Start.
    appending 136749256
  nativeFinalize - End.
GObject:finalize() completed.

I have no idea what that menas, but that error does not occur when .class files are run by gij, even though it was the same libraries and the same libgcj. It only happens when the natively compiled executable is run — which is why Mark suggested that miscompilation may also be an issue.

AfC

gcj-4.0.0-linking-problem, posted by Andrew Cowie in /andrew/software/java-gnome at 14:58, 31 May 2005.

---

Category Specific Feeds. Use these links for an RSS or ATOM feed limited to this category and its descendants. Technorati Profile

---