Re: Powerpc-eabi, bootstrap compilers...

[Joe Sislow <flynn at cosmodog dot com>]

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