Building a cross-compiler

Building a cross-compiler

[Jeff Elkins]

I'm attempting to build a cross-compiler for i686->powerpc using directions I 
found  at http://www.x86-64.org/documentation_folder/build and  
http://penguinppc.org/embedded/cross-compiling/

I get the error:

config/rs6000/linux.h:81:20: signal.h: No such file or directory
config/rs6000/linux.h:82:26: sys/ucontext.h: No such file or directory
make[2]: *** [libgcc/./_muldi3.o] Error 1
make[2]: Leaving directory `/home/jeff/gcc-3.2.2/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/jeff/gcc-3.2.2/gcc'
make: *** [all-gcc] Error 2

Thanks for any assistance,

Jeff Elkins

Re: Building a cross-compiler

[Wenton L. Davis]

Michael Witten wrote:
>
> On 28 Jan 2008, at 6:44 PM, Wenton L. Davis wrote:
>
>> John Carter wrote:
>>>
>>> It's a _very_ dark art....
>> No kidding!!!!
>
> I disagree wholeheartedly.
>
> Creating a cross compiler _should_ be the easiest
> thing in the world, but the gcc is so backasswards
> that it can be troublesome.
>
I definitely agree that this should be one of the simplest tasks, 
because it's so vital.  I will say that building the native compiler was 
1..2..3.. simple.  I got the kernal to compile more easily than this!


>>>
>>> Last time I did it, I found I had to have the binutils --prefix 
>>> directory
>>> the same --prefix as the compiler.
>
> This is definitely the case; gcc is really just an
> interface to a bunch of different tools, so it needs
> to know where to find those tools.
>
> It would be nice if there were a configure directive
> to specify the location of binutils tools for greater
> flexibility. For now, just make --prefix the same for
> both.
>
> In any case, you're supposed to be able to put the
> binutils source subdirectories (gprof, opcodes,
> bintutils, ...) inside the top level of the gcc source
> code so that one configure invocation handles both; both
> source trees are actually 2 separate views of a larger
> tree.
>
I'm not sure I understand you clearly.  Right now, in my /mnt/tmp 
directory, I have a binutils-2.18.50 directory, and a gcc-4.1.2 
directory  (and all the others that were results of building).  Are you 
saying the binutils directory should be moved up into the gcc-4.1.2 
directory?

>> At this point, I tried the brute force, copying the exact command 
>> line, but adding to it the -I../../(etc) to find the unistd.h and 
>> pthreads.h, but it failed because of an #endif without #if error... I 
>> thought I'd manually modify this file, but it was automagically 
>> created by fixincludes.  (?!?!?)
>
> Do you need libc on these other targets? If not, use
> --without-headers to indicate that you have no intention
> of building libc or the runtime libraries like libstdc++.
> See below.
>
Well, the answer to this is "eventually."  For now, just the compiler is 
needed, and eventually, I will need the libc.  I suppose that if I can 
get the compiler built, I'll be able to use it to build the libc.  
(Since most of my targets communicate via RS-232c, libc will need to be 
customized anyway.)

So, I went ahead with the --without-headers, and I eliminated the 
--enable-threads and --enable-shared.  Now, I run make, and I see 
several of these:

Next, I had to disable libssp because it failed (because it needs 
libc?)  Not happy about eliminating this, but I'll deal with it.

and viola! there it is!  I had to do a "echo $?" just to make sure I 
wasn't imagining things!

My final configure command line was:

../gcc-4.1.2/configure --prefix=/mnt/tmp --program-prefix=mips-elf- 
--target=mips-elf --enable-languages=c --disable-checking --verbose 
--without-headers --disable-nls --disable-libssp

Now, I am assuming that this is just about the bare-bones compiler, but 
I have something I can work with now.

THANKS ALL!!!!

I will go ahead and try John's scripts and see how they work for me, but 
now that I can at least get something working, I have a better (slightly 
better) clue what I'm doing.




Just for the sake of neatness, here's what I did (either run as root or 
use sudo for the install steps!):

export DESTINATION=/usr/local
export TARGET=mips-elf
mkdir objdir
tar jxvf binutils-2.18.50.tar.bz2
tar zxfv gcc-core-4.1.2.tar.gz [&& other gcc-(lang)-4.1.2.tar.gz optional]
cd objdir
../binutils-2.18.50/configure --prefix=$DESTINATION \
      --target=$TARGET --program-prefix=$(TARGET)-
make
make install
../gcc-4.1.2/configure --prefix=$DESTINATION \
      --program-prefix=$(TARGET)- --target=$TARGET \
      --enable-languages=c --without-headers --disable-nls --disable-libssp
make
make install

I hope this helps someone.  Thanks, again, everyone that helped me!

(Still open to suggestions on building the various libc's! :-)  )

Wenton L. Davis
wenton@ieee.org

Re: Building a cross-compiler

[Kai Ruottu]

Michael Witten wrote:

> Creating a cross compiler _should_ be the easiest
> thing in the world, but the gcc is so backasswards
> that it can be troublesome.
Most problems really come from the total ignorance about what GCC
is and what it isn't :(   A "C compiler" usually includes a "C library" and
all the required "binutils" like 'as' (assembler) and 'ld' (linker). GCC 
then
is a "bare compiler" which only produces assembly (symbolic machine
code) text...  So a GCC builder MUST provide both the binutils and the
C library BEFORE starting to build a GCC !

People building native GCCs don't need to care about these things, of
course there are those prebuilt binutils for instance in '/usr/bin' and 
a prebuilt
C library in '/lib', '/usr/lib' and '/usr/include', in the Linux case.  
So those
required "target binutils and target C library" are already there....  
We should
always remember that the "native GCC" is the DEFAULT GCC type and
the cross GCC is only "another incarnation of the native GCC" on some
other host!  And therefore all the same prerequisites will exist...

So many cross GCC builders have really weird opinions about what the GCC
build should require and what it shouldn't, totally forgetting that 
"native" default :(

Producing a cross GCC then is just as easy as producing a native one when
one hasn't any weird "attitude problems". One accepts those prerequisites
for the binutils and the C library and the build is easy as a pie...  
This of course
is true only with  "existing"  targets.  In the Linux target cases  all 
the Linux
distros are "existing".  Some with that attitude problem always claim 
that they
don't exist or that people shouldn't care or should be prepared to the doom
day when all those prebuilt Linux binaries have been destroyed :)

When one wants to make one's own Linux distro "from scratch", there are
many choices to do that crosstoolchain with which to produce the self-built
Linux distro.

The easiest way is to bootstrap with something "existing". Making the target
binutils is easy and doesn't require anything else than the host GCC 
(with its
own binutils and C library). But producing GCC is problematic, a "Catch 22"
or "Chicken and egg", because the target C library is missing :(  The 
produced
GCC will produce it but when producing GCC requires the target C library
during its build, what on earth to do?

Fortunately the world is full of similar cases...  A car builder may 
accept using
"wrong but suitable tyres" when driving to the tyre shop for those 
"right" tyres.
Driving with bare wheels isn't a sane alternative...  In cross GCC world 
this
means for instance that a glibc for Linux/MIPS is "suitable" when 
producing a
GCC for a "self-made" Linux/MIPS distro... Or a Linux/MIPSEL one.  One
place where to find it is  a Debian Linux archive, both 'mips' and 
'mipsel' targets
are supported...

When one uses some existing C library during the "first" GCC build, one 
learns
the "normal GCC build", used with existing targets and when updating the 
GCC.

Much harder is to try to start from absolute scratch...  The sadly 
famous "crosstool"
tries to help the people with the attitude problems.  When using it 
people will never
learn how others will build their own crosstoolchains in less time than 
one hour :(
Even with old < 1 GHz PCs....  When always starting from absolute 
scratch again,
the productivity is horribly low!


>>> Last time I did it, I found I had to have the binutils --prefix 
>>> directory
>>> the same --prefix as the compiler.
This is the assumption!  A cross GCC must use its own 'as' and 'ld', 
with their bare
names, from somewhere else than the native GCC!  It is not a "human 
user" for
whom those '$target-<tool>'s are aimed :(   Both the native and a cross 
GCC will
try to launch 'as' and 'ld' from their own built-in search directories 
seen with the
well-known (even for newbies) :

     $target-gcc -print-search-dirs

Every newbie of course can ask on-line help :

     $target-gcc --help

from the GCC if not remembering those most usual options... Or can RTFM....

Ok, the '$tooldir/bin' aka '$prefix/$target/bin' is the place where 
those target binutils
will be installed.  There are many $gcc-version specific search places 
for GCC version
specific 'as' and 'ld' if these are required to work-around something. 
People can have
installed many GCC versions for one $target, these generally using the 
same binutils
and the same C library. Having many native GCCs isn't rare, neither 
having many cross
GCCs for one target.

All the previous was for those "true" cross GCCs, for the "system 
targets" which also
have native GCCs for them...  The method for a GCC build for an 
"embedded target",
one which doesn't have any "native GCC" ever, then is totally different 
case !

Using the 'newlib' free C library is the assumption for all those 
"unreal" targets  like the
"elves".  Some claim that they have seen an 'elf' or an 'angel' (the 
default target for 'arm-elf'),
or that 'p(oke)mon' for the 'mips-elf', used to be patched as the 
default target in the GCC's
'specs' file.  But I haven't seen either :(   I have seen Linuces, 
Unices and such "real" targets
however...  The question is where on earth those executables will run?  
If one doesn't ask
this question, then those "basic courses about computers" have failed 
miserably...

Producing a GCC for a newlib-using target basically requires only :

1. the target binutils
2..the generic newlib headers
3. using the '--with-newlib' in the GCC configure

The prerequisites 1. and 2. means these being preinstalled, the 2. a 
single 'cp -r' command
made for the proper 'newlib/libc/include' in the sources....  After that 
everything belonging
to the C/C++ compilers should be produced!  There are very old and weird 
bugs hurting
this but then these things have been discussed tens or hundreds or 
thousands times... Like
that "sys-include bug".  Just use Google and all these discussions will 
be found!

 

Re: Building a cross-compiler

[Andrew Haley]

Wenton L. Davis wrote:
> I am finally going to admit defeat and come ask for help on this.  I am 
> trying to build a cross-compiler to run on an x86 machine for several 
> targets: ARM, MIPS, AVR, and m681x.  I would like a single compiler to 
> handle those 4 architectures in addition to the x86, eventually.  
> However, for now, I am just trying to get the individual targets able to 
> compile.
> 
> I can get the binutils to compile/install/run just fine.  The compiler 
> build, however, is not cooperating, and I am almost certain I am 
> overlooking something remarkably simple, but I just don't see it.  I 
> have my source tree installed in /mnt/tmp/gcc-4.1.2 and I am building in 
> /mnt/tmp/objdir.  (I found one recommendation to always build in a 
> seperate directory.)  I configure it with the following (as run from in 
> objdir):
> 
> ../gcc-4.1.2/configure --prefix=/mnt/tmp --program-prefix=mips-elf- \
>  --target=mips-elf --enable-threads=posix --enable-shared \
>  --enable-languages=c --disable-checking --with-gnu-ld --verbose
> 
> 
> This should, as I understand it, build the MIPS's compiler and after 
> running "make install"put it in the /mnt/tmp/bin directory, prefixing 
> each executable with "mips-elf-"  right?
> 
> After configure runs, I just type 'make' to build the compiler.
> 
> Everything goes OK (now that I figured out the --enable-threads=posix 
> thing), until I get to this  (I apologize about the formatting, but I 
> wanted to send exactly what I see):
>
>                 from ../../gcc-4.1.2/gcc/unwind-dw2.c:42:
> ../../gcc-4.1.2/gcc/gthr-posix.h:43:21: error: pthread.h: No such file 
> or directory

OK, take a step backawards.  You're building a cross-compiler for MIPS, but
what operating system / C library do you intend to target?  gcc doesn't contain
a C library, and you are going to need one.  gcc also needs to know what OS
your target is going to run.

You can use newlib as a minimal target C library, but I'm not sure if that's
what you want.

Andrew.

Re: Building a cross-compiler

[John Carter]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4546 bytes --]

This set of scripts builds several things we use, including the gnu tool chain.

I tried writing it as a "make" file like thing, but that really didn't
work well.

So what it does is a fast compressed tar of the result of each step,
so you can start at or restart from any step. ie. You can make
mistakes faster, and hopefully converge on the right solution.

ie. You need buckets of disk space and a fast machine.

To fit all this into an email, I have excluded the source code tar
balls I use, anyway, you are probably using different ones.

Since you are probably using a different version of the tarballs than
I'm using, it's probably just best you d/load and move them into the
tarball directory your self.

You'll also have to tweak the include/BuildBlah.rb script to specify
the correct version.

If you're using a different version, you may well not need the patches.

For example the new_make_multiline_behaviour.patch copes with new
behaviour of gnu make when dealing with multiple line commands.

If you have an old version of make, you don't need it.

If you have a newer version of gcc, the patch has probably been applied.

GTC
|-- build_ecos
|-- build_nullmodem
|-- build_ruby
|-- build_tool_chain  <--- this is the script you're interested in.
|-- include
|   |-- BuildBinUtils.rb
|   |-- BuildEcos.rb
|   |-- BuildGcc.rb <-- This configures things for the right versions, options etc. Tweak here
|   |-- BuildGdb.rb <-- This configures things for the right versions, options etc. Tweak here
|   |-- BuildGnuToolChain.rb <-- This configures things for the right versions, options etc.
|   |-- BuildMachine.rb <-- this does the work
|   |-- Privilege.rb
|   |-- Utilities.rb
|   `-- WrapExecutables.rb <-- A bit weird, see body of email...
|-- patches <-- Patches go here
|   |-- ecos-cvs-1182121504.patch
|   |-- modra_binutils_fix.patch
|   `-- new_make_multiline_behaviour.patch
|-- result <-- Results end up as a tarball here
|-- tarballs <-- Src tar balls live here.
|-- test <-- Unit tests for the scripts live here.
|   |-- TC_AbstractBuildContext.rb
|   |-- TC_Action.rb
|   |-- TC_ActionConfigure.rb
|   |-- TC_ActionGet.rb
|   |-- TC_ActionLibraryPathWrapper.rb
|   |-- TC_ActionList.rb
|   |-- TC_ActionMake.rb
|   |-- TC_ActionMakeEcos.rb
|   |-- TC_ActionMakeLink.rb
|   |-- TC_ActionPatch.rb
|   |-- TC_ActionUnpack.rb
|   |-- TC_EcosContext.rb
|   |-- TC_GnuContext.rb
|   |-- TC_Stub.rb
|   |-- TC_WrapExecutables.rb
|   `-- TS_BuildToolChain.rb
`-- wrap_executable

5 directories, 33 files

The Wrap executable idea is a bit weird, perhaps I should back off
from that one...

I found the team evolved a diverse set of distributions and versions
of linux. And since gcc seems to _insist_ on being a dynamically
linked, not a statically linked executable these days.... It can be a
problem. A Big Problem.

You have to build on the _oldest_ platform (usually with the slowest
hardware too) in the team... and hope the rest have backward
compatible DLL's lying around!

Or you have to build afresh on _every_ distro / version used.

Or you force every on the team to the exact same distro / version.

Or you have do what I've done. Which is deliver _every_ dll used by
_every_ executable and replace every executable by a shell script that
loads the delivered dlls.

Have fun.  The license on this one GPL, since it has chunks of GPL'd
and copied from GPL'd code in it.


On Mon, 28 Jan 2008, Wenton L. Davis wrote:

> John Carter wrote:
>> 
>> It's a _very_ dark art....
> No kidding!!!!
>> 
>> Some hints:...

> OK, this could very easily be the problem.  I was assuming this was built as 
> a part of the gcc build, but that does not appear to be the case.  But if the 
> compiler needs libc to build, and libc is built by compiling.... which came 
> first, the chicken or the egg?

The libc headers are needed to build the compiler chicken which grows
up to compile the libc egg.

> Well, I'm not real familiar with ruby (it's on my list of languages to look 
> at), but I can't imagine it's so bizarre I can't glean a little info from it. 
> If you would please, send me your scripts, and even if they don't work, they 
> might give me some more ideas.  Thanks!

http://www.ruby-doc.org/

is a very useful resource.

http://ruby-lang.org for the ruby source code.

(My script even builds ruby :-)


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 17930 bytes --]

Re: Building a cross-compiler

[James Tebneff]

On Jan 29, 2008 11:06 AM, Michael Witten <mfwitten@mit.edu> wrote:
>
> On 28 Jan 2008, at 6:44 PM, Wenton L. Davis wrote:
>
> > John Carter wrote:
> >>
> >> It's a _very_ dark art....
> > No kidding!!!!
>
> I disagree wholeheartedly.
>
> Creating a cross compiler _should_ be the easiest
> thing in the world, but the gcc is so backasswards
> that it can be troublesome.
>
> >> Some hints:...
> >>
> >> There is a nasty tangly dependency between binutils, libc and the
> >> compiler.
> >>
> >> Last time I did it, I found I had to have the binutils --prefix
> >> directory
> >> the same --prefix as the compiler.
>
> This is definitely the case; gcc is really just an
> interface to a bunch of different tools, so it needs
> to know where to find those tools.
>
> It would be nice if there were a configure directive
> to specify the location of binutils tools for greater
> flexibility. For now, just make --prefix the same for
> both.
>
> In any case, you're supposed to be able to put the
> binutils source subdirectories (gprof, opcodes,
> bintutils, ...) inside the top level of the gcc source
> code so that one configure invocation handles both; both
> source trees are actually 2 separate views of a larger
> tree.
>


Yes check out the documentation for a Combined build

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

Regards

JT

RE: Building a cross-compiler

[Rupert Wood]

Wenton L. Davis wrote:

> OK, this could very easily be the problem.  I was assuming this was 
> built as a part of the gcc build, but that does not appear to be the
> case.  But if the compiler needs libc to build, and libc is built
> by compiling.... which came first, the chicken or the egg?

You build the compiler in two halves; you run

    make all-gcc
    make install-gcc

to build the compiler but not its support libraries, and then you can use that to build a libc. Once you've built and installed libc you can restart your GCC build but it's probably safest to start a new build from scratch at that point. In your case 'make all-gcc' is probably a no-op from what you have, but I'm not sure you really want --enable-threads for mips-elf which is presumably an embedded target?

You probably want to fetch and build newlib, unless you're targeting a Linux system when you likely want glibc. In the first case you could instead do a combined tree build of GCC and newlib by adapting the instructions at http://gcc.gnu.org/simtest-howto.html, or in the latter - glibc - you can use the scripts at http://kegel.com/crosstool/. Of course if you already have libraries and headers for your target from somewhere else you should pass them to the compiler with --with-sysroot and it should already just work.

Good luck!
Rup.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Building a cross-compiler

[Michael Witten]

On 28 Jan 2008, at 6:44 PM, Wenton L. Davis wrote:

> John Carter wrote:
>>
>> It's a _very_ dark art....
> No kidding!!!!

I disagree wholeheartedly.

Creating a cross compiler _should_ be the easiest
thing in the world, but the gcc is so backasswards
that it can be troublesome.

>> Some hints:...
>>
>> There is a nasty tangly dependency between binutils, libc and the
>> compiler.
>>
>> Last time I did it, I found I had to have the binutils --prefix  
>> directory
>> the same --prefix as the compiler.

This is definitely the case; gcc is really just an
interface to a bunch of different tools, so it needs
to know where to find those tools.

It would be nice if there were a configure directive
to specify the location of binutils tools for greater
flexibility. For now, just make --prefix the same for
both.

In any case, you're supposed to be able to put the
binutils source subdirectories (gprof, opcodes,
bintutils, ...) inside the top level of the gcc source
code so that one configure invocation handles both; both
source trees are actually 2 separate views of a larger
tree.

> At this point, I tried the brute force, copying the exact command  
> line, but adding to it the -I../../(etc) to find the unistd.h and  
> pthreads.h, but it failed because of an #endif without #if error...  
> I thought I'd manually modify this file, but it was automagically  
> created by fixincludes.  (?!?!?)

Do you need libc on these other targets? If not, use
--without-headers to indicate that you have no intention
of building libc or the runtime libraries like libstdc++.
See below.

If --without-headers is indeed what you want, then make
sure you specify the --target properly. If you include
'linux' in there, the build will fail trying to use glibc
headers to build parts of libgcc that are Linux specific
(or something like that), because--as stated before--the
gcc is backasswards.

If you need libc, I've seen people do 2 things, you should
probably grab the libraries and headers from each target
and put them (or build them on each target and install them)
into a directory on your host machine; pass this directory
to --with-sysroot during the configuration of gcc.

That's my understanding.


>> You then need to have the target libc in the appropriate level of the
>> gcc src tree. Your error messages suggest to me you either don't have
>> a libc build, or have it at the wrong level.

I'm not sure this is correct. Take a look at
--with-sysroot

I have always only made "naked" (libc-less) cross
compilers, but I believe that configuration switch
should be hardcoded into the final gcc to tell it
where to look for libc stuff (much in the same way
I'd like to be able to configure gcc to look for binutils
in some nonstandard place).

> OK, this could very easily be the problem.  I was assuming this was  
> built as a part of the gcc build, but that does not appear to be the  
> case.  But if the compiler needs libc to build, and libc is built by  
> compiling.... which came first, the chicken or the egg?
>>
>> I found I couldn't build it "out the box" for the variants I was
>> building for, I had to find and apply some patches. (Not too
>> surprising, given the combinatorial explosion of host os X host CPU X
>> target os X target CPU X libc implementation X libc version X  
>> binutils
>> version, they simply can't test everything.)
>>
> I absolutely agree... there must be several thousand combinations.   
> I sometimes wonder if this works against the linux community rather  
> than for it?

Against. Then again, Linux can't be built easily outside of
standard Linuxy environments, as it too is backasswards, because
it depends on other backasswards GNU setups. For instance, the
kernel requires certain headers, like /etc/include/elf.h, but elf.h
is only included with glibc. Then one must ask, why the hell would
glibc concern itself with elf.h ? That should be part of binutils
or something.

>> Good Luck! I can email you my scripts for building things, can't
>> guarantee they'll work for you though! Being in Ruby, I find them  
>> easy to
>> read / maintain than the cross gcc shell script project.

I have a Gentoo Linux box that is rather slow. I have a much faster
PowerBook G4. Therefore, I wanted to use the PowerBook to compile
stuff for use with the Gentoo box.

Interestingly, distcc (which distributes compilation across machines)
preprocesses code on the one client machine, so that only direct comp-
ilation to Object Code is necessary on each server. This means the  
server
need not have libraries or headers common to the client machine.

For this reason, I built a naked cross compiler on the PowerBook:
(or something similar)

	tar xjf binutils-2.17.tar.bz2
	mv binutils-2.17 src
	
	mkdir build
	cd build
	
	export PREFIX=/usr/local/xgcc
	export TARGET=i686-elf
	
	../src/configure --target=$TARGET --prefix=$PREFIX --disable-nls
	
	make -j3
	sudo make install
	
	--------------------------------
	
	tar xjf gcc-core-4.1.2.tar.bz2 && tar xjf gcc-g++-4.1.2.tar.bz2
	mv gcc-4.1.2 src
	
	mkdir build
	cd build
	
	export PATH=$PATH:$PREFIX/bin
	
	../src/configure --target=$TARGET --prefix=$PREFIX --disable-nls -- 
enable-languages=c,c++ --without-headers
	
	MACOSX_DEPLOYMENT_TARGET=10.4 make -j3 all-gcc
	sudo make install-gcc

BUT!

I had to link $PREFIX/bin/i686-elf-* to $PREFIX/bin/i686-pc-linux-gnu- 
*, because of
backasswardsness; there is a gcc configuration switch to mangle the  
names, but
this can cause problems if you configure binutils with mangled names  
too.

I hope this helps / is correct.

Sincerely,
Michael Witten

Re: Building a cross-compiler

[Wenton L. Davis]

John Carter wrote:
>
> It's a _very_ dark art....
No kidding!!!!
>
> Some hints:...
>
> There is a nasty tangly dependency between binutils, libc and the
> compiler.
>
> Last time I did it, I found I had to have the binutils --prefix directory
> the same --prefix as the compiler.
>
At first, I thought that might be the problem because once I 
"test"-built that, I reconfigured and rebuilt and installed into the 
/usr/local.  So, I went back to building the binutils and kept them in 
the /mnt/tmp directory, then tried to build gcc on top of that.  For 
some reason, it failed because it couldn't create a file in the 
gcc/libiberty/pic directory (because the directory didn't exist) so I 
created the gcc/libiberty/pic directory, and make was able to continue, 
but I still ended up with the same problem.  (the unistd.h and 
pthreads.h files missing)

At this point, I tried the brute force, copying the exact command line, 
but adding to it the -I../../(etc) to find the unistd.h and pthreads.h, 
but it failed because of an #endif without #if error... I thought I'd 
manually modify this file, but it was automagically created by 
fixincludes.  (?!?!?)
> You then need to have the target libc in the appropriate level of the
> gcc src tree. Your error messages suggest to me you either don't have
> a libc build, or have it at the wrong level.
>
OK, this could very easily be the problem.  I was assuming this was 
built as a part of the gcc build, but that does not appear to be the 
case.  But if the compiler needs libc to build, and libc is built by 
compiling.... which came first, the chicken or the egg?
>
> I found I couldn't build it "out the box" for the variants I was
> building for, I had to find and apply some patches. (Not too
> surprising, given the combinatorial explosion of host os X host CPU X
> target os X target CPU X libc implementation X libc version X binutils
> version, they simply can't test everything.)
>
I absolutely agree... there must be several thousand combinations.  I 
sometimes wonder if this works against the linux community rather than 
for it?
> Good Luck! I can email you my scripts for building things, can't
> guarantee they'll work for you though! Being in Ruby, I find them easy to
> read / maintain than the cross gcc shell script project.
>
Well, I'm not real familiar with ruby (it's on my list of languages to 
look at), but I can't imagine it's so bizarre I can't glean a little 
info from it.  If you would please, send me your scripts, and even if 
they don't work, they might give me some more ideas.  Thanks!

Wenton L. Davis
wenton@ieee.org

Re: Building a cross-compiler

[John Carter]

On Mon, 28 Jan 2008, Wenton L. Davis wrote:

> I am finally going to admit defeat and come ask for help on this.  I am 
> trying to build a cross-compiler to run on an x86 machine for several 
> targets: ARM, MIPS, AVR, and m681x.  I would like a single compiler to handle 
> those 4 architectures in addition to the x86, eventually.  However, for now, 
> I am just trying to get the individual targets able to compile.

It's a _very_ dark art....

Some hints:...

There is a nasty tangly dependency between binutils, libc and the
compiler.

Last time I did it, I found I had to have the binutils --prefix directory
the same --prefix as the compiler.

You then need to have the target libc in the appropriate level of the
gcc src tree. Your error messages suggest to me you either don't have
a libc build, or have it at the wrong level.


I found I couldn't build it "out the box" for the variants I was
building for, I had to find and apply some patches. (Not too
surprising, given the combinatorial explosion of host os X host CPU X
target os X target CPU X libc implementation X libc version X binutils
version, they simply can't test everything.)

Good Luck! I can email you my scripts for building things, can't
guarantee they'll work for you though! Being in Ruby, I find them easy to
read / maintain than the cross gcc shell script project.


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Building a cross-compiler

[Wenton L. Davis]

I am finally going to admit defeat and come ask for help on this.  I am 
trying to build a cross-compiler to run on an x86 machine for several 
targets: ARM, MIPS, AVR, and m681x.  I would like a single compiler to 
handle those 4 architectures in addition to the x86, eventually.  
However, for now, I am just trying to get the individual targets able to 
compile.

I can get the binutils to compile/install/run just fine.  The compiler 
build, however, is not cooperating, and I am almost certain I am 
overlooking something remarkably simple, but I just don't see it.  I 
have my source tree installed in /mnt/tmp/gcc-4.1.2 and I am building in 
/mnt/tmp/objdir.  (I found one recommendation to always build in a 
seperate directory.)  I configure it with the following (as run from in 
objdir):

../gcc-4.1.2/configure --prefix=/mnt/tmp --program-prefix=mips-elf- \
  --target=mips-elf --enable-threads=posix --enable-shared \
  --enable-languages=c --disable-checking --with-gnu-ld --verbose


This should, as I understand it, build the MIPS's compiler and after 
running "make install"put it in the /mnt/tmp/bin directory, prefixing 
each executable with "mips-elf-"  right?

After configure runs, I just type 'make' to build the compiler.

Everything goes OK (now that I figured out the --enable-threads=posix 
thing), until I get to this  (I apologize about the formatting, but I 
wanted to send exactly what I see):

/mnt/tmp/objdir/./gcc/xgcc -B/mnt/tmp/objdir/./gcc/ 
-B/mnt/tmp/mips-elf/bin/ -B/mnt/tmp/mips-elf/lib/ -isystem 
/mnt/tmp/mips-elf/include -isystem /mnt/tmp/mips-elf/sys-include -O2  
-O2 -g -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include  -G 0 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.1.2/gcc 
-I../../gcc-4.1.2/gcc/. -I../../gcc-4.1.2/gcc/../include 
-I../../gcc-4.1.2/gcc/../libcpp/include   -fexceptions -c 
../../gcc-4.1.2/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
In file included from ./gthr-default.h:1,
                 from ../../gcc-4.1.2/gcc/gthr.h:114,
                 from ../../gcc-4.1.2/gcc/unwind-dw2.c:42:
../../gcc-4.1.2/gcc/gthr-posix.h:43:21: error: pthread.h: No such file 
or directory
../../gcc-4.1.2/gcc/gthr-posix.h:44:20: error: unistd.h: No such file or 
directory
In file included from ./gthr-default.h:1,
                 from ../../gcc-4.1.2/gcc/gthr.h:114,
                 from ../../gcc-4.1.2/gcc/unwind-dw2.c:42:
../../gcc-4.1.2/gcc/gthr-posix.h:46: error: expected '=', ',', ';', 
'asm' or '__attribute__' before '__gthread_key_t'
../../gcc-4.1.2/gcc/gthr-posix.h:47: error: expected '=', ',', ';', 
'asm' or '__attribute__' before '__gthread_once_t'
../../gcc-4.1.2/gcc/gthr-posix.h:48: error: expected '=', ',', ';', 
'asm' or '__attribute__' before '__gthread_mutex_t'
../../gcc-4.1.2/gcc/gthr-posix.h:49: error: expected '=', ',', ';', 
'asm' or '__attribute__' before '__gthread_recursive_mutex_t'
../../gcc-4.1.2/gcc/gthr-posix.h:88: error: 'pthread_once' undeclared 
here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:88: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_once'
../../gcc-4.1.2/gcc/gthr-posix.h:89: error: 'pthread_getspecific' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:89: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_getspecific'
../../gcc-4.1.2/gcc/gthr-posix.h:90: error: 'pthread_setspecific' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:90: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_setspecific'
../../gcc-4.1.2/gcc/gthr-posix.h:91: error: 'pthread_create' undeclared 
here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:91: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_create'
../../gcc-4.1.2/gcc/gthr-posix.h:92: error: 'pthread_cancel' undeclared 
here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:92: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_cancel'
../../gcc-4.1.2/gcc/gthr-posix.h:93: error: 'pthread_mutex_lock' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:93: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_mutex_lock'
../../gcc-4.1.2/gcc/gthr-posix.h:94: error: 'pthread_mutex_trylock' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:94: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_mutex_trylock'
../../gcc-4.1.2/gcc/gthr-posix.h:95: error: 'pthread_mutex_unlock' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:95: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_mutex_unlock'
../../gcc-4.1.2/gcc/gthr-posix.h:96: error: 'pthread_mutex_init' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:96: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_mutex_init'
../../gcc-4.1.2/gcc/gthr-posix.h:99: error: 'pthread_key_create' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:99: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_key_create'
../../gcc-4.1.2/gcc/gthr-posix.h:100: error: 'pthread_key_delete' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:100: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_key_delete'
../../gcc-4.1.2/gcc/gthr-posix.h:101: error: 'pthread_mutexattr_init' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:101: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_mutexattr_init'
../../gcc-4.1.2/gcc/gthr-posix.h:102: error: 'pthread_mutexattr_settype' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:102: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_mutexattr_settype'
../../gcc-4.1.2/gcc/gthr-posix.h:103: error: 'pthread_mutexattr_destroy' 
undeclared here (not in a function)
../../gcc-4.1.2/gcc/gthr-posix.h:103: warning: type defaults to 'int' in 
declaration of '__gthrw_pthread_mutexattr_destroy'
../../gcc-4.1.2/gcc/gthr-posix.h:513: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:522: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:528: error: expected ')' before 'key'
../../gcc-4.1.2/gcc/gthr-posix.h:534: error: expected ')' before 'key'
../../gcc-4.1.2/gcc/gthr-posix.h:540: error: expected ')' before 'key'
../../gcc-4.1.2/gcc/gthr-posix.h:546: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:555: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:564: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:574: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:595: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:601: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/gthr-posix.h:607: error: expected ')' before '*' token
../../gcc-4.1.2/gcc/unwind-dw2.c: In function 'uw_init_context_1':
../../gcc-4.1.2/gcc/unwind-dw2.c:1259: error: expected '=', ',', ';', 
'asm' or '__attribute__' before 'once_regsizes'
../../gcc-4.1.2/gcc/unwind-dw2.c:1259: error: 'once_regsizes' undeclared 
(first use in this function)
../../gcc-4.1.2/gcc/unwind-dw2.c:1259: error: (Each undeclared 
identifier is reported only once
../../gcc-4.1.2/gcc/unwind-dw2.c:1259: error: for each function it 
appears in.)
../../gcc-4.1.2/gcc/unwind-dw2.c:1259: error: 'PTHREAD_ONCE_INIT' 
undeclared (first use in this function)
../../gcc-4.1.2/gcc/unwind-dw2.c:1260: warning: implicit declaration of 
function '__gthread_once'
make[3]: *** [libgcc/./unwind-dw2.o] Error 1
make[3]: Leaving directory `/mnt/tmp/objdir/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/mnt/tmp/objdir/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/mnt/tmp/objdir'
make: *** [all] Error 2

