Re: [ian@airs.com: Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking]

[Edward Peschko <esp5 at pge dot com>]

On Wed, Jan 26, 2005 at 09:14:52PM -0800, Dan Kegel wrote:
> Edward Peschko wrote:
> >If I made changes that did the following:
> >
> >   1) allowed for "*" in LD_LIBRARY_PATH to reference the path of 
> >      the executable being run, to be used by ldd, ld.so, etc. 
> >      to determine which libraries to use at runtime for a given 
> >      executable.
> >
> >    2) allowed for "*" in LD_RUN_PATH to be used in the same way
> >       for the linker.
> >
> >would they be accepted as part of the 'standard' part of these tools? 
> >(assuming lots of testing, etc). 
> 
> Before you propose this change, please also include the use case
> that's driving you to propose it.  I understand your use case is:
> 
>   A developer is building a large set of applications to run
>   on a wide variety of x86 Linux systems.  He wants the same
>   binary to run unchanged on all these x86 Linux systems.
>   He also cannot use the system version of glibc on his build
>   system because it might be newer than that on some target systems.
>   He cannot ship statically-linked versions of his applications because
>   [fill in the blank here ].
>   He cannot link his applications against the oldest version of
>   glibc on all target systems because [ fill in the blank here ].
>   He cannot develop against the LSB because [ fill in the blank here ].
>   Thus he must ship a custom glibc shared library with his applications,
>   and needs to be able to tell the shared library loader on the target
>   system to use his custom glibc shared library when loading the 
>   applications.

Well, you got it right but backwards. For the most part, I'm not 
developing applications, I'm compiling them.

"A developer is compiling a large set of applications that he doesn't
 control, and hence may or may not be LSB compliant. He cannot expect
 the oldest version of glibc to apply because the applications may
 depend on newer glibc features. He does not have root, so therefore
 cannot develop in a chroot environment.

 Furthermore, one of the things that he is doing is migrating from an older
 version of glibc to a newer one, and wants both the freedom of doing
 it without trashing his environment, and not having to rebuild his programs 
 from scratch to test versus two versions of glibc.
"

However, it occurs to me that the patch alone would not be enough..
apparently the ld.so interface heeps changing, which makes it currently 
impossible to use any system libraries unrelated to the current glibc.

My question is: why does this interface keep changing? Could it be 
stabilized?

Ed