This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: ./a.out: symbol errno, version GLIBC_2.0 not defined
- From: Kai Ruottu <karuottu at mbnet dot fi>
- To: Pramod P K <pra dot engr at gmail dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Thu, 27 Oct 2005 20:10:18 +0300
- Subject: Re: ./a.out: symbol errno, version GLIBC_2.0 not defined
- References: <417f1b740510270826h3c9f2aabw79a515db5195b08c@mail.gmail.com>
- Reply-to: karuottu at mbnet dot fi
Pramod P K wrote:
when I compile using my new arm-9tdmi-linux-gnu-gcc, why
../a.out: relocation error: ./a.out: symbol errno, version GLIBC_2.0
not defined in file libc.so.6 with link time reference
error comes?
I've gone thru:
http://www.novell.com/coolsolutions/feature/11775.html
Ive another a.out generated from Reference compiler, which can be run properly.
It differs frm new complr generatd a.out, when I vi ./a.out:
/lib/ld-linux.so.3 & /lib/ld-linux.so.2
LIBC_2.4 & LIBC_2.0
respectively
Did you really produce your crosscompiler for your target? People
seem to produce these things for "something else" nowadays, thinking
that this something of course is completely binary compatible with
the runtime target platform...
For instance one could produce a crosstoolchain for 'i686-linux-gnu'
using some plain vanilla FSF binutils, GCC and glibc sources and then
try to run the produced stuff on a SuSE, Red Hat, Debian or something
and when it doesn't run, ask here why it doesn't work...
The right approach is always to produce the toolchain for the precise
target itself if this is possible. Or choose the least common nominator
among the targets like choosing Red Hat 7.3 when needing to target to
RHL 7.3 - 9... Or produce the whole target system with the self-made
crosstoolchain, using the self-made glibc runtimes on it and so on. Then
it is binary compatible with the crosstoolchain.