Hi Michael, 2018-07-06 11:54 GMT+02:00 Michael Olbrich <[email protected]>: > On Thu, Jul 05, 2018 at 02:50:13PM +0200, Guillermo Rodriguez Garcia wrote: >> 2018-07-05 14:22 GMT+02:00 Michael Olbrich <[email protected]>: >> > On Thu, Jul 05, 2018 at 01:02:47PM +0200, Alejandro Vázquez wrote: >> >> Yes. At least it gives problems with Java applications. >> >> ....... >> >> [Failed to open library /usr/lib/classpath/libjavanio.so: >> >> /usr/lib/classpath/libjavanio.so: cannot open shared object file: No such >> >> file or directory] >> >> [Failed to open library ./libjavanio.so: ./libjavanio.so: cannot open >> >> shared object file: No such file or directory] >> >> [Failed to open library /usr/lib/jni/libjavanio.so: >> >> /usr/lib/jni/libjavanio.so: cannot open shared object file: No such file >> >> or >> >> directory] >> >> ...... >> >> >> >> It also happens with some Gstreamer plugins. >> >> >> >> (gst-plugin-scanner:252): GStreamer-WARNING **: Failed to load plugin >> >> '/usr/lib/gstreamer-1.0/libgstimxg2d.so': libGAL.so: cannot open shared >> >> object file: No such file or directory >> > >> > These libraries are broken. I expect they don't have a soname (you can >> > check that with 'readelf -d <filename>'). >> > >> > You need to create the link manually with 'install_link'. >> >> I can't talk about GStreamer but dynamic library loading in Java is a >> bit different. > > This has nothing to do with GStreamer. The problem is, that libGAL.so is > missing the correct 'soname'. As a result, libgstimxg2d.so is not linked > correctly.
Yes, so libGAL.so is broken. You are right in that this is not something that ptxdist should try to "fix". However .... > >> There are no elf files involved. Java >> applications/libraries can request that a native library is loaded via >> the System.loadLibrary runtime API. This takes a "generic" (platform >> independent) library name, which is then "resolved" to a platform >> specific filename by the JVM. For Windows this is typically "foo" -> >> "foo.dll", and for Linux it is "foo" -> "libfoo.so". >> >> So it seems that removing the .so links breaks all Java applications.. >> >> Can this be reconsidered? > > No, install_lib is for proper versioned shared libraries. If you need extra > links, then you can add those with install_link. .... however, this is a different case. The problem with Java is not that the libraries themselves are not properly versioned. The problem is that due to the way native libraries are loaded in Java, the JVM must map a "generic" name such as foo to a platform-specific filename, which for Linux would be "libfoo.so", and then it tries to load that by filename. This assumes that the .so file is present and links to the appropriate libfoo.so.X. Guillermo > > Michael > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | > > _______________________________________________ > ptxdist mailing list > [email protected] -- Guillermo Rodriguez Garcia [email protected] _______________________________________________ ptxdist mailing list [email protected]
