[Pkg-octave-devel] Packaging Octave 3.8

[Mike Miller]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20140102/730044c9/attachment.sig>