* [ptxdist] The second symbolic links are not copied to the target @ 2018-07-01 4:28 Alejandro Vázquez 2018-07-05 8:25 ` Guillermo Rodriguez Garcia 0 siblings, 1 reply; 8+ messages in thread From: Alejandro Vázquez @ 2018-07-01 4:28 UTC (permalink / raw) To: ptxdist [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ptxdist] The second symbolic links are not copied to the target 2018-07-01 4:28 [ptxdist] The second symbolic links are not copied to the target Alejandro Vázquez @ 2018-07-05 8:25 ` Guillermo Rodriguez Garcia 2018-07-05 11:02 ` Alejandro Vázquez 0 siblings, 1 reply; 8+ messages in thread From: Guillermo Rodriguez Garcia @ 2018-07-05 8:25 UTC (permalink / raw) To: ptxdist 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ptxdist] The second symbolic links are not copied to the target 2018-07-05 8:25 ` Guillermo Rodriguez Garcia @ 2018-07-05 11:02 ` Alejandro Vázquez 2018-07-05 12:22 ` Michael Olbrich 0 siblings, 1 reply; 8+ messages in thread From: Alejandro Vázquez @ 2018-07-05 11:02 UTC (permalink / raw) To: ptxdist [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ptxdist] The second symbolic links are not copied to the target 2018-07-05 11:02 ` Alejandro Vázquez @ 2018-07-05 12:22 ` Michael Olbrich 2018-07-05 12:50 ` Guillermo Rodriguez Garcia 0 siblings, 1 reply; 8+ messages in thread From: Michael Olbrich @ 2018-07-05 12:22 UTC (permalink / raw) To: ptxdist 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ptxdist] The second symbolic links are not copied to the target 2018-07-05 12:22 ` Michael Olbrich @ 2018-07-05 12:50 ` Guillermo Rodriguez Garcia 2018-07-06 9:54 ` Michael Olbrich 0 siblings, 1 reply; 8+ messages in thread From: Guillermo Rodriguez Garcia @ 2018-07-05 12:50 UTC (permalink / raw) To: ptxdist 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ptxdist] The second symbolic links are not copied to the target 2018-07-05 12:50 ` Guillermo Rodriguez Garcia @ 2018-07-06 9:54 ` Michael Olbrich 2018-07-06 10:30 ` Guillermo Rodriguez Garcia 0 siblings, 1 reply; 8+ messages in thread From: Michael Olbrich @ 2018-07-06 9:54 UTC (permalink / raw) To: ptxdist 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ptxdist] The second symbolic links are not copied to the target 2018-07-06 9:54 ` Michael Olbrich @ 2018-07-06 10:30 ` Guillermo Rodriguez Garcia 2018-07-10 6:48 ` Michael Olbrich 0 siblings, 1 reply; 8+ messages in thread From: Guillermo Rodriguez Garcia @ 2018-07-06 10:30 UTC (permalink / raw) To: ptxdist 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ptxdist] The second symbolic links are not copied to the target 2018-07-06 10:30 ` Guillermo Rodriguez Garcia @ 2018-07-10 6:48 ` Michael Olbrich 0 siblings, 0 replies; 8+ messages in thread From: Michael Olbrich @ 2018-07-10 6:48 UTC (permalink / raw) To: ptxdist 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-07-10 6:48 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-01 4:28 [ptxdist] The second symbolic links are not copied to the target Alejandro Vázquez 2018-07-05 8:25 ` Guillermo Rodriguez Garcia 2018-07-05 11:02 ` Alejandro Vázquez 2018-07-05 12:22 ` Michael Olbrich 2018-07-05 12:50 ` Guillermo Rodriguez Garcia 2018-07-06 9:54 ` Michael Olbrich 2018-07-06 10:30 ` Guillermo Rodriguez Garcia 2018-07-10 6:48 ` Michael Olbrich
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox