22.1.2011 11:15, Jacques Greindl kirjoitti:
Here are the details of the lib of the embedded system :
ls -ls /lib :
-rwxr-xr-x 1 root root 94543 Apr 25 2007 ld-2.2.4.so
lrwxrwxrwx 1 root root 11 Nov 9 2007 ld-linux.so.2
-> ld-2.2.4.so
-rwxr-xr-x 1 root root 1384168 Apr 25 2007 libc-2.2.4.so
lrwxrwxrwx 1 root root 13 Nov 9 2007 libc.so.6 ->
libc-2.2.4.so
This could be a RHL7.1 or RHL7.2 distro with updates, RHL7.3 without
updates, Debian Woody (3.0r5) or anything else...
I can copy all these libs on my computer, but then how to specify to
gcc to use this directory for shared lib instead of /lib ?
For RHL distros there were those 'compat-rhl7.1' etc. RPMS. Installing
one of them via 'rpm' or preferably first unpacking with something like:
rpm2cpio <the-RPM> | cpio -idmuvB
into some temporary place and seeing what one got before copying the
toolchain into its final place, would be the most easy route. Maybe
the current package handlers allow one to only unpack something but
if not, then knowing how to unpack '.rpm's and '.deb's manually is a
recommended know-how...
Generally downloading old RPMS or Debian packages for some old distro
and unpacking them for investigation before deciding what to do with
the stuff, shouldn't be any rocket science.
And will this solve my problem ? (which is: rebuild an program on a
new linux so that it will run on the embedded system,where there is no
compiler)
If you cannot tell the distro on the embedded board or the distro on
which the earlier program was built and then it ran ok on the possibly
different distro, then it is quite hard to help you :(
For instance I myself have both the RHL7.1 and RHL7.3 install CDs and
one can easily find them on the net. I have also the Debian 3.0r5 CDs
but couldn't easily find any Debian 3.0r5 stuff like its glibc-2.2.4
and gcc-2.95.4 on the net.
Anyhow for curiosity I unpacked the Debian 3.0r5 gcc-2.95.4 and
glibc-2.2.5 updates onto my CentOS 5.5 (no binutils) and tried
the toolchain with a simple program :
[root@localhost tprintf]# gcc-debian3.0r5 -v -Os -o tst_debian3.0r5
tprintf.c
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
/usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__
-D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix)
-D__OPTIMIZE_SIZE__ -D__OPTIMIZE__ -Acpu(i386) -Amachine(i386) -Di386
-D__i386 -D__i386__ tprintf.c /tmp/ccgcHRUF.i
GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
/usr/lib/gcc-lib/i386-linux/2.95.4/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
End of omitted list.
/usr/lib/gcc-lib/i386-linux/2.95.4/cc1 /tmp/ccgcHRUF.i -quiet
-dumpbase tprintf.c -Os -version -o /tmp/cc23BDBn.s
GNU C version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled
by GNU C version 2.95.4 20011002 (Debian prerelease).
as -V -Qy -o /tmp/cci3Ypck.o /tmp/cc23BDBn.s
GNU assembler version 2.17.50.0.6-14.el5 (i386-redhat-linux) using BFD
version 2.17.50.0.6-14.el5 20061020
/usr/lib/gcc-lib/i386-linux/2.95.4/collect2 -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o tst_debian3.0r5
/usr/i386-linux/lib/crt1.o /usr/i386-linux/lib/crti.o
/usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o
-L/usr/lib/gcc-lib/i386-linux/2.95.4 -L/usr/i386-linux/lib
-L/lib/i386-linux/2.95.4 /tmp/cci3Ypck.o -lgcc -lc -lgcc
/usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/i386-linux/lib/crtn.o
As can be seen, even a native GCC searches its target stuff from other
places first, the target headers from :
/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
aka
/usr/i386-linux/include
and the libs from :
/usr/i386-linux/lib
before searching the system ones, '/usr/include', '/usr/lib' and '/lib'.
In any case there are those '-nostdinc' and '-nostdlib' and '-I' / '-L'
etc. options for GCC if the native GCC also uses the same (here
'i386-linux') target name... Where a GCC will search as default can be
seen with the (should be) well-known '-print-search-dirs' option and
this option can be seen with the option '--help' which everyone should
at least know...
Getting the original '/lib' and '/usr/lib' stuff being seen in a single
'lib' maybe needs some advice, who knows... Anyhow, I unpacked all the
Debian 3.0r5 stuff into its own $sysroot :
/opt/host-Debian3.0r5_i386/lib
/opt/host-Debian3.0r5_i386/usr/include
/opt/host-Debian3.0r5_i386/usr/lib
etc
and then made the necessary symlinks so that the 2nd and 3rd '/usr'
directory were seen in the searched '/usr/i386-linux'. Furthermore
I fixed the existing symlinks in the original '/usr/lib', pointing
to '/lib' to point to '../../lib' (a normal glibc install should
use these relative links!) and added some new like for 'libc.so.6'
and 'ld-linux.so.2' and edited the 'libc.so' script to not have any
absolute pathnames for 'libc.so.6' and 'libc_nonshared.a'...
The original target binutils weren't unpacked (and then symlinked
to '/usr/i386-linux/bin'), but the system's own 'as' and 'ld' were
used with the old 'gcc', 'cc1' and 'collect2'... Quite often those
in some distro have used shared bfd and opcodes libs like in CentOS :
[root@localhost bin]# ldd as
linux-gate.so.1 => (0x00637000)
libbfd-2.17.50.0.6-14.el5.so =>
/usr/lib/libbfd-2.17.50.0.6-14.el5.so (0x0031d000)
libc.so.6 => /lib/libc.so.6 (0x00101000)
/lib/ld-linux.so.2 (0x00ccf000)
My self-made binutils have never required shared 'libbfd' or
'libopcodes', therefore this "feature" in the distro ones has
always been surprising... Problems expected with old binutils
from some distro :(
You could recreate the old GNU/Linux system. Old GNU/Linux distros are
easy to find on the web.
The Debian ones didn't seem to be there :( Ok, I didn't try googling,
only looked the main Debian archive and its mirrors in Finland and
Sweden.
So I have to :
1- find the glibc version of my embedded system
2- install this version on my actual system without erasing my actual one (how?)
3- compile my sources with gcc and a parameter to specify this version (how?)
The previous should give the answers. If you can tell the distro you
have (for instance via running '/libc/so.6' on the target system),
then it would be much easier to discuss about issues related to that
distro, where to find its GCC and glibc etc. RPMS or '.deb's...
Building glibc is nontrivial. But the basic idea is to build and
install glibc with a specific --prefix option, and use that directory as
a --with-sysroot option when building GNU binutils and gcc.
Neither I would recommend this. Relying on backwards compatibility
with the binutils, GCC etc. executables would be much easier, just
unpack them and see if they will run ok on the uptodate Linux system.
