This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Configuration problem? (resembles of FAQ #2.8)
- To: "'glibc-linux at ricardo dot ecn dot wfu dot edu'" <glibc-linux at ricardo dot ecn dot wfu dot edu>
- Subject: Configuration problem? (resembles of FAQ #2.8)
- From: Ambrus Michael <Michael dot Ambrus at elema dot siemens dot se>
- Date: Wed, 10 Oct 2001 13:04:15 +0200
- Cc: "'michael dot ambrus at home dot se'" <michael dot ambrus at home dot se>, Ambrus Michael <Michael dot Ambrus at elema dot siemens dot se>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
Hi all,
I have problem that resembles of #2.8 in the glibc FAQ at gnu.org
(http://www.gnu.org/software/libc/FAQ.html#s-2.8):
When searching this list archive I found only one topic that comes even
close to my problem (I hope I'm not wrong ):
http://sources.redhat.com/ml/glibc-linux/2000-q2/msg00135.html . The
reason/solution however, seems to be far away from mine.
=x==
2.8. When I run an executable on one system which I compiled on another, I
get dynamic linker errors. Both systems have the same version of glibc
installed. What's wrong?
=x==
The reason for wanting to do this strange stuff, is not quite the same as
what is assumed in the answer/solution to this FAQ entry.
What I want to do is the following:
====================================
I have a very small x86 target (actually AMD SC400), a so called embedded
target, that comes with a 2.2.5 kernel and a tiny file-system on a flash
PROM. I'll refer to this system as the 'target' hereby.
The system I use for development is a ordinary RH7.0 running on a PIII and
I'll refer to this system as the 'host'.
The target has a very limited set of commands and tools (no 'ldd' and no
'ldconfig' among others). However, judging by the filenames in /lib, I
conclude that the system is made for supporting libc 6. This is the same
version that my host system runs, and I figure that executables built on my
host should run flawlessly on both systems.
Below is a snippet of the library contents of /lib the two (the target has
no /usr/lib except terminfo/ b.t.w.)
On 'host':
=======
[mambrus@pc1409 /lib]$ ls -al /lib/libc*.*
-rwxr-xr-x 1 root root 4776568 Aug 30 2000 /lib/libc-2.1.92.so
lrwxrwxrwx 1 root root 14 Jul 3 12:44 /lib/libc.so.6 ->
libc-2.1.92.so
lrwxrwxrwx 1 root root 17 Jul 3 12:44 /lib/libcom_err.so.2
-> libcom_err.so.2.0
-rwxr-xr-x 1 root root 8410 Aug 30 2000
/lib/libcom_err.so.2.0
-rwxr-xr-x 1 root root 80717 Aug 30 2000
/lib/libcrypt-2.1.92.so
lrwxrwxrwx 1 root root 18 Jul 3 12:44 /lib/libcrypt.so.1
-> libcrypt-2.1.92.so
On 1486 'target':
============
# ls -l libc*.*
-rwxr-xr-x 1 root root 1286208 Dec 8 1999 libc-2.1.1.so
lrwxrwxrwx 1 root root 13 Jul 12 2000 libc.so.6 ->
libc-2.1.1.so
-rwxr-xr-x 1 root root 25818 Dec 8 1999 libcrypt-2.1.1.so
lrwxrwxrwx 1 root root 17 Jul 12 2000 libcrypt.so.1 ->
libcrypt-2.1.1.so
=X==
Now, if I build a program (called MyProg) on the host it will run without
problems on the host, but when invoked on the target I'll get the following
error:
./MyProg: /lib/libc.so.6: version `GLIBC_2.1.3' not found (required by
./MyProg)
I'm confused - none of the systems have any libc file version 2.1.3 . Where
does this reference come from? Could it be to a faulty 'soname' made by the
ones that built the library? In that case, on which system?
I can't run ldconfig on the target since it's not there, and when If try to
run the command via a mounted NFS dir, the system gives up and dies
(something about an illegal instruction).
I dare not to hack the targets /etc/ld.so.cache by hand since I don't know
neither the format nor what is broken, so I tried to create links pointing
to lib-2.1.1.so (from various names) with no luck.
All other binaries on each system runs with no problem (as long as they stay
on the system that harbours them). What could be the problem & any
suggestions of how to solve it?
Best Regards
Michael Ambrus
Siemens Elema - LSS
SWEDEN
P.S. If you wonder why I'm not setting up a cross environment, it's because
I'm lacking the @£#! needed header files of the target :-( I'm on to that
to, but that's a different story. D.S. /Michael