* Building a cross-compiler
@ 2008-01-29 4:17 Wenton L. Davis
2008-01-29 4:32 ` John Carter
2008-01-29 19:04 ` Andrew Haley
0 siblings, 2 replies; 12+ messages in thread
From: Wenton L. Davis @ 2008-01-29 4:17 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
2008-01-29 4:17 Building a cross-compiler Wenton L. Davis
@ 2008-01-29 4:32 ` John Carter
2008-01-29 4:47 ` Wenton L. Davis
2008-01-29 19:04 ` Andrew Haley
1 sibling, 1 reply; 12+ messages in thread
From: John Carter @ 2008-01-29 4:32 UTC (permalink / raw)
To: Wenton L. Davis; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
2008-01-29 4:32 ` John Carter
@ 2008-01-29 4:47 ` Wenton L. Davis
2008-01-29 5:05 ` Michael Witten
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Wenton L. Davis @ 2008-01-29 4:47 UTC (permalink / raw)
To: John Carter; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
2008-01-29 4:47 ` Wenton L. Davis
@ 2008-01-29 5:05 ` Michael Witten
2008-01-29 6:54 ` James Tebneff
2008-01-29 20:24 ` Kai Ruottu
2008-01-29 6:11 ` Rupert Wood
2008-01-29 9:58 ` John Carter
2 siblings, 2 replies; 12+ messages in thread
From: Michael Witten @ 2008-01-29 5:05 UTC (permalink / raw)
To: Wenton L. Davis, John Carter; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
2008-01-29 5:05 ` Michael Witten
@ 2008-01-29 6:54 ` James Tebneff
2008-01-29 20:24 ` Kai Ruottu
1 sibling, 0 replies; 12+ messages in thread
From: James Tebneff @ 2008-01-29 6:54 UTC (permalink / raw)
To: Michael Witten; +Cc: Wenton L. Davis, John Carter, gcc-help
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
2008-01-29 5:05 ` Michael Witten
2008-01-29 6:54 ` James Tebneff
@ 2008-01-29 20:24 ` Kai Ruottu
1 sibling, 0 replies; 12+ messages in thread
From: Kai Ruottu @ 2008-01-29 20:24 UTC (permalink / raw)
To: gcc-help
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!
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Building a cross-compiler
2008-01-29 4:47 ` Wenton L. Davis
2008-01-29 5:05 ` Michael Witten
@ 2008-01-29 6:11 ` Rupert Wood
2008-01-29 9:58 ` John Carter
2 siblings, 0 replies; 12+ messages in thread
From: Rupert Wood @ 2008-01-29 6:11 UTC (permalink / raw)
To: 'Wenton L. Davis', 'John Carter'; +Cc: gcc-help
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
______________________________________________________________________
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
2008-01-29 4:47 ` Wenton L. Davis
2008-01-29 5:05 ` Michael Witten
2008-01-29 6:11 ` Rupert Wood
@ 2008-01-29 9:58 ` John Carter
2 siblings, 0 replies; 12+ messages in thread
From: John Carter @ 2008-01-29 9:58 UTC (permalink / raw)
To: Wenton L. Davis; +Cc: gcc-help
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
2008-01-29 4:17 Building a cross-compiler Wenton L. Davis
2008-01-29 4:32 ` John Carter
@ 2008-01-29 19:04 ` Andrew Haley
1 sibling, 0 replies; 12+ messages in thread
From: Andrew Haley @ 2008-01-29 19:04 UTC (permalink / raw)
To: Wenton L. Davis; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Building a cross-compiler
@ 2008-01-31 15:33 Wenton L. Davis
0 siblings, 0 replies; 12+ messages in thread
From: Wenton L. Davis @ 2008-01-31 15:33 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Building a cross-compiler
@ 2003-03-03 14:33 James Don
0 siblings, 0 replies; 12+ messages in thread
From: James Don @ 2003-03-03 14:33 UTC (permalink / raw)
To: 'Jeff Elkins'; +Cc: 'gcc-help@gcc.gnu.org'
[-- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Building a cross-compiler
@ 2003-03-03 14:28 Jeff Elkins
0 siblings, 0 replies; 12+ messages in thread
From: Jeff Elkins @ 2003-03-03 14:28 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-01-29 20:31 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-29 4:17 Building a cross-compiler Wenton L. Davis
2008-01-29 4:32 ` John Carter
2008-01-29 4:47 ` Wenton L. Davis
2008-01-29 5:05 ` Michael Witten
2008-01-29 6:54 ` James Tebneff
2008-01-29 20:24 ` Kai Ruottu
2008-01-29 6:11 ` Rupert Wood
2008-01-29 9:58 ` John Carter
2008-01-29 19:04 ` Andrew Haley
-- strict thread matches above, loose matches on Subject: below --
2008-01-31 15:33 Wenton L. Davis
2003-03-03 14:33 James Don
2003-03-03 14:28 Jeff Elkins
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).