This is the mail archive of the crossgcc@sources.redhat.com 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] |
That's exactly why I suggested using LD_RUN_PATH setenv'd to /usr/local/lib when creating your compiler and tools. it has the same effect than -rpath Joe Sislow wrote: > Kai Ruottu wrote: > > > Rodney, here are something for you too... > > > > Joe Sislow wrote: > > > > > > Joe Sislow wrote: > > > > > > > Well, what it turns out was going on was that my glibc stuff in /lib was version 2.2.2, and > > > > I had installed 2.2.4 to /usr/local/lib. So, I just set the LD_LIBRARY_PATH to > > > > /usr/local/lib, and they all run just fine! BTW, I avoided installing them to /usr as many > > > > of the FAQ's on installing glibc said it might be a bad idea. > > > > > > > > Thanks all! You've been very helpful! > > > > > > > Well, it wasn't that easy. That DOES get the binutils working, but it proceeds to mess a > > > LOT of other things up. I've been using: > > > > > > binutils-2.11.2 > > > glibc-2.2.4 > > > gcc-2.95.3 > > > > > > My system seems to have glibc 2.2.2 installed (found by checking /lib/libc.so.6). It seems > > > that the binutils I'm using wants 2.2.3 or more...how do I get IT to use the 2.2.4 I have in > > > /usr/local without fubaring everything else? When I set LD_LIBRARY_PATH to /usr/local/lib, > > > things start crashing all over the place. Ideas? > > > > Haven't tried this, but my thought is that those '-dynamic-linker <libdir>' and '-rpath <libdir>' > > options given to the linker should control where the produced executables will search the dynamic > > linker file and the shared libs (first) at run-time : > > > > --------------------------- clip --------------------------------- > > ld --help > > Usage: ld [options] file... > > Options: > > -a KEYWORD Shared library control for HP/UX compatibility > > -A ARCH, --architecture ARCH > > Set architecture > > <snip> > > > > --demangle Demangle symbol names > > --dynamic-linker PROGRAM Set the dynamic linker to use <------------- > > --embedded-relocs Generate embedded relocs > > > > <snip> > > > > --retain-symbols-file FILE Keep only symbols listed in FILE > > -rpath PATH Set runtime shared library search path <------ > > -rpath-link PATH Set link time shared library search path > > --------------------------- clip --------------------------------- > > > > The '-rpath-link' then tells where the '.so' stuff will be searched (first) > > at link-time... > > > > I'm still searching a better way to look at these 'hard-wired' things in the > > executables, but the 'objdump -p' is now my way to see the needed shared-libs > > and 'strings' (aren't there any better way?) to see the 'hard-wired' dynamic- > > linker and its place. > > > > Anyway using the '-dynamic-linker' and '-rpath' to set non-default search > > paths using something like: > > > > --------------------------- clip --------------------------------- > > gcc-ppc-linux -v -Os \ > > -Wl,-dynamic-linker,/usr/local/lib/ld.so.1,-rpath,/usr/local/lib \ > > -o tst_ppc-linux.x tprintf.c > > --------------------------- clip --------------------------------- > > > > one then gets with 'strings' : > > > > --------------------------- clip --------------------------------- > > strings tst_ppc-linux.x | less > > /usr/local/lib/ld.so.1 <----------- > > __gmon_start__ > > libc.so.6 > > strcpy > > printf > > stdout > > puts > > fflush > > strcat > > .... > > --------------------------- clip --------------------------------- > > > > and with 'objdump -p' : > > > > --------------------------- clip --------------------------------- > > Dynamic Section: > > NEEDED libc.so.6 > > RPATH /usr/local/lib <----------- > > INIT 0x10000de4 > > FINI 0x10000e08 > > HASH 0x10000150 > > STRTAB 0x10000254 > > SYMTAB 0x10000194 > > --------------------------- clip --------------------------------- > > > > instead of the normal '/lib/ld.so.1' and RPATH undefined (so using > > the defaults)... > > > > So one can produce executables which search these things somewhere else > > than in the default places. > > > > Perhaps the '/usr/local' is not a suitable place for the 'another glibc', > > if still wanting to produce stuff using the original glibc, because the > > native compiler tries to find stuff also there, even first. I prefer to > > just build a cross-compiler (like '--host=i586-linux --target=i486-linux') > > to have the 'another' glibc... > > > > I have quite a similar situation now: I have a 'generic' i486-linux-gnu > > targeted GCC with glibc-2.1.3 and glibc-2.2.4 built for it, but my native > > GCC and Linux (RedHat 7.1) use glibc-2.2.2. So the possibility to produce > > older, RH 6.2 compatible and newer 2.2.4-dependent executables exists... > > (Ok, there was the RedHat's own 'compatability' stuff without static libs > > but I had this own stuff before updating to RH 7.1...) > > > > But my thought is that the run-time host will either be a RH 6.2-like or > > Suse 7.3 / RedHat 7.2 etc. like which uses glibc-2.2.4 as default, not > > that I would try to run the glibc-2.2.4-based executables under RH 7.1... > > As the matter of fact, I produce almost everything by linking against > > glibc-2.1.3, so if I need to copy stuff into the older Linux'es, it should > > run there... > > Ok, this sounds like it *might* work, except it's my linker that's having trouble running! So, does > this mean that for some reason I'm going to have to try and hack the Makefiles for creating a cross > compiler normally? I mean, the makefiles don't do the -dynamic-linker and -rpath stuff. Plus, the > makes nest around the configure script. I'm not sure if what needs to get passed will get passed. > > I don't really care whether my binutils work with 2.2.2 or 2.2.4 or whatever, as long as I can tell > them where to find their libraries. > > Basically, I can't totally figure out why when I do this: > > cd build-binutils > ../binutils-2.11.2/configure --target=powerpc-eabi --prefix=/cross/powerpc-eabi > make all install > > And then it makes the binutils successfully, but it wants different libraries. Why is this? If > I have the shared libraries on my system, currently running Redhat 7.1 with 2.2.2 as you do, Kai. > The only possible weirdness I can think is that I upgraded my kernel to 2.4.12. Could this have set > things up weirdly? > > %%%%%%%%%%%%%%%%%%%%%%%%%%%% > Joe Sislow > Cosmodog, Ltd. > joe@cosmodog.com > > ------ > Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ > Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |