Re: [ptxdist] The second symbolic links are not copied to the target

[Guillermo Rodriguez Garcia <guille.rodriguez@gmail.com>]

Hi Michael,

2018-07-06 11:54 GMT+02:00 Michael Olbrich <m.olbrich@pengutronix.de>:
> On Thu, Jul 05, 2018 at 02:50:13PM +0200, Guillermo Rodriguez Garcia wrote:
>> 2018-07-05 14:22 GMT+02:00 Michael Olbrich <m.olbrich@pengutronix.de>:
>> > 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
> ptxdist@pengutronix.de



-- 
Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de