Bug#930884: marked as done (feature request: with Windows and FreeBSD and MacOS desktop, you can ship the libraries together with your application. With Linux desktop: still not :-(.)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Bug#930884: marked as done (feature request: with Windows and FreeBSD and MacOS desktop, you can ship the libraries together with your application. With Linux desktop: still not :-(.)

Debian Bug Tracking System
Your message dated Thu, 27 Jun 2019 10:15:15 +0200
with message-id <[hidden email]>
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 [hidden email]
immediately.)


--
930884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930884
Debian Bug Tracking System
Contact [hidden email] with problems


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

Hi,

On 2019-06-21 22:37, [hidden email] 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
[hidden email]                 http://www.aurel32.net