public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Edward Peschko <esp5@pge.com>
To: gcc@gcc.gnu.org, libc-alpha@sources.redhat.com,
	binutils@sources.redhat.com, linux-kernel@vger.kernel.org
Subject: forestalling GNU incompatibility - proposal for binary relative dynamic linking
Date: Mon, 24 Jan 2005 22:33:00 -0000	[thread overview]
Message-ID: <20050124222449.GB16078@venus> (raw)

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

             reply	other threads:[~2005-01-24 22:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-24 22:33 Edward Peschko [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050124222449.GB16078@venus \
    --to=esp5@pge.com \
    --cc=binutils@sources.redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sources.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).