Re: Problem when building a crosscompiler for arm-linux target

[Kai Ruottu <kai dot ruottu at luukku dot com>]

David Westberg wrote:
> 
> The steps needed to build the toolchain and kernel are according to my
> findings/guessings.
> 
> 1. build the toolchain for arm-linux
> 1a   binutils
> 1b   crosscompiler for the target without libc support so it is possible to
> build glibc later.
>
>   This makes me wonder what with-newlib really does/means.

 Reading from the docs shouldn't be a bad idea... Either 'www.gnu.org' or the install docs
coming with GCC should tell this:

--with-newlib -- Specifies that "newlib" is being used as the target C library. This causes
                 __eprintf to be omitted from libgcc.a on the assumption that it will be
                 provided by newlib. 

Sometimes reading only the wrong docs can be a bad idea, also the 'www.gnu-org' docs have bugs,
like the famous:

--with-headers=dir -- Specifies a directory which has target include files. This options is
                required when building a cross compiler, if ${prefix}/${target}/sys-include
                doesn't pre-exist.

which clashes with the GCC-manual, the install docs coming with GCC, with glibc sources with
most cross-compiler installations etc. But the GCC sources have adapted this bug.

When writing 'make install', the glibc headers will now be installed into the '$prefix/include',
not into the '$prefix/sys-include', but as said the GCC developers seem to have doomed this
to be totally wrong... The '$prefix' here is the one given when configuring glibc...

 The ChangeLog's in GCC show that the guys named Jeff Law and Jim Wilson invented all this
mess... Ok, while Richard M. Stallman (GCC manual), me on this list etc. have written otherwise,
the 'www.gnu.org' HTML-document and others try to push people like RMS to change their
instructions. The two or three files in the GCC sources should be much easier to correct...

 Back to the shared libgcc-problem...

 Your problem arises from the need to produce a shared libgcc. Earlier libgcc was always
static, 'libgcc.a', so no linking with the startups was needed...

 I remember there being now a '--disable-shared-libgcc' or something to prevent producing
the shared libgcc. This could be the workaround...

> 1c   glibc
> 1d   crosscompiler again this time with glibc support.
> 
> 2 compile the kernel
> 
> 3 compile all other stuff needed

 Your steps sound quite sane, but the 1b could mean also some earlier GCC which can be built
and which can build glibc without problems. I used the gcc-2.9-edk-000221 from the RedHat EDK,
aimed for embedded Linux'es, but prebuilt only for x86 and PowerPC targets. Probably the
gcc-2.95.3-prerelease3 has all the needed patches too. I remember building both glibc-2.1.3
and glibc-2.2.1 for the 'arm-linux-gnu' with the EDK-based GCC and having no problems... But
I must confess that I adapted some fixes for ARM from the GCC snapshots between the gcc-2.95.2
release and the EDK release (and some weeks further), in order to get the 'thumb-elf' working.

 Trusting to the experimental GCC snapshots which lately have crashed for almost any target,
doesn't sound sane if you aim to some stable production tools. Feel free to experiment though.
The ARM-target has been a nuisance, nobody seeming really know what is the current 'stable
production compiler', but starting with the gcc-2.95.3 shouldn't be a bad idea...

Cheers, Kai


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