I have tried this same process using different versions (4.1.1, 4.1.2, 
4.2.2) of gcc and I keep hitting this same wall. II can find 
gcc-4.1.2/fixincludes/tests/base/sys/pthread.h and 
gcc-4.1.2/fixincludes/tests/base/pthread.h as well as 
gcc-4.1.2/fixincludes/tests/base/unistd.h and 
gcc-4.1.2/libssp/ssp/unistd.h, but none of these directory paths appear 
to be included with -I ... parameters.  This is what leads me to believe 
that I am somehow missing something in my configure command, but I just 
can't figure it out.

Alternatively, I am only untar-ing  the gcc-core-4.x.x.tar.gz.... I only 
need the 'C' compiler, not the C++ or ada or others.  I have tried 
untar-ing all of them, but the build still failed.

Please help!
Wenton L. Davis
wenton@ieee.org

RE: Building a cross-compiler

[James Don]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Hi Jeff,

Here's a script I slopped together for gcc-2.95.3 from some www sources ... 

I recommend you don't use libstdc++ part of the script ... use what ever stl
etc comes with the g++-core package ... people will just ignore you for the
better part if you have troubles building this and tell you to read the FAQ
etc (which is not really that useful) ...

I'll hopefully clean it up and make a Makefile version later this month when
I have a free moment ...

