On Thu, 2 Jan 2014 20:10:19 +0100, Sébastien Villemot wrote: > Le lundi 30 décembre 2013 à 15:51 -0500, Mike Miller a écrit : > >> One minor issue I've noticed with the new release is the way the JRE is >> dynamically linked in. With this configure option in debian/rules >> >> --with-java-homedir=/usr/lib/jvm/default-java/ >> >> you might think it would use only that path for Java support, but in >> fact the following path is a built-in string in liboctinterp.so.2 >> >> /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server >> >> The result is that the binary package actually depends on the version of >> Java that was the default-jdk when it was built, and not what >> default-jre-headless is at run time. Fixing the build to only use the >> default-java path should help with maintainability and might avoid >> potential bugs. >> >> Adding the option >> >> --with-java-libdir=/usr/lib/jvm/default-java/jre/lib/amd64/server >> >> to my configure command fixes that. This would of course need to be >> parameterized in some way to work on all ports, I'm not sure at the >> moment what that would look like. Perhaps this should also be reported >> upstream? > > Thanks for noticing this. Clearly this is an issue that we should fix, > otherwise the package dependencies will not reflect the actual > dependencies if the default JDK were to change on a given arch. Do you > think you can propose a patch? I guess the simplest and most straightforward way would be to simply find libjvm.so in /usr/lib/jvm/default-java/jre/lib/*/{client,server} and pass the containing directory to configure as --with-java-libdir. The javahelper package looks like it provides some make variables that essentially encapsulate this logic. I'll try to get something working along these lines using this additional build helper unless anyone else has a better solution. I now remember that I had reported an upstream bug [1] a while ago to fix this in a different way, to simply avoid encoding the path to libjvm.so at all and locate it at runtime instead. This would obviate this problem but is a bigger change from what we have now. [1] https://savannah.gnu.org/bugs/?40111 -- mike
Attachment:
signature.asc
Description: OpenPGP digital signature