[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 :-(.)

Your message dated Thu, 27 Jun 2019 10:15:15 +0200
with message-id <20190627081515.GA11568@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 owner@bugs.debian.org
immediately.)


-- 
930884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930884
Debian Bug Tracking System
Contact owner@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.moutie@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
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: