Re: Tutorial 3

Re: Tutorial 3

[Mark Butcher]

Hi Phil

Thanks for your notes.

I am also sure that the problem is due to not finding some headers and
library files. In the mean time I believe that I have managed to
successfully build NEWLIB and am quite sure that the (previously really)
missing items are present (mcore-elf-gcc.exe is now there, crt0.o is now
there and libraries like libc.a).

Although the full gcc build still failed for the same reason, it must be
something silly and so probably even I can fix it - given a little more
time.

I'm looking forward to posting details of my successful build for the mcore
soon, with a list of exactly what to type in to get it working - for any
other Windows Cygwin Dummies out there.

Cheers

Mark

Re: Tutorial 3

[Peter Barada]

>The full GCC build didn't work - failing for the same reason as before -
>but I am sure that it is now something silly which I can, given adequate
>time, solve myself. I see that I now really do have "mcore-elf-gcc.exe" in
>the mcore/bin directory (I think that this must be the minimum gcc
>compiler) "crt0.o" libraries like "libc.a" are also in /mcore-elf
>directories. Since some things seem to be in /mcore and some others in
>/mcore-elf I probably did something not quite right when setting prefixes,
>resulting in the files not being found correctly - once I have gained a
>little more strength I will probably be able to swat the last self-made bug
>and will take time off to celebrate.

You have to use the *same* prefix and target for all 4 steps in order
to build a complete tool chain.

Also be user that the directory where mcore-elf-gcc, mcore-elf-as
and mcore-elf-ld are installed is in you PATH variable so configure
can find all the pieces...

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: Tutorial 3

[Hans-Peter Nilsson]

On Tue, 18 Jun 2002, Mark Butcher wrote:

> I think that Bill Gatliff's site should be compulsory reading for anyone
> contemplating a GCC cross-build. [www.billgatliff.com]. Although there is
> only a relatively small amount of information, it is the information that
> is needed and the example script is even more or less understandable to a
> dummy like myself.
>
> Build BINUTILS
> Build a minimum gcc without headers and libraries
> Build NEWLIB with the minimum gcc
> Build the full GCC

Or build them all at once, with a unified tree.  Try
<URL:http://gcc.gnu.org/simtest-howto.html>: add "make install",
but strip dejagnu and gdb parts to taste.  Alternatively, using
tarballs with gcc, binutils and newlib instead of CVS, with
releases reasonably in phase, just untar them into the same
directory, then configure --target=..., make and make install.

The simulator targets (most of them) are actually bare-bones
*-elf cross-toolchains; the simulator is an add-on from the gdb
package.  Neccessary I/O libraries are built as part of the
newlib/libgloss package.

It's not rocket science.

brgds, H-P
PS.  Houston..?  Houston..?  ...darn, not again.

Re: Tutorial 3

[Mark Butcher]

Hi Peter

I think that Bill Gatliff's site should be compulsory reading for anyone
contemplating a GCC cross-build. [www.billgatliff.com]. Although there is
only a relatively small amount of information, it is the information that
is needed and the example script is even more or less understandable to a
dummy like myself.

Build BINUTILS
Build a minimum gcc without headers and libraries
Build NEWLIB with the minimum gcc
Build the full GCC

Logical once it is explained in plain text and not camouflaged with jargon
(why has it taken me a month to discover the 4 steps ?)

The full GCC build didn't work - failing for the same reason as before -
but I am sure that it is now something silly which I can, given adequate
time, solve myself. I see that I now really do have "mcore-elf-gcc.exe" in
the mcore/bin directory (I think that this must be the minimum gcc
compiler) "crt0.o" libraries like "libc.a" are also in /mcore-elf
directories. Since some things seem to be in /mcore and some others in
/mcore-elf I probably did something not quite right when setting prefixes,
resulting in the files not being found correctly - once I have gained a
little more strength I will probably be able to swat the last self-made bug
and will take time off to celebrate.

Hope to give the mailing list a rest very soon (I think I said this several
weeks ago, but perhaps it will really happen this time). 

Cheers

Mark

