Hayden Thring wrote:
thanks for the prompt reply and information, just afetr i posted this i got working a arm-linux 2.95.3 (fpa) crosschain from handhelds.org and cross compiled glibc with that resulting in a fpa glibc :)
so i just copy that over to my host/target and "hook" it into my bootstrap gcc via the specs file and it works :)
alternatively i could have copied a glibc from another source such as debian but i was worried that i needed one compiled for the prefix it would reside at on my target... perhaps this is not an issue ?? as i did download a debian glibc earlier on but felt it could only go in / and this stuffed up my current glibc and subsequently the whole system resulting in a re-flash of the os.
As default those "native" packages are trying to go onto the native
places, for instance a glibc onto '/lib', '/usr/include', '/usr/lib' etc.
But unpacking a '.deb' (ar x package.deb ; tar xvf data.tar.gz) can be
done anywhere and then be copied somewhere else. The
question only is whether the binutils, especially 'ld', and the GCC will
find it from there. There is no '--with-sysroot=something'
for gcc-2.95.3 so this problem must be solved otherwise. Seemingly you
tailored the 'specs'...
In a native glibc there is at least that 'libc.so' problem, it is a
linker script telling '/lib/libc.so.6 /usr/lib/libc_nonshared.a' as default
and without that '--with-sysroot=$sysroot' these places and files are of
course used. So it must be edited by taking the absolute
paths away and leaving only the file names there so the linker could
decide from where these files will be taken...
At runtime those native places and the native stuff,
'/lib/ld-linux.so.2', '/lib/libc.so.6' etc. will be used by the
executable if there is
no custom '--dynamic-linker something -rpath something' in the 'specs'
to tell otherwise (the first for the 'ld-linux.so.2' or its
equivalent, some Linuces use a different name, and the second for the
runtime shared libraries). These both options could be in
that customized 'specs', the default '--dynamic-linker
/lib/ld-linux.so.2' or something option is there always...
So the GCC and binutils configures ('--prefix=$prefix') will tell where
the C headers and libraries are searched from at link-time
but for the run-time behaviour of the produced executables the
'--dynamic-linker ' and the '-rtpath' options give to the linker
will make sure that some non-native place for the C runtimes will be
used. One could also try some environment settings but
they most probably will cause all executables to follow them meanwhile
"hardwiring" the previous info into some executables
will make them as "dissident" - they will think otherwise in relation to
the runtime stuff... The case with the 'libc.so' - and with
'libpthread.so' in newer glibcs - may be the only one(s) requiring
"native" install places.
as for the objdump examples, i did test the glibc see files but gave gcc examples in the post indirectly.
With 'readelf -l' the place to search for the dynamic linker can be
seen (the INTERP header), with 'objdump -h' the added
RPATH in those 'dissidents' as executables....
Ok, changing the '--dynamic-linker' option and adding the '-rpath'
option into the 'specs' would be what I would try if needing
to experiment with an "alternative glibc" (at runtime) while still
keeping the original glibc in its native places...
