* forestalling GNU incompatibility - proposal for binary relative dynamic linking
@ 2005-01-24 22:33 Edward Peschko
2005-01-24 22:56 ` Edward Peschko
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: Edward Peschko @ 2005-01-24 22:33 UTC (permalink / raw)
To: gcc, libc-alpha, binutils, linux-kernel
hey all,
Forgive the crosspost in advance, but I had an idea that touched many
areas, and would need input from multiple groups associated with the
gnu build chain, and perhaps the kernel itself.
After spending *two weeks* on various ways of building glibc,
I'm convinced that the gnu/linux toolchain is in great danger of
losing interoperability.
The main problem is that the glibc's supplied with each commercial
system are *heavily* patched. My Suse 9.2 system has a rpm for
glibc with fifty patches. Fifty patches!
Fifty patches which make the SuSE glibc binarily incompatible
with the redhat, and so on. And everything is incompatible
with the vanilla flavor.
All this makes me very skeptical that I'm ever going to get
to a 'standard' out of the box glibc build. I build a standard
glibc, and then all the supplied programs that come with SuSE
break. And each vendor has the same problem - new that they are
stuck with a heavily patched glibc, what chance do *they* have
of getting back to a standard with the need to have old programs
still work with the upgrades?
What IMO is desperately needed is a backwards compatibility
hack or hacks. And of course the will of the different linux
distribution providers to migrate back to the standard gnu
toolchain.
Below is such a hack that lets providers do this, and
solves quite a few problems in the process - the basic problem
being that one currently can't get from a nonstandard glibc to
a standard one without quite a bit of pain - for migrating back
breaks all the legacy binaries out there.
What is needed is the ability to reference multiple versions of the
glibc WITHOUT changing my environment to do so.
Ie: If I set up my LD_LIBRARY_PATH to reference:
setenv LD_LIBRARY_PATH /system/path/to/libc:.....
then the SuSE executables work fine but my new executables break,
and if I set up my LD_LIBRARY_PATH to reference:
setenv LD_LIBRARY_PATH /new/path/to/libc:.....
then my new executables work, but my *old* executables break.
What I'd like to do is be able to set up my LD_LIBRARY_PATH
so that I can reference it from the point of view of the
*executable*:
setenv LD_LIBRARY_PATH "*/../lib:....."
Here, read "* == full path of dirname of executable".
So if gcc was installed in say, "/opt/tools/bin/gcc",
LD_LIBRARY_PATH would become at runtime "/opt/tools/bin/../lib"
or "/opt/tools/lib". And hence if I had a libc.so installed
there, it would pick it up and use it.
Anyways, I have no idea whether or not this idea is being considered
or has been considered in the past, but AFAICT it would save me the
trouble of having hundreds of wrapper scripts. And I would like to
get an idea of what adding something like this to the gnu toolset would
require. Discussion is welcome..
Ed
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 22:33 forestalling GNU incompatibility - proposal for binary relative dynamic linking Edward Peschko
@ 2005-01-24 22:56 ` Edward Peschko
2005-01-24 23:08 ` Mike Frysinger
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Edward Peschko @ 2005-01-24 22:56 UTC (permalink / raw)
To: gcc, libc-alpha, binutils, linux-kernel
(
ps -
just to forestall a particular objection that was pointed out to me
- simply use chroot - I don't want a chroot environment. I want to
use both old binaries and new binaries seamlessly.
Ed
)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 22:33 forestalling GNU incompatibility - proposal for binary relative dynamic linking Edward Peschko
2005-01-24 22:56 ` Edward Peschko
@ 2005-01-24 23:08 ` Mike Frysinger
2005-01-24 23:20 ` Edward Peschko
2005-01-24 23:11 ` Richard Henderson
2005-01-28 11:20 ` Oldani Massimiliano
3 siblings, 1 reply; 10+ messages in thread
From: Mike Frysinger @ 2005-01-24 23:08 UTC (permalink / raw)
To: Edward Peschko; +Cc: gcc, binutils, linux-kernel, libc-alpha
On Monday 24 January 2005 05:24 pm, Edward Peschko wrote:
> After spending *two weeks* on various ways of building glibc,
> I'm convinced that the gnu/linux toolchain is in great danger of
> losing interoperability.
sounds like what you want is already being tackled by OSDL and their Binary
Regression Testing group ...
http://groups.osdl.org/apps/group_public/workgroup.php?wg_abbrev=binary_sig
http://www.osdl.org/docs/isv_issues_and_binary_testing.pdf
-mike
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 22:33 forestalling GNU incompatibility - proposal for binary relative dynamic linking Edward Peschko
2005-01-24 22:56 ` Edward Peschko
2005-01-24 23:08 ` Mike Frysinger
@ 2005-01-24 23:11 ` Richard Henderson
2005-01-24 23:25 ` Edward Peschko
2005-01-28 11:20 ` Oldani Massimiliano
3 siblings, 1 reply; 10+ messages in thread
From: Richard Henderson @ 2005-01-24 23:11 UTC (permalink / raw)
To: Edward Peschko; +Cc: gcc, libc-alpha, binutils, linux-kernel
On Mon, Jan 24, 2005 at 02:24:49PM -0800, Edward Peschko wrote:
> What I'd like to do is be able to set up my LD_LIBRARY_PATH
> so that I can reference it from the point of view of the
> *executable*:
>
> setenv LD_LIBRARY_PATH "*/../lib:....."
>
> Here, read "* == full path of dirname of executable".
See -Wl,-rpath,'$ORIGIN/../lib/'
r~
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 23:08 ` Mike Frysinger
@ 2005-01-24 23:20 ` Edward Peschko
0 siblings, 0 replies; 10+ messages in thread
From: Edward Peschko @ 2005-01-24 23:20 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gcc, binutils, linux-kernel, libc-alpha
On Mon, Jan 24, 2005 at 06:08:52PM -0500, Mike Frysinger wrote:
> On Monday 24 January 2005 05:24 pm, Edward Peschko wrote:
> > After spending *two weeks* on various ways of building glibc,
> > I'm convinced that the gnu/linux toolchain is in great danger of
> > losing interoperability.
>
> sounds like what you want is already being tackled by OSDL and their Binary
> Regression Testing group ...
> http://groups.osdl.org/apps/group_public/workgroup.php?wg_abbrev=binary_sig
> http://www.osdl.org/docs/isv_issues_and_binary_testing.pdf
> -mike
well of course the osdl is going to focus on this, but they need tools
and functionality to do it correctly..
In particular, the statement 'Vendor lock-in (at any level) is not
desirable' is false - there *is* vendor lock-in, and the suggestion
of relative pathing for LD_LIBRARY_PATH is just one way to migrate
back to doing things the right way.
Distributions are basically hoist by their own petard - they need to
support old legacy executables, which have nonstandard glibc's. And since
they need to support legacy executables in the past, they need
to support them in the future.
What I'd envision is that the distributions split basically into two:
executables using the old style glibc/libraries, and executables using the
new, standard glibcs. There would be two paths,
/usr/bin
and
/usr/standard/bin
The first directory would contain old executables which haven't been ported to
the standard glibc. The second would contain executables that have. The relative
pathing in LD_LIBRARY_PATH would insure that each tree used the correct libraries.
In the process of making /usr/standard/bin, linux vendors would need
to make their rpms both path-neutral and build clean. However, they would
*not* need to hold up their release process until everything is ported -
they could pick and choose which applications were the most important to
port. Ultimately, /usr/standard/bin would go away, and be moved back to
/usr/bin, and perhaps the cycle could begin again, with upgrades going into
a new /usr/standard/bin.
Ed
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 23:11 ` Richard Henderson
@ 2005-01-24 23:25 ` Edward Peschko
2005-01-24 23:38 ` Richard Henderson
0 siblings, 1 reply; 10+ messages in thread
From: Edward Peschko @ 2005-01-24 23:25 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc, libc-alpha, binutils, linux-kernel
On Mon, Jan 24, 2005 at 03:10:47PM -0800, Richard Henderson wrote:
> On Mon, Jan 24, 2005 at 02:24:49PM -0800, Edward Peschko wrote:
> > What I'd like to do is be able to set up my LD_LIBRARY_PATH
> > so that I can reference it from the point of view of the
> > *executable*:
> >
> > setenv LD_LIBRARY_PATH "*/../lib:....."
> >
> > Here, read "* == full path of dirname of executable".
>
> See -Wl,-rpath,'$ORIGIN/../lib/'
>
>
> r~
cool.. any chance for some syntactic sugar so me (and other
users/vendors) wouldn't need to change any of their build scripts
and compilation processes?
The only thing I would see as a drawback would be backwards compatibility,
but how often do people have directories named '*'?
Ed
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 23:25 ` Edward Peschko
@ 2005-01-24 23:38 ` Richard Henderson
2005-01-25 0:01 ` Edward Peschko
0 siblings, 1 reply; 10+ messages in thread
From: Richard Henderson @ 2005-01-24 23:38 UTC (permalink / raw)
To: Edward Peschko; +Cc: gcc, libc-alpha, binutils, linux-kernel
On Mon, Jan 24, 2005 at 03:16:36PM -0800, Edward Peschko wrote:
> cool.. any chance for some syntactic sugar so me (and other
> users/vendors) wouldn't need to change any of their build scripts
> and compilation processes?
Uh, like what? That's about as simple as you can get.
r~
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 23:38 ` Richard Henderson
@ 2005-01-25 0:01 ` Edward Peschko
2005-01-25 0:29 ` Daniel Jacobowitz
0 siblings, 1 reply; 10+ messages in thread
From: Edward Peschko @ 2005-01-25 0:01 UTC (permalink / raw)
To: Richard Henderson; +Cc: gcc, libc-alpha, binutils, linux-kernel
On Mon, Jan 24, 2005 at 03:38:49PM -0800, Richard Henderson wrote:
> On Mon, Jan 24, 2005 at 03:16:36PM -0800, Edward Peschko wrote:
> > cool.. any chance for some syntactic sugar so me (and other
> > users/vendors) wouldn't need to change any of their build scripts
> > and compilation processes?
>
> Uh, like what? That's about as simple as you can get.
>
>
> r~
I don't understand.
Which is simpler, changing an environmental variable, or adding extra
CFLAGS to every single compile and recompiling?
In addition, in your --rpath example, the relative pathing is hardcoded
into the executable, wheras with "*" you could modify the runtime behavior
of the executable at runtime. I suppose you could change this with chrpath,
but why bother? What if you want to test out two versions of relative
libraries side by side?
And in any case, I'm not even sure if you can change the runtime path
to something longer than what currently exists in the executable using
chrunpath.
And finally, certain programs (glibc, for example) seem to get into to
trouble (ie: not compile) when you use --rpath flags. So, what's the
issue with "*"?
Ed
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-25 0:01 ` Edward Peschko
@ 2005-01-25 0:29 ` Daniel Jacobowitz
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2005-01-25 0:29 UTC (permalink / raw)
To: Edward Peschko; +Cc: Richard Henderson, gcc, libc-alpha, binutils, linux-kernel
On Mon, Jan 24, 2005 at 03:53:11PM -0800, Edward Peschko wrote:
> On Mon, Jan 24, 2005 at 03:38:49PM -0800, Richard Henderson wrote:
> > On Mon, Jan 24, 2005 at 03:16:36PM -0800, Edward Peschko wrote:
> > > cool.. any chance for some syntactic sugar so me (and other
> > > users/vendors) wouldn't need to change any of their build scripts
> > > and compilation processes?
> >
> > Uh, like what? That's about as simple as you can get.
> >
> >
> > r~
>
> I don't understand.
>
> Which is simpler, changing an environmental variable, or adding extra
> CFLAGS to every single compile and recompiling?
>
> In addition, in your --rpath example, the relative pathing is hardcoded
> into the executable, wheras with "*" you could modify the runtime behavior
> of the executable at runtime. I suppose you could change this with chrpath,
> but why bother? What if you want to test out two versions of relative
> libraries side by side?
You might want to take a look at Richard's suggestion again. The
string '$ORIGIN' gets hardcoded into the binary and handled by the
dynamic linker.
But really, RPATH is a good solution to almost no problems.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking
2005-01-24 22:33 forestalling GNU incompatibility - proposal for binary relative dynamic linking Edward Peschko
` (2 preceding siblings ...)
2005-01-24 23:11 ` Richard Henderson
@ 2005-01-28 11:20 ` Oldani Massimiliano
3 siblings, 0 replies; 10+ messages in thread
From: Oldani Massimiliano @ 2005-01-28 11:20 UTC (permalink / raw)
To: binutils
On Mon, Jan 24, 2005 at 02:24:49PM -0800, Edward Peschko wrote:
> ....
> What is needed is the ability to reference multiple versions of the
> glibc WITHOUT changing my environment to do so.
>
>
> Ie: If I set up my LD_LIBRARY_PATH to reference:
>
> setenv LD_LIBRARY_PATH /system/path/to/libc:.....
>
>
> then the SuSE executables work fine but my new executables break,
> and if I set up my LD_LIBRARY_PATH to reference:
>
> setenv LD_LIBRARY_PATH /new/path/to/libc:.....
>
> then my new executables work, but my *old* executables break.
>
>
> What I'd like to do is be able to set up my LD_LIBRARY_PATH
> so that I can reference it from the point of view of the
> *executable*:
>
> setenv LD_LIBRARY_PATH "*/../lib:....."
>
>
>
>
> Here, read "* == full path of dirname of executable".
>
> So if gcc was installed in say, "/opt/tools/bin/gcc",
> LD_LIBRARY_PATH would become at runtime "/opt/tools/bin/../lib"
> or "/opt/tools/lib". And hence if I had a libc.so installed
> there, it would pick it up and use it.
>
>
>
> Anyways, I have no idea whether or not this idea is being considered
> or has been considered in the past, but AFAICT it would save me the
> trouble of having hundreds of wrapper scripts. And I would like to
> get an idea of what adding something like this to the gnu toolset would
> require. Discussion is welcome..
>
>
> Ed
>
Using LD_LIBRARY_PATH is not always rialable, it`s not always possible to use it,
for example for SUID/SGID binary and so..?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-01-28 11:20 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-24 22:33 forestalling GNU incompatibility - proposal for binary relative dynamic linking Edward Peschko
2005-01-24 22:56 ` Edward Peschko
2005-01-24 23:08 ` Mike Frysinger
2005-01-24 23:20 ` Edward Peschko
2005-01-24 23:11 ` Richard Henderson
2005-01-24 23:25 ` Edward Peschko
2005-01-24 23:38 ` Richard Henderson
2005-01-25 0:01 ` Edward Peschko
2005-01-25 0:29 ` Daniel Jacobowitz
2005-01-28 11:20 ` Oldani Massimiliano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).