Hope this helps,
Jim



-----Original Message-----
From: Jeff Elkins [mailto:jeffelkins@earthlink.net] 
Sent: Monday, March 03, 2003 9:28 AM
To: gcc-help@gcc.gnu.org
Subject: Building a cross-compiler

I'm attempting to build a cross-compiler for i686->powerpc using directions
I 
found  at http://www.x86-64.org/documentation_folder/build and  
http://penguinppc.org/embedded/cross-compiling/

I get the error:

config/rs6000/linux.h:81:20: signal.h: No such file or directory
config/rs6000/linux.h:82:26: sys/ucontext.h: No such file or directory
make[2]: *** [libgcc/./_muldi3.o] Error 1
make[2]: Leaving directory `/home/jeff/gcc-3.2.2/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/jeff/gcc-3.2.2/gcc'
make: *** [all-gcc] Error 2

Thanks for any assistance,

Jeff Elkins


[-- Attachment #2: buildgcc.sh --]
[-- Type: application/octet-stream, Size: 6649 bytes --]

#!/bin/bash

#
# Get, build and install the latest cross-development tools and libraries
#

#
# Specify the architectures for which the tools are to be built
# To build for multiple targets: ARCHS="m68k ppc i386"
#
ARCHS="powerpc-linux"

#
# Where to install
#
PREFIX=$HOME/ppcgcc/

#
# My kernel includes
#
KERNEL=$HOME/ppclinux/include/

#
# Where to get the GNU tools
#
RTEMS_BINUTILS_URL=ftp://ftp.gnu.org/gnu/binutils/
RTEMS_GCC_URL=ftp://ftp.gnu.org/gnu/gcc/gcc-2.95.3/
RTEMS_NEWLIB_URL=ftp://sources.redhat.com/pub/newlib/
GLIBC_URL=ftp://ftp.gnu.org/gnu/glibc
LIBSTDC_URL=ftp://ftp.gnu.org/gnu/libstdc++

#
# Specify the versions
#
GCC_VER=2.95.3
GCC=gcc-core-$GCC_VER
BINUTILS=binutils-2.13.2.1
NEWLIB=newlib-1.10.0
GLIBC_VER=2.2.5

#
# Get the source
#
getSource() {
    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_BINUTILS_URL/$BINUTILS.tar.gz
    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_BINUTILS_URL/$BINUTILS*.diff

    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_GCC_URL/$GCC.tar.gz
    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_GCC_URL/$GCC*.diff

    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_NEWLIB_URL/$NEWLIB.tar.gz
    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_NEWLIB_URL/$NEWLIB*.diff
}

getSourceGLIBC() {
    wget --passive-ftp --no-directories --retr-symlinks $GLIBC_URL/glibc-$GLIBC_VER.tar.gz
    wget --passive-ftp --no-directories --retr-symlinks $GLIBC_URL/glibc-$GLIBC_VER*.diff
    wget --passive-ftp --no-directories --retr-symlinks $GLIBC_URL/glibc-linuxthreads-$GLIBC_VER.tar.gz

    

}


#
# UnpackGCC
#
unpackGCC() {

   rm -rf gcc-$GCC_VER
    tar xvfz $GCC.tar.gz
    for d in $GCC*.diff
    do
        if [ -r "$d" ]
        then
            cat "$d" | (cd gcc-$GCC_VER ; patch -p1)
        fi
    done
}

#
# Unpack the source
#
unpackSource() {
    rm -rf $BINUTILS
    tar xvfz $BINUTILS.tar.gz 
    for d in $BINUTILS*.diff
    do
        if [ -r "$d" ]
        then
            cat "$d" | (cd $BINUTILS ; patch -p1)
        fi
    done

    unpackGCC

    rm -rf $NEWLIB
    tar xvfz $NEWLIB.tar.gz
    for d in $NEWLIB*.diff
    do
        if [ -r "$d" ]
        then
            cat "$d" | (cd $NEWLIB ; patch -p1)
        fi
    done
    cd gcc-$GCC_VER 
    ln -s ../$NEWLIB/newlib newlib
    ln -s ../$NEWLIB/libgloss libgloss
    cd ..
}

unpackGLIBC() {

   rm -rf glibc-$GLIBC_VER
   tar xvfz glibc-$GLIBC_VER.tar.gz
   for d in glibc-$GLIBC_VER*.diff
   do
      if [ -r "$d" ]
      then
         cat "$d" | (cd glibc-$GLIBC_VER ; patch -p1)
        fi
    done
    cd glibc-$GLIBC_VER
    tar xvfz ../glibc-linuxthreads-$GLIBC_VER.tar.gz
    cd ..

}

#
# Build
#
build() {
    PATH=$PREFIX/bin:$PATH
    export PATH
    for arch in $ARCHS
    do
        rm -rf BINUTILS
        mkdir BINUTILS
        cd BINUTILS
        ../$BINUTILS/configure --target=$arch --prefix=$PREFIX
	make
        make install
        cd ..

        rm -rf GCC
        mkdir  GCC
        cd GCC
        ../gcc-$GCC_VER/configure --target=$arch --prefix=$PREFIX \
            --with-gnu-as --with-gnu-ld --verbose \
            --with-system-zlib --disable-nls \
            --disable-threads \
	    --disable-shared  \
            --with-newlib \
	    --with-headers=$KERNEL \
            --enable-languages=c

	make
        make install
        cd ..
    done
}

build_glibc() {
    PATH=$PREFIX/bin:$PATH
    export PATH
    for arch in $ARCHS
    do
	rm -rf GLIBC
	mkdir GLIBC
	cd GLIBC
	rm -rf $PREFIX/$arch/include $PREFIX/$arch/sys-include $PREFIX/$arch/lib

        CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib \
                ../glibc-$GLIBC_VER/configure \
	 	--host=$arch \
                --enable-add-ons=linuxthreads \
                --with-headers=$KERNEL  \
                --prefix=$PREFIX/$arch
	make
	make install
	cd ..
   done
}

build_gcc_glibc() {
    PATH=$PREFIX/bin:$PATH
    export PATH
    for arch in $ARCHS
    do

	
	rm -rf GCC_GLIBC
	mkdir GCC_GLIBC
	cd GCC_GLIBC
        ../gcc-$GCC_VER/configure --target=$arch --prefix=$PREFIX/ \
                 --with-gnu-as --with-gnu-ld \
                 --enable-shared \
                 --enable-threads=posix \
                 --enable-languages=c \
                 --with-headers=$KERNEL
	make
        make install
	cd ..


    done
}

getCPPSource() {
    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_GCC_URL/gcc-g++-$GCC_VER.tar.gz
    wget --passive-ftp --no-directories --retr-symlinks $RTEMS_GCC_URL/gcc-g++-$GCC_VER*.diff
    wget --passive-ftp --no-directories --retr-symlinks $LIBSTDC_URL/libstdc++-2.90.8.tar.gz
}

unpackCPPSource(){
    pwd
    echo UNPACK G++
    tar xfz gcc-g++-$GCC_VER.tar.gz
}

build_g++_glibc() {
    PATH=$PREFIX/bin:$PATH
    export PATH
    for arch in $ARCHS
    do

	
	rm -rf G++_GLIBC
	mkdir G++_GLIBC
	cd G++_GLIBC
        #cd gcc-$GCC_VER
        ../gcc-$GCC_VER/configure --target=$arch --prefix=$PREFIX \
	    --with-gnu-as --with-gnu-ld \
	    --enable-shared \
	    --enable-threads=posix \
	    --enable-languages=c,c++ \
	    --enable-version-specific-runtime-libs \
	    --with-headers=$KERNEL --with-sysroot=$PREFIX/

	make
        #make install
	cd ..


    done
}

unpackStd() {
    pwd
    echo UNPASK STDC
    tar xfz libstdc++-2.90.8.tar.gz
    patch -p0 -b -z.ORIG < libstdc++-2.90.8-compat-gcc-2.95.3.diff
    cd gcc-$GCC_VER
    mv libstdc++ libstdc++ORIG
    mv libio     libioORIG
    cp -rf ../libstdc++-2.90.8 ./
    mv ./libstdc++-2.90.8 ./libstdc++ 
    cd ..
}


#
# Do everything
#
# Comment out any activities you wish to omit
#
#set -ex

export PATH=$PREFIX/bin/:$PATH

echo ====================================
echo BUILD BOOT STRAPPED COMPILER
echo ====================================
#sleep 10
#getSource
#unpackSource
#unpackCPPSource
#build


echo ====================================
echo BUILD GLIBC
echo ====================================
#getSourceGLIBC
unpackGLIBC
build_glibc

echo ====================================
echo BUILD GCC WITH GLIBC
echo ====================================
unpackGCC
build_gcc_glibc

echo =====================================
echo BUILD G++/GCC WITH GLIBC AND LIBSTC++
echo =====================================
#getCPPSource
#unpackGCC
#unpackCPPSource
#unpackStd
#build_g++_glibc