On Sun, 03 Oct 1999, Chris Rutter wrote:
> I've finally had an overhaul and update of my toolchain guide; you
> can find the result, as ever, at:
>
> http://www.inkvine.fluff.org/~chris/arm-tools.html
>
> Stuff like the inhibit_libc hack is now mentioned, along with some
> extra patches, and stuff.
>
> One caveat: I just tried following through the whole document and
> got some build error in glibc re: threads, although according to
> the mailing list archives I think it should work. I'll post more
> when Jenny hasn't got the PC in Windoze *grumble grumble*.
>
> --
> Chris <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )
I've read the new guide and am very enthusiastic about it. Just before it was
released, on friday, I succeeded at building a complete ToolChain, I'm _very_
newbie, which would explain how lost I felt in the middle of gcc & glibc
configure and makefile structure nightmare. But well, I finally did it, so I
think the following can be useful.
Here is therefore a condensed version (the new guide does most of the job) of my
experience on an Intel dual Celeron based Linux system (running Mandrake 6.1
with pgcc).
The crossplatform toolchain I succeeded to built from scratch is based on:
-linux-2.2.10 (I've heard of 2.2.12 working)
-binutils-2.9.5.0.13 (the latest at this time)
-gcc-2.95.1
-glibc-2.1.2
I chose target = arm-linux, PREFIX=/usr, TARGET-PREFIX=/usr/arm-linux
BINUTILS:
Binutils building went exactly as specified by the new (and old) guide. As
specified by Philip, no patch need to be added to the 2.9.5 binutils,
especially not the 2.9.1 ones.
GCC:
The kernel header I used are from linux-2.2.10, though later version probably
work (I've heard of 2.2.12 working).
I applied patch 2.2.10-rmk3 from Russel. The latest 2.2.10 patches from Philip
are to be applied against 2.2.10-rmk2 and some of them has been included in
rmk3. So I haven't included any Philip's patches.
In the old version, the guide suggests to:
# cp -a /usr/src/linux-2.2.10/include/asm-arm /usr/arm-linux/include/asm
# cp -a /usr/src/linux-2.2.10/include/linux /usr/arm-linux/include/linux
while in the new version, it suggests to:
# cp -dR /usr/src/linux-2.2.10/include/asm-arm /usr/arm-linux/include/asm
# cp -dR /usr/src/linux-2.2.10/include/linux /usr/arm-linux/include/linux
Why does it suggests cp. Wouldn't symlink do the job?
As is suggested in the new guide, I did:
-Used gcc-2.95.1 sources from egcs.cygnus.com mirrors,
-Applied 2.95-diff-990730 patch from ftp://ftp.netwinder.org/users/p/philb/,
-Changed #if 0 to #if 1 in gcc/config/arm/linux-elf.h (for binutils-2.9.5.x)
-Applied by hand the patch sent by Philip to gcc/fold-const.c (for the kernel)
-In order to avoid the fact that libgcc2.c build cannot find stdlib.h, I had to:
-------
Edit gcc/config/arm/t-linux and add "-Dinhibit_libc" and
"-D__gthr_posix_h" to TARGET_LIBGCC2_CFLAGS
Delete #include "gthr.h" in libgcc2.c
Add the "--disable-threads" option to configure
-------
This last patch has bad consequences as specified by Philip B:
>The generated libraries will not be threadsafe. This will bite you if, for
>example, you have a multithreaded C++ program that uses exceptions.
However, this problem can be fixed. Once glibc has succesfully been built,
all you have to do is rebuild gcc again whitout these corrections (you don't
need to recompile glibc a second time however). I will cover that later.
While doing the ./configure, I noted the host type, as suggested at Step 7. of
Intel note http://developer.intel.com/design/strong/applnots/sa1100lx/egcs_c.htm
The host type is given in the first output lines of ./configure, looking like:
configuring for a i686-pc-linux-gnu host
This (i686-pc-linux-gnu or whatever configure give you as host type) will be
used as --build argument when configuring glibc, later.
Chris corrected the erronous "cd gcc" before the make and make install statement
and that is good, since it avoid the famous libiberty/libiberty.a Error.
However I've found this from Chris and Philip on the Mailing List
On Sat, 02 Oct 1999, Philip Blundell wrote:
> >> Don't do that, then - just configure and make at the top level. The gcc
> >> subdirectory depends on other things such as libiberty that need to be built
> >> first.
> >
> >What happens to all the bits of the compiler that depend on libc?
> >Presumably it's impossible to reach a working `make install' target
> >unless you inhibt make from considering these? Is `make LANGUAGES="c"'
> >at the top level the correct way of doing this?
>
> I don't think that will work. What you have to do is `make' at the top level,
> wait for it to crash, then `make install' in the gcc subdirectory.
>
> p.
I have the feeling that this _may_ be more complicated. The first time I tried
building my toolchian I did exactly this:
[/usr/src/gcc-2.95.1] #./configure --target=arm-linux --prefix=/usr --disable-threads
[/usr/src/gcc-2.95.1] #make LANGUAGES="c"
Very late in the build process (at the linking stage I think) it generated the
famous libio Error:
make[1]: Leaving directory `/usr/src/gcc-2.95.1/gcc'
Configuring in arm-linux/libiberty
COPYING.LIB ..linked
ChangeLog ..linked
Makefile ..linked
Makefile.in ..linked
README ..linked
acconfig.h ..linked
...
A lot more linked modules from a to z...
...
xxstrdup.o ..linked
xstrerror.c ..linked
xstrerror.o ..linked
make[1]: Entering directory `/usr/src/gcc-2.95.1/arm-linux/libiberty'
make[2]: Entering directory `/usr/src/gcc-2.95.1/arm-linux/libiberty/testsuite' rm -f
test-us.c test-filter
make[2]: Leaving directory `/usr/src/gcc-2.95.1/arm-linux/libiberty/testsuite'
rm -rf *.o pic core errs \#* *.E a.out
rm -f needed.awk needed2.awk errors dummy needed-list config.h stamp-*
rm -f stamp-picdir
make[2]: Entering directory `/usr/src/gcc-2.95.1/arm-linux/libiberty/testsuite'rm -f
test-us.c test-filter
make[2]: Leaving directory `/usr/src/gcc-2.95.1/arm-linux/libiberty/testsuite'
rm -f *.a required-list tmpmulti.out
make[2]: Entering directory `/usr/src/gcc-2.95.1/arm-linux/libiberty/testsuite' rm -f
test-us.c test-filter
rm -f Makefile
make[2]: Leaving directory `/usr/src/gcc-2.95.1/arm-linux/libiberty/testsuite'
rm -f *~ Makefile config.status xhost-mkfrag TAGS multilib.out
rm -f config.log
make[1]: Leaving directory `/usr/src/gcc-2.95.1/arm-linux/libiberty'
loading cache ./config.cache
checking host system type... arm-unknown-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for arm-linux-ar... arm-linux-ar
checking for arm-linux-ranlib... arm-linux-ranlib
checking for gcc... /usr/src/gcc-2.95.1/gcc/xgcc -B/usr/src/gcc-2.95.1/gcc/ -B/u
sr/arm-linux/bin/
checking whether we are using GNU C... yes
checking whether /usr/src/gcc-2.95.1/gcc/xgcc -B/usr/src/gcc-2.95.1/gcc/ -B/usr/
arm-linux/bin/ accepts -g... yes
checking for POSIXized ISC... no
checking for a BSD compatible install... /usr/bin/install -c
checking how to run the C preprocessor... /lib/cpp
checking for sys/file.h... yes
checking for sys/param.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for unistd.h... yes
checking for strings.h... yes
checking for sys/time.h... yes
checking whether the C compiler (/usr/src/gcc-2.95.1/gcc/xgcc -B/usr/src/gcc-2.9
5.1/gcc/ -B/usr/arm-linux/bin/ -g -O2 ) works... no
configure: error: installation or configuration problem: C comipler cannot
create executables.
make[1]: Entering directory `/usr/src/gcc-2.95.1/arm-linux/libio'
if [ x"no" = xyes ] && [ ! -d pic ]; then \
mkdir pic; \
else true; fi
touch stamp-picdir
test x"no" != xyes ||\
/usr/src/gcc-2.95.1/gcc/xgcc -B/usr/src/gcc-2.95.1/gcc/ -B/usr/arm-linux/bin/
-c -g -O2 -I. -I. -D_IO_MTSAFE_IO iogetline.c -o pic/iogetline.o
/usr/src/gcc-2.95.1/gcc/xgcc -B/usr/src/gcc-2.95.1/gcc/ -B/usr/arm-linux/bin/ -c -g
-O2 -I. -I. -D_IO_MTSAFE_IO iogetline.c
In file included from iogetline.c:26:
libioP.h:30: errno.h: No such file or directory
In file included from iolibio.h:1,
from libioP.h:47,
from iogetline.c:26:
libio.h:30: _G_config.h: No such file or directory
iogetline.c:27: string.h: No such file or directory
make[1]: *** [iogetline.o] Error 1
make[1]: Leaving directory `/usr/src/gcc-2.95.1/arm-linux/libio'
make: *** [all-target-libio] Error 2
So following Philip B suggestion, I just did
[/usr/src/gcc-2.95.1] #make LANGUAGES="c" install
Everything got installed, and I moved to glibc.
I have, as explained bellow, reasons to believe that this is wrong (but I cannot
explain it since I just have _NO_ idea what is happening here ;-().
Anyway I _feel_ you should redo:
[/usr/src/gcc-2.95.1] #make LANGUAGES="c"
[/usr/src/gcc-2.95.1] #make LANGUAGES="c" install
again to make sure everything got build completely before moving to glibc. I
didn't do it the first time and I ran in the ld.so.map Error in building glibc.
More later.
GLIBC:
I used:
glibc-2.1.2.tar.bz2
glibc-linuxthreads-2.1.2.tar.bz2
glibc-crypt-2.0.111.tar.gz
As told in binutils-2.9.5.0.12 release note, found at
ftp://ftp.varesearch.com:/pub/support/hjl/binutils/release.binutils-2.9.5.0.12:
>
>For arm-linux targets, there are some important differences in behaviour
>between these tools and binutils 2.9.1.0.x. The linker emulation name has
>changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
>passed with the linker when working with object files (or static libraries)
>created using older versions of the assembler. If this flag is omitted the
>linker will silently generate bad output when given old input files.
>
>To get the correct behaviour from gcc, amend the *link section of your specs
>file as follows:
>
>*link:
>%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic}
>%{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic}
>%{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X
>%{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26}
>%{!mapcs-26:-m armelf_linux} -p
>
The refered specs file is /usr/lib/gcc-lib/arm-linux/2.95.1/specs.
I add nothing to modify, although I know many had to permform the changes
So I did
# CC=linux-arm-gcc
# ./configure arm-linux --build=i686-pc-linux-gnu --prefix=/usr/arm-linux
--enable-add-ons
# make
Note that the --build option is the host type I got from gcc configure not
i586-linux as suggested.
The first time, I then hit the infamous ld.so.map Error, in the late building
phase of glibc. That was _BAD_ since I was just _begining_ to learn the syntax
of bash, makefile, sed awk (very newbie, said I)
Nobody had fixed that problem before, Philip thought it could be a problem
with awk, refered me to the alpha mailing-list. I previously was fool enough to
assign only 1 week of works on my tight schedule for building the toolchain.
That had already slipped to 3 weeks, and I couldn't imagine how I would
become a makefile expert quick enough (this gcc and glibc configure/makefile is
really a nightmare for a newbie) to fix this without losing a month or so.
That's when Nicolas Pitre sent me that little E-Mail that brought me
hope. He actually succeeded at building a gcc-2.95.1/glibc2.1.2 toolchain.
After a few days of Makefile darkness, I just decided to restart everything from
scratch.
When after a few hours of building binutils and patching/building gcc, I
hit the gcc libio Error, I just said to my self: "Hey! could that incomplete
gcc build be the reason why glibc fail later?" So after instaling gcc I did:
make clean, configure, make and make install again. Everyting went well. On the
second make it didn't complained about libio Error.
So I started building glibc and it went through! No more ld.so.map Error! (I've
just _no_ idea why: Trust your feeling Luke ;-)
Then, I installed glibc. It went well.
I even went back to gcc-2.95.1 and rebuild it without the corrections:
------
Edit gcc/config/arm/t-linux and add "-Dinhibit_libc" and
"-D__gthr_posix_h" to TARGET_LIBGCC2_CFLAGS
Delete #include "gthr.h" in libgcc2.c
Add the "--disable-threads" option to configure
-------
in order for gcc to generate thread safe code. That went well.
At that moment, I thought: Can I reproduce the original ld.so.map Error in
glibc? (So that this will confirm or not my "double gcc make" hypothesis)
So I erase the complete content of /usr/src and /usr/arm-linux, and did the
entire process again without double compiling gcc-2.95.1. But, there is
probably something else installed somewhere that I didn't erase, because "make
LANGUAGES="c"" went succesfully through without the libio Error on the first
attempt. And glibc was successful as well on first attempt. So I wasn't able to
invalidate my "double gcc make" hypothesis.
The only other difference I can remember (I took precise notes) between the
first, 3-weeks-long toolchain build, that resulted in a ld.so.map Error and the
second succesful one, is that I used --with-cpu=strongarm110
as a gcc ./configure argument the second time, that I didn't use the first
time. But I didn't verify this. (Complete toolchain build takes a lot of time)
If I'm right on this one (I hope Philip can confirm this), one would have to
build gcc 3 times in order to have a completely foncionnal toolchain:
-Build/install binutils
-Patch/Build/install gcc
-Build/install gcc again
-Build/install glibc
-Build/install gcc a third time without the -Dinhibit_libc corrections.
Am I totally wrong here or what ?
--
Fran�ois Desloges
[EMAIL PROTECTED]
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
