Re: Powerpc-eabi, bootstrap compilers...

[Kai Ruottu <kai dot ruottu at luukku dot com>]

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

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com