Re: help for /x86_64-linux/bin/ld: cannot open crti.o

["Kai Ruottu" <karuottu at mbnet dot fi>]

Zhiyong Sun <szhiyong@cs.unm.edu> wrote:

> I am building x86-64 crosscompiler.

 First you must think what the AMD's Athlon64 is and how
it differs from the AthlonXP. There is the clue... It is
quite similar as an idea as mips/mips64, sparc/sparc64,
powerpc/powerpc64 and sh/sh64. Maybe there are others but
the point is that the newer CPU chips are bi-arch, capable
to run both 64-bit and old 32-bit binaries. A toolchain
for these so should be capable to produce both 64-bit (as
the default) and 32-bit (with '-m32') binaries.

> I met the problem when I build final gcc, the error message
> is:
>  /opt/x86-64/x86_64-linux/bin/ld: cannot open crti.o: No such file or
>  directory
>  collect2: ld returned 1 exit status
>     make[2]: *** [32/libgcc_s_32.so] Error 1

 When linking the 32-bit shared 'libgcc_s.so' [32/libgcc_s_32.so],
the 32-bit glibc will be required, not the 64-bit one you probably
already have...

 Then you should either build glibc once again using the '-m32' in
order to get the 32-bit C library. Or you may have it already with
an 'athlon_xp-linux-gnu' targeted toolchain... I had this but built
however glibc with the 'x86_64-linux-gnu' targeted GCC in order to
see whether it was different from the pure 'athlon_xp-linux-gnu'
target one... It was at least in library sizes.

 How you want to arrange the installation is up to you. GCC expects
the 'multilib'ed stuff being in subdirs below 'lib' but the 'x86_64'
Linux specs try to use '.../lib64' and '.../lib' for these. The new
'--with-sysroot' definitely tries to bring these 'native' (in some
other land) habits and conventions into the "peaceful land of cross",
so basically you can approve every new GCC bringing its own weird
native habits, or try to force all GCCs to follow the existing cross
habits...

 Ok, the well-known cross-habit is to use the multilib-definitions,
so you can have the directory:

  /opt/x86-64/x86_64-linux/lib

for the default 64-bit C library, and the directory:

  /opt/x86-64/x86_64-linux/lib/32

for the optional (-m32) C library.

 The headers, binutils etc. are partly common but what to
do with the 'sbin', 'etc', 'libexec' etc. stuff generated
for each glibc, is still unclear...

 Maybe the easy way is to build also a 'athlon_xp-linux'
target cross-toolchain and symlink its C library directory:

  /opt/x86-64/athlon_xp-linux/lib

to be seen as the:

  /opt/x86-64/x86_64-linux/lib/32

 Or you can try to force the land of cross to accept the
native x86_64 habits some way...

> My platform is :i686. OS is Redhat 9. I use gcc-3.3.2, glibc-2.3.2,
> binutils-2.14.

 You could also consider taking any prebuilt RedHat's 'athlon_xp'
tailored glibc-2.3.2, or even the i686-tailored one to serve as
the 32-bit C library...

 BUT !!! If you are not producing these tools "just for a fun",
then your approach to the cross-tools problem seems to be wrong.

 If your REAL target is RedHat's "Enterprise Server 3" or the SuSE's
equivalent, ie. a prebuilt commercial Linux/x86_64 distribution, then
you should build a cross-GCC around the target's own prebuilt strongly
patched (expected) C libraries, not around your own self-built glibcs...

 Your "I build final gcc" tells you are using Dan's scripts etc. for
some "just for a fun" purposes, or you are going to produce your own
Linux/x86_64 distribution for some embedded purpose, not targeting to
RedHat or SuSE.

Cheers, Kai


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