public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Workaround: compiling GCC 3.0 as a cross-compiler under Linux
@ 2001-11-15 22:47 John Zaitseff
  2001-11-16  8:35 ` Rupert Wood
  0 siblings, 1 reply; 2+ messages in thread
From: John Zaitseff @ 2001-11-15 22:47 UTC (permalink / raw)
  To: gcc-help

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A number of people have previously queried compiling GCC 3.0 as a 
cross-compiler for embedded systems under Linux.  These people have had 
problems in doing so, with apparently no answers to their queries.

I also have had problems compiling GCC 3.0.2 as a cross-compiler (in my 
case, for arm-elf) under Linux.  I have found a suitable workaround, which 
others having the same problems may like to know.  It probably would be 
good if someone got around to FIXING the problems as well...

1. Download and unpack the GCC sources as per the standard instructions 
(I'll use /usr/local/src/gcc-3.0.2 in this example).  Also create a build 
directory---I'll use /tmp/build/gcc-3.0.2.

2. You need to download and unpack the newlib distribution (currently 
newlib-1.9.0.tar.gz from ftp://sources.redhat.com/pub/newlib) when 
compiling GCC for an embedded system.  The GCC installation documentation 
states that you need "--with-newlib" when configuring GCC, but does NOT 
state that you actually need the newlib distribution present and unpacked, 
at least as far as I can tell!  I'll use /usr/local/src/newlib-1.9.0 in 
this example.

3. Assuming that you have already compiled the binutils package for arm-elf 
and installed it in /usr/local/bin, /usr/local/arm-elf, etc, do the 
following AS ROOT:

    # cd /usr/local/arm-elf
    # mkdir sys-include
    # ln -s sys-include include
    # chmod o+w sys-include

    # cd /usr/local/lib
    # mkdir -p gcc-lib/arm-elf
    # chmod o+w gcc-lib/arm-elf

The reason for the world-writable sys-include directory (a VERY bad idea in 
general) is that GCC's "configure" will copy files from the newlib 
distribution into this directory during configuration.

The reason for the world-writable gcc-lib/arm-elf directory (also a bad 
idea) is that GCC's Makefile will copy files there during "make all".

The reason for the symbolic link /usr/local/arm-elf/include -> sys-include 
is that compiling libiberty (part of GCC) will fail during "make all" if it 
is not present.

4. As an ordinary user, issue the following command (with appropriate 
substitutions for your own set-ups, of course):

    $ cd /tmp/build/gcc-3.0.2
    $ /usr/local/src/gcc-3.0.2/configure --target=arm-elf --with-newlib \
      --with-headers=/usr/local/src/newlib-1.9.0/newlib/libc/include

5. Compile GCC:

    $ make all

6. Now you can install the cross-compiler, and remove the world-writable 
permission from those directories listed above:

    # make install
    # chmod o-w /usr/local/arm-elf/sys-include
    # chmod o-w /usr/local/lib/gcc-lib/arm-elf
    # chown -R root:root /usr/local/arm-elf/sys-include
    # chown -R root:root /usr/local/lib/gcc-lib/arm-elf

7. NOW you can go ahead and compile newlib as per instructions...

This workaround highlights the following bugs:

1. GCC's "configure" expects write-access to system directories (in this 
case /usr/local/arm-elf/sys-include) to copy header files.

2. GCC's Makefile expects write-access to system directories (in this case 
/usr/local/lib/gcc-lib/arm-elf/3.0.2/include) to create "fixed" header 
files.

3. Libiberty's Makefile (in .../libiberty, part of GCC) uses "include" 
instead of "sys-include" when compiling the cross-compiled version of its 
library.  I am not sure if the link created in step 3 needs to be kept 
after GCC's installation.

I hope this helps other people.  Please send any replies directly to my 
e-mail address (J.Zaitseff@zap.org.au) as I am not subscribed to the 
gcc-help mailing list.

Yours truly,

John Zaitseff

- -- 
John Zaitseff                    ,--_|\    The ZAP Group
Phone:  +61 2 9543 6448         /      \   Sydney, Australia
E-mail: J.Zaitseff@zap.org.au   \_,--._*   http://www.zap.org.au/
Finger: john@zap.org.au               v
GnuPG   fingerprint:  8FD2 8962 7768 2546 FE07  DE7C 61A8 4486 C9A6 69B0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjv9e5gACgkQYahEhsmmabCusgCdF7ZE0O+E0InMoES3zwH1J/Pd
SZ4AnRmHHew14RG4Fq+eQz0ID/Ch7QKo
=wv7F
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: Workaround: compiling GCC 3.0 as a cross-compiler under Linux
  2001-11-15 22:47 Workaround: compiling GCC 3.0 as a cross-compiler under Linux John Zaitseff
@ 2001-11-16  8:35 ` Rupert Wood
  0 siblings, 0 replies; 2+ messages in thread
From: Rupert Wood @ 2001-11-16  8:35 UTC (permalink / raw)
  To: 'John Zaitseff'; +Cc: gcc-help

John Zaitseff wrote:

> A number of people have previously queried compiling GCC 3.0 as a
> cross-compiler for embedded systems under Linux.  These people have
> had problems in doing so, with apparently no answers to their
> queries.

Oh. If *I*'d seen the questions, I'd have had a go.

Yes, you need GCC, binutils and newlib, but the easiest way is to build
all three as a single toolchain: the top-level directories of all three
are roughly the same and the top level configure and makefile support
this.

Unpack all three sources to a single tree; I read on the GCC list that
the GCC files should take precedence :-) but if you're combining
packages with radically different timestamps, you need to pay attention
to the libiberty and include directories. I'd recommend allowing the
most recent libiberty and includes to overwrite the older copies (or
even deleting the older copies first and installing the most recent
clean). You can use find / cpio games to hard-link three separate source
trees to a single toolchain tree (recommended if you're using CVS copies
of the packages) but if it's a single untar, build, throw then you might
as well plain overwrite, e.g. symlink for ease:

    fox:~/src$ mkdir toolchain
    fox:~/src$ ln -s toolchain newlib-1.9.0
    fox:~/src$ ln -s toolchain binutils-2.11.2
    fox:~/src$ ln -s toolchain gcc-3.02
    fox:~/src$ gzip -cd newlib-1.9.0.tar.gz |tar xvf -
    fox:~/src$ bzip2 -cd binutils-2.11.2.tar.bz2 |tar xvf -
    fox:~/src$ bzip2 -cd gcc-3.02.tar.bz2 |tar xvf -

Then you just need a single configure and make step:

    fox:~/build/arm-elf$ ~/src/toolchain/configure \
    --target=arm-elf --prefix=~/local-arm-elf && gmake

and you're away. It'll first build binutils, then gcc and finally newlib
using both the arm-elf binutils and gcc. It does not attempt to install
anything in the target path, as you mention, and all three can be
installed in one go. And that's it - a workable embedded-cross-compiler
with no fuss.

If you want to check the resulting compiler, you can use gdb's sim.
There are instructions on the GCC website:

    http://gcc.gnu.org/simtest-howto.html

although that's based around CVS sources.

> The reason for the world-writable gcc-lib/arm-elf directory (also a
> bad idea) is that GCC's Makefile will copy files there during "make
> all".

I agree that world-writable is a bad idea. However, it'd be easier and
safer to temporarily grant the build user ownership or group privs to
the relevant parts of the install tree. On the other hand, this isn't
needed for the single-toolchain method.

Rup.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-11-23  9:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-11-15 22:47 Workaround: compiling GCC 3.0 as a cross-compiler under Linux John Zaitseff
2001-11-16  8:35 ` Rupert Wood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).