Hi, On Sunday, 01.05.2011, 20:25 +0200 Andreas Barth wrote: > * Matthias Klose (d...@debian.org) [110501 18:31]: > > On 05/01/2011 04:31 PM, Andreas Barth wrote: > >> So it seems to me this can either only be avoided with having g++ and > >> gcj pointing to the same version, and/or explicitly depending on one > >> version in the build-dependencies of pdftk (which I would consider > >> more ugly - but YMMV). > > > > please fix pdftk to build-depend on default-jdk, and don't use gcj > > explicitly. > > so, how should the calls be then? Build-depend on default-jdk, and use > g++ for building the c++-part, and what for building the jdk-part?
Here some explanatory notes about the (partial exotic) pdftk program and a summary of the issue: 1. pdftk links C++ code directly with java code using the Compiled Native Interface (CNI) [1], which is AFAIK only supported by gcj. So common rules like "use default-jdk instead of gcj-jdk" are here not applicable. 2. pdftk fails during runtime if the used gcj and g++ have different version. The reason is a check inside the g++ class loader, see [2]. 3. Currently, the compiler version check is done at build time by calling g++-4.x explicitly if default gcj has version 4.x.y. But if gcc-defaults (or any other package) does not guarantee that g++-4.x is available, FTBFS can happen - better than frustrated users due to unusable pdftk but anything than optimal. That gcc-defaults should provide the same version of g++ and gcj is the opinion of Sebastian Schmidt, too [3]. I understand that this change in gcc-defaults is for almost all applications not needed and makes gcc-defaults less flexible. Adding build-dependencies on explicit g++ and gcj versions to pdftk would be a workaround, but is in my eyes not the way we should solve the issue. Best regards, Johann Felix [1] http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html [2] Comments from gcc-4.6.0/libjava/java/lang/natClassLoader.cc: // Check that the file we're trying to load has been compiled with a // compatible version of gcj. In previous versions of libgcj we // silently failed to register classes of an incompatible ABI version, // but this was totally bogus. ... // If we've loaded a library that uses the C++ ABI, and this // library is an incompatible version, then we're dead. There's // no point throwing an exception: that will crash. [3] http://bugs.debian.org/624778 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
