Am Mon, 19 Oct 2015 19:08:17 +0200 (CEST) schrieb Yamaban <foerster@lisas.de>:
On Mon, 19 Oct 2015 18:59, Peter Ragosch <peter.ragosch@...> wrote:
Am Mon, 19 Oct 2015 18:01:35 +0200 schrieb Yamaban <foerster@lisas.de>:
On Mon, 19 Oct 2015 17:43, Peter Ragosch <peter.ragosch@...> wrote:
I have installed current package Scilab[1] on openSuSE 13.2 x86_64. .... /usr/java/jre1.8.0_60/lib/amd64/libjava.so /usr/java/jre1.8.0_60/lib/amd64/libverify.so /usr/java/jre1.8.0_60/lib/amd64/server/libjvm.so
Any advice or suggestions how to solve the problem would be appreciated.
Oracle Java, I presume, right?
RIGHT!
Well, for these at least the help is easy. In your dir: /usr/java/ there should be a symbolic link named "jre" , or "jre1.8.0" pointing to "jre1.8.0_60"
with the help of this link it is easy to create a small file in /etc/ld.so.conf.d/ that contains the neccessary info:
e.g. for link "/usr/java/jre"
[code file: /etc/ld.so.conf.d/oracle_java.conf] # get lib path for oracle java right /usr/java/jre/lib/amd64/ [/code]
just two lines, atfer that run run "/sbin/ldconfig" as "root".
Now the command "ldd /usr/bin/scilab-bin" should show the libs.
Does it still break when called now?
- Yamaban.
Thanks for your quick response, Yamaban.
I've created the link and run /sbin/ldconfig.
Now I got peter@raven:~> ldd /usr/bin/scilab-bin [...] libjava.so => /usr/java/jre1.8.0/lib/amd64/libjava.so (0x00007f7233cc2000) libverify.so => /usr/java/jre1.8.0/lib/amd64/libverify.so (0x00007f7233ab3000) libjvm.so => not found libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7233895000) [...] libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f722dfc9000) /lib64/ld-linux-x86-64.so.2 (0x00007f723564a000) libjvm.so => not found libjvm.so => not found libidn.so.11 => /usr/lib64/libidn.so.11 (0x00007f722dd94000) [...]
Remaining problems libjvm.so => not found after libverify.so was found in the "new" path; additionally and NEW after /lib64/ld-linux-x86-64.so.2 was found.
Ah, ld is small-mindend. Happens. (Every dir has to get ists own line)
Add a line to the config file from before: [code] /usr/java/jre/lib/amd64/server/ [/code]
same as before, run ldconfig. Sorry, mea culpa, ignoratem.
- Yamaban.
Your are welcome. I've added the line .... now ldd /usr/bin/scilab-bin found all the libs. But, the Segmentation fault is remaining. If I remember right I get the Pango-WARNING with other apps too, and there it doesn't matter. From that I guess there is a serious problem with the scilab binaries elsewhere. peter@raven:~> scilab XineramaGetLibHandle: using lib libXinerama.so.1 -> 0x1084c90 XineramaGetQueryFunc: trying func 0x1084c90 -> XineramaIsActive XineramaGetQueryFunc: got func 0x7fedcca922a0 XineramaIsEnabled: has Xinerama Ext: ext 1, query-func 0x7fedcca922a0 (scilab-bin:30404): Pango-WARNING **: /usr/lib/pango/1.8.0/modules/pango-basic-fc.so: falsche ELF-Klasse: ELFCLASS32 /usr/bin/scilab: Zeile 928: 30404 Speicherzugriffsfehler "$SCILABBIN" "$@" peter@raven:~> Line 928 is in the scilab script where a test decide which mode to run: "xcos" or "scinotes" or "$SCILABBIN" "$@" The latter is chosen and by this "30404" is an ERROR code from the binary? Alternatively, I could download, install and test the original http://www.scilab.org/download/5.5.2/scilab-5.5.2.bin.linux-x86_64.tar.gz. It is said it would run without a problem ... -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org