Your message dated Thu, 27 Jun 2019 10:15:15 +0200 with message-id <20190627081515.ga11...@aurel32.net> and subject line Bug#930884: feature request: with Windows and FreeBSD and MacOS desktop, you can ship the libraries together with your application. With Linux desktop: still not :-(. has caused the Debian Bug report #930884, regarding feature request: with Windows and FreeBSD and MacOS desktop, you can ship the libraries together with your application. With Linux desktop: still not :-(. to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 930884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930884 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: ld-linux.so.X When we, I, write an application on Linux, we do installation from the repositories (or even the installation of "-dev" packages in addition if "soft symlink" is missing) for the needed shared libraries (fore exeample: Firebird, ...). But, once the application is finished, I will uninstall everything about Firebird, and from the content of the download of its *.tar.gz, I must create a client installation with AppImage + its yaml scripts (my choice). It's not so easy. The problem is that on *nix the escape like on Window or MacOS ( putting dlls together with the application !!!) doesn't work, making versioning issues more complex, specially when using official packaging systems ==> "DLL-hell" now only exists under *nix \ Linux. Can Linux improve its binary compatibility and be less forced in its package management (specially: versioning on Desktop. It's really always "DLL-hell": if you want to start distributing the libraries\packages and resulting files apart, on Linux Desktop, then you get into the dependency problems). Honestly, I think that the Linux ELF's program loader ( ld-linux.so.X ), on Linux idiosyncrasy directories, would require an evolution that would make Linux as convenient as Windows or MacOS from the point of view of desktop developments, i. e. starting by ***first*** looking in the same directory as the loaded application, if the NEEDED library would not be there, by the best of luck. -- Best regards
--- End Message ---
--- Begin Message ---Hi, On 2019-06-21 22:37, eric.mou...@laposte.net wrote: > > Package: ld-linux.so.X > > When we, I, write an application on Linux, we do installation from the > repositories (or even the installation of "-dev" packages in addition if > "soft symlink" is missing) for the needed shared libraries (fore exeample: > Firebird, ...). > But, once the application is finished, I will uninstall everything about > Firebird, and from the content of the download of its *.tar.gz, I must create > a client installation with AppImage + its yaml scripts (my choice). It's not > so easy. > The problem is that on *nix the escape like on Window or MacOS ( putting dlls > together with the application !!!) doesn't work, making versioning issues > more complex, specially when using official packaging systems ==> "DLL-hell" > now only exists under *nix \ Linux. > > Can Linux improve its binary compatibility and be less forced in its package > management (specially: versioning on Desktop. It's really always "DLL-hell": > if you want to start distributing the libraries\packages and resulting files > apart, on Linux Desktop, then you get into the dependency problems). > > Honestly, I think that the Linux ELF's program loader ( ld-linux.so.X ), on > Linux idiosyncrasy directories, would require an evolution that would make > Linux as convenient as Windows or MacOS from the point of view of desktop > developments, i. e. starting by ***first*** looking in the same directory as > the loaded application, if the NEEDED library would not be there, by the best > of luck. While I think it's a bad idea, especially from security point of view, what you ask is already implemented on GNU/Linux for many years. This feature is called rpath, and allows one to provide a list of paths where to look for the NEEDED libraries. You can use the $ORIGIN keyword to specify a path relative to the binary, which is exactly what you want. For example: $ gcc -o main ./main.c -lz $ ldd ./main linux-vdso.so.1 (0x00007ffda8dd7000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fda95b4f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda9598e000) /lib64/ld-linux-x86-64.so.2 (0x00007fda95dc6000) $ gcc -o main ./main.c -lz -Wl,-rpath,'$ORIGIN' $ ldd ./main linux-vdso.so.1 (0x00007fff379f2000) libz.so.1 => /tmp/./libz.so.1 (0x00007f9fb52e7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9fb50d4000) /lib64/ld-linux-x86-64.so.2 (0x00007f9fb550c000) The feature you requested being already implemented, I am closing the bug. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
--- End Message ---