Re: Tutorial 3

[Phil Edwards]

On Sun, Jun 16, 2002 at 06:40:42PM -0400, Mark Butcher wrote:
> checking how to run the C preprocessor... (cached) /lib/cpp

That's never a good sign.

For some history of why this happens, and what's causing it, take a look
at the messages in libstdc++/2255:

    http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2255&database=gcc

It isn't a libstdc++ problem, obviously, since you're seeing it far before
the build even gets to libstdc++, but that's the PR that I had in my notes.

There's some further discussion from that PR in the mail archives:

    http://gcc.gnu.org/ml/libstdc++/2001-05/msg00009.html


> checking whether the C compiler (/usr/local/src/gnu/BUILD/gcc/gcc/xgcc
> -B/usr/local/src/gnu/BUILD/gcc/gcc/ -B/usr/local/mcore/mcore-elf/bin/
> -B/usr/local/mcore/mcore-elf/lib/ -isystem
> /usr/local/mcore/mcore-elf/include -g -O2 ) works... no
> configure: error: installation or configuration problem: C compiler cannot
> create executables.
> make: *** [configure-target-libiberty] Error 1
> 
> [The error is because the linker doesn't find "crt0.o"]

Yep.  This kind of error is what causes everything else to die and results
in weird settings like the /lib/cpp thing about.  It's almost always related
to not finding the standard C library headers or the system startup files,
which are (again, almost always) the two most common symptoms of the same
problem:  the cross-compiler hasn't properly been told where to find the
C library stuff to use.

Does that help at all?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Tutorial 3

[Peter Barada]

>Here an update of my weary journey from innocent and gullable PC user to
>hardened, grey-haired GCC cross-compiler guru. Actually the journey
>probably has not yet reached further than the end of the garden path and I
>must still be making some kind of beginners errors - but its hope that
>drives me on.

You've obviously persisted long enough to get close to your goal!  To
help you get there I've just built up a gcc-3.0.4 version configured
for mcore-elf(can't run it, don't have hardware), and I found that I
had to modify gcc/config/mcore/mcore.h:

Index: mcore.h
===================================================================
RCS file: /usr/local/wavemark/cvs/archives/cross-linux-tools/gcc-304/gcc/config/mcore/mcore.h,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 mcore.h
*** mcore.h	2002/03/04 18:05:08	1.1.1.1
--- mcore.h	2002/06/17 16:16:55
***************
*** 185,191 ****
  
  /* The MCore ABI says that bitfields are unsigned by default. */
  /* The EPOC C++ environment does not support exceptions.  */
! #define CC1_SPEC "-funsigned-bitfields %{!DIN_GCC:-fno-rtti} %{!DIN_GCC:-fno-exceptions}"
  
  /* What options are we going to default to specific settings when
     -O* happens; the user can subsequently override these settings.
--- 185,191 ----
  
  /* The MCore ABI says that bitfields are unsigned by default. */
  /* The EPOC C++ environment does not support exceptions.  */
! #define CC1_SPEC "-funsigned-bitfields"
  
  /* What options are we going to default to specific settings when
     -O* happens; the user can subsequently override these settings.


Which drops the -fno-rtti and -fno-exceptions from the command
line(needed to configure libcstd++v3).

To build it, I used binutils-2.12(20020222), gcc-3.0.4, newlib-1.9.0,
gdb-5.1, and a slightly tweaked crossgcc.sh script that Bill Gatliff
wrote. Here's the following config.status results in the order of the
construction: 

binutils:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/binutils-2/configure --host=i686-pc-linux-gnu --target=mcore-elf --prefix=/tmp/crap --norecursion 
# 


gcc-bootstrap:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/configure --with-gcc-version-trigger=/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/gcc/version.c --host=i686-pc-linux-gnu --target=mcore-elf --prefix=/tmp/crap --enable-languages=c --with-local-prefix=/tmp/crap/mcore-elf --without-headers --with-newlib --disable-shared --verbose --norecursion 
# 


newlib:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/newlib-1.9.0/configure --host=i686-pc-linux-gnu --target=mcore-elf --prefix=/tmp/crap --norecursion 
# 


gcc:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/configure --with-gcc-version-trigger=/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/gcc/version.c --host=i686-pc-linux-gnu --target=mcore-elf --prefix=/tmp/crap --enable-languages=c,c++ --with-local-prefix=/tmp/crap/mcore-elf --with-newlib --norecursion 
# 


gdb:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gdb-5/configure --host=i686-pc-linux-gnu --target=mcore-elf --prefix=/tmp/crap --norecursion 
# 


Notice the gcc compiler is built twice, the first time as just a c
compiler, and the second as a full-up c++ compiler.  You should check
Bill Gatliff's website www.billgatliff.com for more information on cross compilation.

The end result is:

[pbarada: ~/work/cvs-wavemark/cross-linux-tools/obj/crap-mcore/mcore-elf/gcc] > /tmp/crap/bin/mcore-elf-g++ -v
Reading specs from /tmp/crap/lib/gcc-lib/mcore-elf/3.0.4/specs
Configured with: /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/configure --target=mcore-elf --prefix=/tmp/crap --enable-languages=c,c++ --with-local-prefix=/tmp/crap/mcore-elf --with-newlib
Thread model: single
gcc version 3.0.4

Hope this helps you get where you want to go....

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Tutorial 3

[Andrew Haley]

Mark Butcher writes:
 > Hi All
 > 
 > Here an update of my weary journey from innocent and gullable PC user to
 > hardened, grey-haired GCC cross-compiler guru. Actually the journey
 > probably has not yet reached further than the end of the garden path and I
 > must still be making some kind of beginners errors - but its hope that
 > drives me on.
 > 
 > [The error is because the linker doesn't find "crt0.o"]
 > 
 > 
 > 
 > So maybe some path is not set up correctly ?

It looks to me like you don't have a C library.  gcc is just a
compiler.

There's a C library at http://sources.redhat.com/newlib/.

Andrew.

Tutorial 3

[Mark Butcher]

Hi All

Here an update of my weary journey from innocent and gullable PC user to
hardened, grey-haired GCC cross-compiler guru. Actually the journey
probably has not yet reached further than the end of the garden path and I
must still be making some kind of beginners errors - but its hope that
drives me on.

So what have I learned ?

1. I downloaded GCC 3.1 (instead of 3.0.4) and tried again with the Mcore
target. This time the 'sjlj' error had disappeared and the build reaches
the same position as the ARM target attempt.

1.a. I assume that the Mcore target really does have a problem in 3.0.4
because I changed absolutely nothing except the compiler version.

2. So where is the build breaking now ? Still in the same place as before
(same with Arm and Mcore target attempty), so here are the details again
(as from ARM):

Configuring in mcore-elf/libiberty
loading cache ../config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo
checking for perl... perl
checking host system type... mcore-unknown-elf
checking build system type... i586-pc-cygwin
checking for mcore-elf-ar... (cached) mcore-elf-ar
checking for mcore-elf-ranlib... (cached) mcore-elf-ranlib
checking for gcc... (cached) /usr/local/src/gnu/BUILD/gcc/gcc/xgcc
-B/usr/local/src/gnu/BUILD/gcc/gcc/ -B/usr/local/mcore/mcore-elf/bin/
-B/usr/local/mcore/mcore-elf/lib/ -isystem
/usr/local/mcore/mcore-elf/include
checking whether we are using GNU C... (cached) yes
checking whether /usr/local/src/gnu/BUILD/gcc/gcc/xgcc
-B/usr/local/src/gnu/BUILD/gcc/gcc/ -B/usr/local/mcore/mcore-elf/bin/
-B/usr/local/mcore/mcore-elf/lib/ -isystem
/usr/local/mcore/mcore-elf/include accepts -g... (cached) yes
checking for POSIXized ISC... no
checking for working const... yes
checking for inline... inline
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking how to run the C preprocessor... (cached) /lib/cpp
checking for sys/file.h... grep: conftest.out: No such file or directory
yes
checking for sys/param.h... grep: conftest.out: No such file or directory
yes
checking for limits.h... grep: conftest.out: No such file or directory
yes
checking for stdlib.h... grep: conftest.out: No such file or directory
yes
checking for string.h... grep: conftest.out: No such file or directory
yes
checking for unistd.h... grep: conftest.out: No such file or directory
yes
checking for strings.h... grep: conftest.out: No such file or directory
yes
checking for sys/time.h... grep: conftest.out: No such file or directory
yes
checking for time.h... grep: conftest.out: No such file or directory
yes
checking for sys/resource.h... grep: conftest.out: No such file or
directory
yes
checking for sys/stat.h... grep: conftest.out: No such file or directory
yes
checking for sys/mman.h... grep: conftest.out: No such file or directory
yes
checking for fcntl.h... grep: conftest.out: No such file or directory
yes
checking for alloca.h... grep: conftest.out: No such file or directory
yes
checking for sys/wait.h that is POSIX.1 compatible... no
checking whether time.h and sys/time.h may both be included... no
checking whether errno must be declared... yes
checking for ANSI C header files... grep: conftest.out: No such file or
directory
no
checking for uintptr_t... no
checking whether the C compiler (/usr/local/src/gnu/BUILD/gcc/gcc/xgcc
-B/usr/local/src/gnu/BUILD/gcc/gcc/ -B/usr/local/mcore/mcore-elf/bin/
-B/usr/local/mcore/mcore-elf/lib/ -isystem
/usr/local/mcore/mcore-elf/include -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler cannot
create executables.
make: *** [configure-target-libiberty] Error 1

[The error is because the linker doesn't find "crt0.o"]



So maybe some path is not set up correctly ? But this could mean more than
one path since the missing header files are not all in one place - so I
poked around looking at the log files and to my suprise realised that
probably a whole bunch of other errors occured, which howver did not break
the build.

Here is a list of the config.log file I found on the computer, in order of
their save time (starting with the oldest).

  gcc/libiberty/config.log
  gcc/gcc/config.log
  gcc/mcore-elf/big/libstdc++-v3/config.log
  gcc/mcore-elf/m210/libstdc++-v3/config.log
  gcc/mcore-elf/big/m210/libstdc++-v3/config.log
  gcc/mcore-elf/libstdc++-v3/config.log
  gcc/mcore-elf/libiberty/config.log

The time between the first and last being about one hour (on slow laptop).
(Does this run sequentially or can the flow be nested ?)

Although the build broke in gcc/mcore-elf/libiberty I curiously checked out
the content of the others and to my horror and suprise found that they were
full of errors but none of them caused the build to stop, until for some
reason the last one.

The compiler seems to work until the linker is used. The linker never seems
to be able to find any of the programs it should link. For example, the
first error message was due to "asprintf()" not being linked. Then some
more:

  basename()
  insque()
  mkstemps()
  sigsetmask()
  vasprintf()
  _doprnt()
  ...
and on and on and on..., right through all library builds.


But maybe it's normal that they all fail .. (some of) the libraries seems
to exist and on a repeat of the build they are not repeatedly built.
Perhaps they are supposed to fail and only then are they actually created
(?).

Well, for example asprint.o and a bunch of other library .o files are in
gcc/libiberty (created some time around the beginning of the build attempt)
but the files mcore-elf/big, mcore-elf/libiberty, mcore-elf/libstdc++-v3/..
are all pretty much empty.

As for the missing header files, they are all in gcc-3.1 source directories
(quite deep, like gcc-3.1/gcc/fixinc/tests/base/sys/..). In the build
directory there are a number of headers (about 20), mainly in gcc/gcc and
gcc/gcc/include and I am wondering where they should be at this point. Are
they normally copied to the target directory or do they remain in the souce
directory, and if so, how should they be found ?

I think this has knocked me more or less back to square one and I can not
get my head around it any more (it's getting too late again). Perhaps some
of this may jog someones memory - " Ohh Yes, I remember now, it also took
me .. months to work it out until I did ........" (please free to fill in
the missing words).


Cheers


Mark in Switzerland