This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: forestalling GNU incompatibility - proposal for binary relative dynamic linking


On Mon, Jan 24, 2005 at 07:29:39PM -0500, Daniel Jacobowitz wrote:
> 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.

Ok, mea culpa, I've been talking faster than my brain is working.. 
True enough, I see that now. But with that solution you still have the 
issues with changing your build processes and a recompile. Plus it isn't
exactly the simplest solution out there.

Anyways, I'm toning this down a notch. I wasn't sure at first which 
group it would belong to, but it looks like it would be involving gcc 
and libc so I'll limit it to there.

> But really, RPATH is a good solution to almost no problems.

A fair enough statement to make, but why? AFAICT, it would allow me to 
have two truly separate trees and two truly separate libc.sos simultaneously.
Given how configure works, the lib corresponding to a bin for a given system 
is almost always equal to "*/../lib"..

Ed


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]