This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |