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

[Zhiyong Sun <szhiyong at cs dot unm dot edu>]

Hi,Kai,

Thanks a lot for your help!! I appreciated it.

I knew my problem now. I have one question how to build toolchain
for AthlonXP. Can you please tell me which /linux/include/asm-*
for AthlonXp? Is asm-ppc ok to build AthlonXp? Is CFLAGS="-march=
athlon_xp -02" right?

I tried to use "CC="gcc -m32"" to build 32 bit library for glibc. But
it still produced 64-bit lib64 library. When I used " CFLAGS="-m32 -02""
, the error message came. May I ask why this happen?

zhiyong

On Fri, 12 Dec 2003, Kai Ruottu wrote:

> 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