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 (0x7ffda8dd7000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fda95b4f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fda9598e000)
/lib64/ld-linux-x86-64.so.2 (0x7fda95dc6000)
$ gcc -o main ./main.c -lz -Wl,-rpath,'$ORIGIN'
$ ldd ./main
linux-vdso.so.1 (0x7fff379f2000)
libz.so.1 => /tmp/./