Re: creating relocatable binutils

[Mike Frysinger <vapier at gentoo dot org>]

On Thursday 12 February 2009 16:17:50 Maurizio Vitale wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On Thursday 12 February 2009 14:53:04 Maurizio Vitale wrote:
> >> I've been able to get relocatable rpms for binutils by linking the
> >> binutils executables statically, but this is not ideal (to be honest I
> >> haven't benchmarked real compilation to see whether it really makes a
> >> difference and the difference in size doesn't bother me at all).
> >>
> >> Dynamic linking would require the user (or rpm, but this is immaterial)
> >> to run ldconfig on relocated binutils' lib directory (where libopcodes
> >> and libbfd live). Unfortunately this requires root permissions.
> >
> > you dont need to statically link the entire program, just dont build
> > shared library versions of the binutils libs.  many distros do not. 
> > statically linking in libbfd and libopcodes really isnt that big of a
> > deal with these few apps.
>
> I was referring to statically link libbfd and libopcodes into as, ld and
> friends.

OK, i think this is what you should do

> Applications compiled by the end user can of course use shared
> libraries.

let's make sure we're clear here ... shared libraries in general -> OK.  end 
user apps linking against shared libbfd and libopcodes from your toolchain -> 
not OK.

> >> One way I see is to use -rpath whan compiling binutils, but
> >> (although I haven't tested it) I believe the rpath must be an absolute
> >> directory, which makes this solution unsuitable for me (only the end
> >> user would know the final destination).
> >
> > if you use $ORIGIN, you can give it a relative path.  then the assumption
> > is that the relative path from the executable to the shared libs will
> > always be the same (and it sounds like that is an assumption you can
> > make).
>
> Yes, I can live with this limitation and the end users will have to :-)
>
> I was not aware of $ORIGIN. This will be a nice plan B if the
> size/performance of the statically linked as/ld will be too much.
> Thanks a lot for the hint.

i really doubt you'll see any kind of measurable performance difference.  i'd 
also point out that statically linked code on x86 will execute faster than 
shared code (register pressure due to %ebx being the dedicated PIC register).  
there will just be memory wasting due to the duplicated data (and perhaps some 
initial time lost during load due to duplicated text).  but if you look at 
libbfd and libopcodes, they'll contribute less than a meg combined to the 
final image.  one meg on todays hardware ?  that's irrelevant and not worth 
your time fighting shared library paths.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.