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

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

2018-07-05 14:22 GMT+02:00 Michael Olbrich <m.olbrich@pengutronix.de>:
> Hi,
>
> On Thu, Jul 05, 2018 at 01:02:47PM +0200, Alejandro Vázquez wrote:
>> None of the two I think. This was changed in commit
>> > f13787aca6bc51976cbc34be7262683ccd134474, log message was:
>> > ptxd_install_shared: don't install last link
>> > It's only needed at build time.
>>
>>
>> Fine but in the ptxdist documentation
>> <https://www.ptxdist.org/doc/ref_manual.html#install-lib> it indicates that
>> the file *.so is copied.
>
> This is outdated. I need to fix that.
>
>> Is this causing any actual problems?
>
> These links should not be necessary at runtime. That's how library
> versioning on Linux works.
> If you check your desktop Linux, you'll notice, that the last link is in
> the devel package: It's only needed at built time.

Most of the time this is right, but there seem to be exceptions, see below.

>
>> 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. 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?

BR,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de