Martin Helm wrote:
> Am 30.08.2012 08:28, schrieb Terry Duell:
>> Hello All,
>> Back in Jan I encountered a problem with Octave 3.4.3 and Fedora 16
>> x86_64, where I received the message from Octave...
>>
>> error: java_invoke:
>> /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/client/libjvm.so:
>>
>> failed to load:
>> /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/client/libjvm.so:
>>
>> cannot open shared object file: No such file or directory
>>
>> Subsequent checking of my system revealed that there was no
>> .../jre/lib/amd64/client dir, but there was a server dir containing
>> libjvm.so.
>> Responses to my request for help suggested that I could create the
>> client dir and provide a simlink to libjvm.so, and that this had
>> probably occurred because of a packaging problem.
>> I am beginning to think that it may not be a packaging problem and
>> that it may be Fedora policy to package openjdk with only a server dir
>> containing libjvm.so, as the same issue has now cropped up with Fedora
>> 17 and subsequent openjdk updates, i.e. I have had to create the
>> symlink a number of times since my original message.
>>
>> Is it possible for the relevant Octave code to look for libjvm.so in
>> the server dir as well as the client dir, or to find the library some
>> other way without causing other issues?
>> It does seem that things are not as they should/could be if the user
>> has to apply a fix to system files to overcome this error.
>> It is a bit curious is that I seem to be the only one who has raised
>> this question on this list. Surely I'm not the only one running Octave
>> on Fedora... and encountered this error.
>>
>> Cheers,
>
> You are not alone with Fedora, the exactly same problem happens on all
> openSUSE versions as well, I always have to create the appropriate
> symlinks manually. I am not sure what the correct solution is (changing
> the package policy for openjdk, creating the symbolic link when the
> octave forge java package is installed, changing the source code of the
> of java package).

This always seems to be the case in 64 bit systems (AFAIK also on 
Windows 64b).
If it gives some comfort: on Mac OSX it is worse. The Java libs and 
executables have been scattered all over the place there and often seem 
to be moved into other locations with new OSX version.

Anyway, Michael (Java package maintainer) is the one to give advice here.

I recently committed a preinstall.m to svn that looks for the 
executables and the jvm lib in the known places and aborts the Java pkg 
installation if they cannot be found. That helps in the sense that 
unwary users are not left with Java package installations that didn't 
yield errors but in fact are still half-baked.
I did think of having the script add the relevant symlink automatically 
(AFAIK it is only needed for the jvm library) but in many situations one 
needs to have admin/root credentials for that. I think I left this 
option out as I'm not sure if fooling around in the system setup is the 
right thing to do for ordinary users, let alone user application 
scripts. But I could amend it to at least warn if the symlink is needed 
but the user doesn't have the required privileges; perhaps that is 
already in place anyway, I forgot.

> Anyway I think this discussion should go to octave forge where the java
> package is maintained not to the octave helper list, I put the
> corresponding dev list on CC and would think that from the next reply on
> help-oct...@octave.org should be removed from CC.

Done.

Philip

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev

Reply via email to