david.hagood@xxxxxxxxx wrote:
I know I'm doing something stupid, but I don't know what:
I am trying to cross-compile binutils/gcc/glibc, HOST=i686-linux-gnu,
TARGET=arm-linux-gnueabi, so that I can build for an embedded system
running Debian on an OMAP3 using my x86 workstation.
About people usually "doing something stupid"...
The assumptions with producing cross toolchains are quite identical with
those with native toolchains :
- the target system exists and already has its own prebuilt and
thoroughly tested C library, installed runtimes etc.
- one only needs to make "reincarnations" of the target binutils
and target GCC for some other $host than the native one, the
"cross host"
Not being aware of these assumptions is quite common so people may try
to replace the existing target libraries for existing targets like the
SuSEs, Fedoras, Ubuntus etc.
So your "I can build for an embedded system running Debian on an OMAP3
using my x86 workstation" is just what needs elaboration. Does your
target system (Debian-based 'arm-linux-gnueabi' system) exist or are
you first creating it from absolute scratch?
I can complete the build of binutils, the first pass of GCC, and glibc
with no errors (as far as I can see).
When producing binutils and GCC for an existing target system, there is
only one build stage with both... Just like you would update the native
binutils and native GCC using the existing native GCC to compile them !
However, when I then start the second pass GCC build (so that it can use
the generated glibc and compile target apps),
If you are starting from absolute scratch, you MUST first produce the
target system, kernel, root file system etc. You CANNOT produce target
apps for something which doesn't yet exist!
It seems that GCC is placing a host library (x86 ELF) into the target
library directory, then attempts to link against them for the target.
I *know* it has to be something stupid - some command line parameter I am
getting wrong - but for the life of me I've not found anything online
which gives me a clue what I am doing wrong.
I am using the following commands to do the build:
>
mkdir -p build/glibc
cd build/glibc
${BASE_DIR}/${GLIBC}/configure \
--target=${TARGET} --host=i686-linux-gnu
--prefix=${ROOTDIR_PREFIX} || exit 2
make all install || exit 3
One builds the target C library ONLY once ! After that it will be
thoroughly tested and copied "as it is" onto every $host, native
and the cross hosts. NEVER being rebuilt, retested etc. "Reinventing
the wheel" is in any way sane!
When one builds a glibc, it will be produced for the NATIVE $host,
not for the CROSS $host ! So your '--host=i686-linux-gnu' means
that you want to produce a glibc for Linux/x86, not for Linux/ARM!
After producing it one installs it onto the (originally unexisting)
target system as its "runtime library" and also as the target C
library in the crosstoolchain. So generally ALWAYS one uses the
'--prefix=/usr' because the usual '/lib', '/usr/include' and '/usr/lib'
will keep the produced glibc on the target system. On the cross host
one usually uses a $sysroot where the 1-to-1 install scheme of the
native glibc will be maintained. So '--with-sysroot=$sysroot' will
be used when configuring the cross binutils and cross GCC...
The "install" command for the produced 'sysroot'ed "native glibc"
would be :
make install_root=$sysroot install
if I remembered it right, please check ! From that $sysroot it will
be easy to pack and copy onto the target system's root filesystem...
If the target system exists, one DOESN'T produce the target C library
for it but uses the existing one in the crosstoolchain!
cd build/gcc
${BASE_DIR}/${GCC}/configure \
--target=${TARGET} --host=${HOST} --build=${HOST}
--prefix=${PREFIX} \
--with-gnu-as --with-gnu-ld \
--disable-nls --enable-threads=posix \
--enable-symvers=gnu --enable-__cxa_atexit --disable-multilib \
--enable-languages=c,c++ || exit 3
>
> make all install || exit 4
Something like this would be the only "configure and build" stage with
the GCC after the target binutils and the target C library (plus the
target kernel headers) are in their proper places...
OK, so, what stupid thing am I missing?
Maybe that was forgetting that producing a crosstoolchain includes
ONLY producing the target binutils and the target GCC ! Producing
the target C library happens ONLY when it really doesn't yet exist!
