On 05/01/2011 09:51 PM, Johann Felix Soden wrote:
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.
No, there is no guarantee that the versions do match. In this case, please
either use 4.4 or 4.6 directly.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
