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

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

[Alejandro Vázquez]

[-- Attachment #1.1: Type: text/plain, Size: 993 bytes --]

Hi!
I've come across the following problem:
When installing classpath, the second symbolic links are not copied to the
target.
This should not happen as the library is installed as install_lib and you
should install the second symbol links.
I came from an older version of ptxdist and this didn't happen.
ptxdist --version: 2018.06.0

I'm not sure if it's a bug or a problem of mine.

Paste Log:

install link:
  src=libjavalangreflect.so.0.0.0
  dst=/usr/lib/classpath/libjavalangreflect.so.0

install file:

src=DistroKit/platform-rpi/packages/classpath-0.99/usr/lib/classpath/libjavanio.so.0.0.0
  dst=/usr/lib/classpath/libjavanio.so.0.0.0
  owner=0
  group=0
  permissions=0644

install link:
  src=libjavanio.so.0.0.0
  dst=/usr/lib/classpath/libjavanio.so.0
-----> MISSING COPY libjavaio.so
install file:

src=DistroKit/platform-rpi/packages/classpath-0.99/usr/lib/security/classpath.security
  dst=/usr/lib/security/classpath.security
  owner=0
  group=0
  permissions=0644


Regards!

[-- Attachment #1.2: Type: text/html, Size: 1549 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

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

[Guillermo Rodriguez Garcia]

Hi there,

2018-07-01 6:28 GMT+02:00 Alejandro Vázquez <vazlup@gmail.com>:
> Hi!
> I've come across the following problem:
> When installing classpath, the second symbolic links are not copied to the
> target.
> This should not happen as the library is installed as install_lib and you
> should install the second symbol links.
> I came from an older version of ptxdist and this didn't happen.
> ptxdist --version: 2018.06.0
>
> I'm not sure if it's a bug or a problem of mine.

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.

Is this causing any actual problems?

BR,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

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

[Alejandro Vázquez]

[-- Attachment #1.1: Type: text/plain, Size: 2175 bytes --]

Thanks, Guillermo!

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.

Is this causing any actual problems?


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


2018-07-05 10:25 GMT+02:00 Guillermo Rodriguez Garcia <
guille.rodriguez@gmail.com>:

> Hi there,
>
> 2018-07-01 6:28 GMT+02:00 Alejandro Vázquez <vazlup@gmail.com>:
> > Hi!
> > I've come across the following problem:
> > When installing classpath, the second symbolic links are not copied to
> the
> > target.
> > This should not happen as the library is installed as install_lib and you
> > should install the second symbol links.
> > I came from an older version of ptxdist and this didn't happen.
> > ptxdist --version: 2018.06.0
> >
> > I'm not sure if it's a bug or a problem of mine.
>
> 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.
>
> Is this causing any actual problems?
>
> BR,
>
> Guillermo Rodriguez Garcia
> guille.rodriguez@gmail.com
>
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de

[-- Attachment #1.2: Type: text/html, Size: 5111 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

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

[Michael Olbrich]

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.

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

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

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

[Guillermo Rodriguez Garcia]

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

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

[Michael Olbrich]

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.

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

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

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

[Guillermo Rodriguez Garcia]

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

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

[Michael Olbrich]

On Fri, Jul 06, 2018 at 12:30:51PM +0200, Guillermo Rodriguez Garcia wrote:
> >> 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.

And as I said, this is not the intended use-case for install_lib. It makes
no sense to install unnecessary links for all libraries just to simplify
one obscure corner case.
Use install_link to create the necessary symlinks.

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