I did this (actually did something pretty similar). But I still have questions.
Phil mentions that this is a common problem when building cross-compilers for
the first time. After compiling with the --disable-threads
and the commented out thread include files, do I need to recompile things a
second time (without the --disable-threads flag and with the
thread include files) ? Why will things be different this time?
(The code that I wish to compile with the cross-compiler includes the use of
threads).
As an aside (of possible interest to some of you) I was able to build my "buggy"
fpic program from last week, and the compiler which
I built *doesn't* demonstrate the bug which I had previously seen.
Does anyone know if this is likely due to a bugfix in the compiler (was anything
like this addressed?), or is it *random chance* that
this bug got fixed (or just hidden)?
Thanks again to everyone for all of your help.
-Hugh
Philip Blundell <[EMAIL PROTECTED]> on 06/25/99 06:40:07 PM
To: Hugh Morgenbesser/Dragon Systems USA@Dragon Systems USA
cc: [EMAIL PROTECTED]
Subject: Re: linux-arm cross-compiling toolchain report... (troubles)
>_muldi3
>./libgcc2.c:41: stdlib.h: No such file or directory
>./libgcc2.c:42: unistd.h: No such file or directory
>gmake[3]: *** [libgcc2.a] Error 1
Yeah, this is a common problem when building cross-compilers for the first
time. The workaround is to edit gcc/config/arm/t-linux and add
"-Dinhibit_libc" to TARGET_LIBGCC2_CFLAGS. You will also probably get errors
building frame.c - to avoid those, add the "--disable-threads" option to
configure, and then manually delete the offending #include <pthread.h>. (This
last bit was suggested by Werner Almesberger; I haven't actually tried it
myself.)
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
