FTBFS dbus-java

The reason for the failiure have changed from 2.3.1-1 to 2.5-4. I suspect this is a problem in libmatthew since it until recently refused to build and the failure in dbus-java is that the symbol about __stack_chk_fail_local not beeing defined in /usr/lib/jni/libunix-java.so, a part of libmatthew-java. I am not sure if the old error is gone. The new error is:

make[2]: Entering directory `/build/buildd/dbus-java-2.5'
/usr/lib/jvm/java-6-openjdk/bin/java -Djava.library.path=/usr/lib/jni -classpath :/usr/share/java/unix.jar:/usr/share/java/hexdump.jar:/usr/share/java/debug-disable.jar:libdbus-java-2.5.jar:dbus-java-test-2.5.jar org.freedesktop.dbus.test.test
Creating Connection
Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jni/libunix-java.so: /usr/lib/jni/libunix-java.so: undefined symbol: __stack_chk_fail_local
 at java.lang.ClassLoader$NativeLibrary.load(Native Method)
 at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1767)
 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1692)
 at java.lang.Runtime.loadLibrary0(Runtime.java:840)
 at java.lang.System.loadLibrary(System.java:1047)
 at cx.ath.matthew.unix.UnixSocket.<clinit>(UnixSocket.java:33)
 at org.freedesktop.dbus.Transport.connect(Transport.java:765)
 at org.freedesktop.dbus.Transport.<init>(Transport.java:730)
 at org.freedesktop.dbus.DBusConnection.<init>(DBusConnection.java:159)
 at org.freedesktop.dbus.DBusConnection.getConnection(DBusConnection.java:142)
 at org.freedesktop.dbus.test.test.main(test.java:422)

Session terminated, killing shell...make[1]: *** wait: No child processes. Stop.

Adding "-fno-stack-protector" to CFLAGS in the libmatthew Makefile and rebuilding solved the problem for me. I'm no expert but here's my theory: If you are using the Sun JDK, the java executable built by Sun does not have stack protection enabled. So when the JVM tries to load the libmatthew shared libraries the external references to __stack_chk_fail_local in the libmatthew shared libraries cannot be resolved and the load fails. Rebuilding the libmatthew libraries with "-fno-stack-protector" removes the references to __stack_chk_fail_local.

Axos: Thank you. In order to get credit for fixing it here is what you do (in case you don't already know):

cd to a new folder

apt-get source libmatthew-java # you will need the original anyway, and if you didn't increase the changelog before you don't have the original but a changed thing

cd libmatthew-java-0.7.1

dch -i # edit the changelog

# write what you did, for example: * Makefile: Added -fno-stack-protector to CFLAGS
# check that your name and email are correct. Be careful with the formating
# change distro in the top line (after libmatthew-java (0.7.1-1ubuntu2)) to Jaunty
# save the changelog

# change libmatthew-java so dbus-java will build

debuild # build it.
cd ..

# Test the new version. (That it fixed the bug, that it builds on jaunty etc) To see if it builds on Jaunty you can use https://wiki.ubuntu.com/PackagingGuide/Intro/Pbuilder

debdiff libmatthew-java_0.7.1-1ubuntu1.dsc libmatthew-java_0.7.1-1ubuntu2.dsc >> libmatthew.debdiff

# Upload libmatthew.debdiff to this bug.
# If you have tested it enough subscribe ubuntu-universe-sponsors

The build only fails currently in unit test. I don't think adding "-fno-stack-protector" to CFLAGS is ideal solution. I am going to update dbus-java to latest release 2.5.1. The build failure I am getting with 2.5.1 is different and due to a missing file from upstream tar ball. I am disabling unit test (check target in Makefile) so the build will not fail.

This bug was fixed in the package dbus-java - 2.5.1-0ubuntu1

---------------
dbus-java (2.5.1-0ubuntu1) jaunty; urgency=low

  * New upstream release.
  * debian/control
    - Update 'Standards-Version' to 3.8.0. No changes needed.
  * debian/rules
    - Disable 'check' target as compilation fails due to a missing file in
      upstream distribution. This in turn causes build failure.
      (LP: #218658, #302402)

 -- Onkar Shinde <email address hidden> Thu, 18 Dec 2008 03:08:07 +0530

This bug still happen using the latest dbus-java package from Jaunty. It doesn't look like it was solved.

Hmm, so I'm the upstream for dbus-java and libmatthew-java and also the Debian packager for both (I think my packages have been taken from Debian for Ubuntu). How come I've not been told about this yet? No-one has said anything in either capacity yet...

Anyway, disabling make check is clearly WRONG. It'll just turn an FTBFS into broken packages.

AFAICT it's working in Debian Lenny, so something has gone wrong with the dependencies since then. If people can work it out please tell me because it looks like something I should push upstream.

Matt

I get the similar error at run time. (Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jni/libunix-java.so: /usr/lib/jni/libunix-java.so: undefined symbol: __stack_chk_fail_local)

Adding the following line to debian/rules (somewhere at the top) and rebuilding the package (libmatthew-java) have solved my problem:

CFLAGS += -fno-stack-protector

This bug was fixed in the package libmatthew-java - 0.7.2-1ubuntu1

---------------
libmatthew-java (0.7.2-1ubuntu1) karmic; urgency=low

  * Merge from debian unstable (LP: #371518), remaining changes:
    - debian/control: Remove unneeded build dependency classpath-doc.
    - Makefile: Add -D_GNU_SOURCE compiler flag and remove -Werror.
  * New Upstream Release:
   - build with -fno-stack-protector compiler flag fixes LP: #218658 and LP: #360880

libmatthew-java (0.7.2-1) unstable; urgency=low

  * New Upstream Release
  * Bump Standards-Version
  * Bump debhelper compat
  * Change to section java

 -- Rail Aliev <email address hidden> Mon, 04 May 2009 14:13:46 +0400

This is fixed for dbus-java also.

For anyone who ended up here while troubleshooting this problem, you can get the debs for karmic from https://launchpad.net/ubuntu/karmic/+source/libmatthew-java/0.7.2-1ubuntu1 on the right hand side of the page. Installing those on 9.04 is working for me so far. I don't know if that's the correct way to do it, but it's the best I've come up with.