creating relocatable binutils

[Maurizio Vitale]

Thanks Mike!

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.
Applications compiled by the end user can of course use shared
libraries.

>> 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.

> ./bin/as -> rpath of $ORIGIN/../lib/
> ./lib/libbfd.so....
>
>> Another way is to force gcc to set  LD_LIBRARY_PATH before calling ld or
>> as. In my case I can assume that the gcc installed location will be
>> related to binutils' in a known way and I could derive the right
>> LD_LIBRARY_PATH setting. But this approach doesn't look nice.
>
> no, that's an awful idea.  dont do it!

I know, I know. Was there just for the sake of completeness. :-)
"doesn't look nice' was an euphemism. 'awful idea' just begins to
describe it.

-- 
Maurizio Vitale
Polymath Solutions


--
For unsubscribe information see http://sourceware.org/lists.html#faq