building native cross compiler

building native cross compiler

[Michael Zintakis]

I have a bit of a conundrum - I am trying to build native cross compiler 
which allows me to compile software which is able to run on 3 platforms: 
x86_64, i585(i686) and powerpc (G2).

The host environment is x86_64, though as native compiler it should not 
use anything from that environment when compiling the software, or at 
least I would like to avoid that as much as possible. One other thing of 
note is that during the software-building process the whole environment 
will be chroot-ed. In the complete image file when the software is built 
there should also be natively-built GCC compiler for the target 
environment (i586/i686 and powerpc).

This used to be pretty straight-forward when host and target platforms 
are the same (3-stage bootstrap, chroot to the target environment image 
and then use the freshly-built GCC to compile the rest of the software), 
but I now have the new task of getting a native cross-compiler built to 
take advantage of the processing power in the host environment, which is 
x86_64 (quad core CPUs).

I have read the help pages (http://gcc.gnu.org/install/build.html) and 
particularly the 2 sections "Building a native compiler" and "Building a 
cross compiler", but there are things in it which aren't very clear to me.

The "Building a cross compiler" section suggests that 3-stage 
bootstrapping is not possible and recommends building and installing 
(presumably in the chrooted environment) a native compiler which is then 
used to build the cross compiler (at least that is my interpretation of 
this).

1. Does that mean that I should follow the steps in the previous section 
("Building a native compiler"), use the 3-stage bootstrapping and after 
this use the resulting compiler to build another GCC cross compiler 
(including the appropriate toolchain) for the 3 architectures I am 
interested in and use this compiler to build my software?

2.  I am also assuming that the native GCC compiler which builds the 
native cross-compiler needs to be for the host environment (x86_64) or 
have I got this wrong?

3. If that is the case what steps should I use to build the GCC compiler 
for the target image architectures (powerpc and i586/i686)?

4. Further in that section ("Building a cross compiler") there is 
reference in it which advices that after building the native compiler I 
should configure the cross compiler and then issue 'make' which will 
automatically build the 'host' tools (host as in the 'host' 
architecture?!) necessary to build the compiler as well as the 'target' 
tools for use of the compiler (again, I assume target as in the 'target' 
architectures I am interested in), then build the compiler itself 
(single-stage only) and "Build runtime libraries using the compiler from 
the previous step". That last bit isn't completely clear to me - what 
previous step?

5. I assume at the end of this process I will end up with my native 
cross compiler which I could then use to build my software. Do I need to 
do anything else?

6. Also, later in that section I am advised that for building the 
binutils (which I would need to anyway!) I need to use the same --host 
and --target that are used for configuring GCC, but which one - the 
native cross-compiling GCC or the one that helped build it?


Many thanks in advance for any guidance with regards to this!


MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> 1. Does that mean that I should follow the steps in the previous
> section ("Building a native compiler"), use the 3-stage bootstrapping
> and after this use the resulting compiler to build another GCC cross
> compiler (including the appropriate toolchain) for the 3 architectures
> I am interested in and use this compiler to build my software?

Yes.  Actually most people just skip the step of building the native
compiler, and just use the native compiler they have installed anyhow.
That will normally work fine.

> 2.  I am also assuming that the native GCC compiler which builds the
> native cross-compiler needs to be for the host environment (x86_64) or
> have I got this wrong?

That is correct.

> 3. If that is the case what steps should I use to build the GCC
> compiler for the target image architectures (powerpc and i586/i686)?

Here you are building a cross compiler.  I'm not sure what you are
asking, exactly.  You use --target when you run configure as described
in the documentation.

> 4. Further in that section ("Building a cross compiler") there is
> reference in it which advices that after building the native compiler
> I should configure the cross compiler and then issue 'make' which will
> automatically build the 'host' tools (host as in the 'host'
> architecture?!) necessary to build the compiler as well as the
> target' tools for use of the compiler (again, I assume target as in
> the 'target' architectures I am interested in), then build the
> compiler itself (single-stage only) and "Build runtime libraries using
> the compiler from the previous step". That last bit isn't completely
> clear to me - what previous step?

You build the runtime libraries using the cross-compiler.

> 5. I assume at the end of this process I will end up with my native
> cross compiler which I could then use to build my software. Do I need
> to do anything else?

The words "native cross compiler" don't mean anything to me.  I would
say that you have a cross-compiler which runs on your build system.

> 6. Also, later in that section I am advised that for building the
> binutils (which I would need to anyway!) I need to use the same --host
> and --target that are used for configuring GCC, but which one - the
> native cross-compiling GCC or the one that helped build it?

The cross-compiler.

It may help you to glance at
    http://www.airs.com/ian/configure/configure_5.html#SEC29
to understand the terminology we use.

Ian

Re: building native cross compiler

[Michael Zintakis]

Ian, Many thanks!


A few points which I probably did not explain fully!

It seems that I actually need to build 3 GCC compilers:

1. The 'native' compiler (following the 3-stage bootstrap process as 
described), which is placed 'somewhere' in my source tree and which has 
the only task of building the cross compiler as described in step 2;

2. Cross compiler (single-stage?) which is able to compile for the two 
target environments I am interested in - powerpc and i586/i686. Its main 
task is to compile and build my software for the selected target 
environment as well as building another GCC compiler (described in 3).

3. GCC compiler which is used as part of my built image and its only 
function is to compile programs/packages/binaries in the target 
environment for the target environment (being i586/i686 or powerpc).

If my assumption is correct in the (very simplified) scenario where I 
have x86_64 host environment and the target is, say, powerpc, then GCC 
No 1 needs to have x86_64 arch build, together with all the tools it 
needs. If so, I presume I need to follow the "Building native compiler" 
section (with the 3-stage bootstrap) for building that.

GCC No 2 (single-stage, no bootstrap?) would have to be also x86_64 and 
have libraries and tools built for both arches (cross-compilation) - 
x86_64 and powerpc.

GCC No 3 would have to be powerpc only and have the libraries and tools 
for that arch only.

Is that correct? If so, what process needs to be followed for building 
GCC No 3 - 3-stage bootstrap or a single-stage and bootstrap disabled?

If the above is all correct, this seems to be a long-drawn process. Is 
there any other route of achieving this (bearing in mind that I have to 
preserve the target environment as 'pure' as possible from the host)?

>> 1. Does that mean that I should follow the steps in the previous
>> section ("Building a native compiler"), use the 3-stage bootstrapping
>> and after this use the resulting compiler to build another GCC cross
>> compiler (including the appropriate toolchain) for the 3 architectures
>> I am interested in and use this compiler to build my software?
>>     
>
> Yes.  Actually most people just skip the step of building the native
> compiler, and just use the native compiler they have installed anyhow.
> That will normally work fine.
>   
Unfortunately, I can't do that - it is part of the process I need to 
follow - build a 'pure' GCC compiler which then builds my software 
without relying on the host environment (or at least relying on it as 
little as possible). I know that I could just transfer the GCC 
files/binaries from the host environment onto my source tree and do the 
rest, but that is not an option for me.


>> 3. If that is the case what steps should I use to build the GCC
>> compiler for the target image architectures (powerpc and i586/i686)?
>>     
>
> Here you are building a cross compiler.  I'm not sure what you are
> asking, exactly.  You use --target when you run configure as described
> in the documentation.
>   
I meant (but it seems I haven't explained it properly) GCC No 3 as I 
pointed out above.


>> 5. I assume at the end of this process I will end up with my native
>> cross compiler which I could then use to build my software. Do I need
>> to do anything else?
>>     
>
> The words "native cross compiler" don't mean anything to me.  I would
> say that you have a cross-compiler which runs on your build system.
>
>   
>> 6. Also, later in that section I am advised that for building the
>> binutils (which I would need to anyway!) I need to use the same --host
>> and --target that are used for configuring GCC, but which one - the
>> native cross-compiling GCC or the one that helped build it?
>>     
>
> The cross-compiler.
>
> It may help you to glance at
>     http://www.airs.com/ian/configure/configure_5.html#SEC29
> to understand the terminology we use.
>   
Brilliant guidance that - yes, I see "native" as in for the host 
environment, so I slightly messed these terms up I see.

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> 1. The 'native' compiler (following the 3-stage bootstrap process as
> described), which is placed 'somewhere' in my source tree and which
> has the only task of building the cross compiler as described in step
> 2;

You don't really have to build this one, but it doesn't hurt.  It's not
place somewhere in your source tree.  It's actually built and installed
as usual.

> 2. Cross compiler (single-stage?) which is able to compile for the two
> target environments I am interested in - powerpc and i586/i686. Its
> main task is to compile and build my software for the selected target
> environment as well as building another GCC compiler (described in 3).

Yes.  If I'm following you correctly, which I may not be, then that is
two different cross-compilers, one for each target.

> 3. GCC compiler which is used as part of my built image and its only
> function is to compile programs/packages/binaries in the target
> environment for the target environment (being i586/i686 or powerpc).

If you need a compiler running on your target system, then, yes.

> If my assumption is correct in the (very simplified) scenario where I
> have x86_64 host environment and the target is, say, powerpc, then GCC
> No 1 needs to have x86_64 arch build, together with all the tools it
> needs. If so, I presume I need to follow the "Building native
> compiler" section (with the 3-stage bootstrap) for building that.

Yes.

> GCC No 2 (single-stage, no bootstrap?) would have to be also x86_64
> and have libraries and tools built for both arches (cross-compilation)
> - 
> x86_64 and powerpc.

This is two compilers.  Both have use x86_64 as the host and build
environment, and use the appropriate target as the target environment.

> GCC No 3 would have to be powerpc only and have the libraries and
> tools for that arch only.

Yes, I guess so, though I'm not sure what happened to the other target.

> Is that correct? If so, what process needs to be followed for building
> GCC No 3 - 3-stage bootstrap or a single-stage and bootstrap disabled?

For stage 3 build is x86_64 and host and target are both PPC or whatever.

> If the above is all correct, this seems to be a long-drawn process. Is
> there any other route of achieving this (bearing in mind that I have
> to preserve the target environment as 'pure' as possible from the
> host)?

No, there are no shortcuts.  You may also want to look at
http://crosstool.org , they have some scripts which may or may not help.

Ian

Re: building native cross compiler

[Michael Zintakis]

>> 1. The 'native' compiler (following the 3-stage bootstrap process as
>> described), which is placed 'somewhere' in my source tree and which
>> has the only task of building the cross compiler as described in step
>> 2;
>>     
>
> You don't really have to build this one, but it doesn't hurt.  It's not
> place somewhere in your source tree.  It's actually built and installed
> as usual.
>   
I know, but GCC No 1 would have to be in a location within my source 
tree as it would form part of the entire build process when I start 
building the software, so it makes sense for me to place it somewhere 
sensible, inside of my source tree perhaps, so that it does not get 
confused with the GCC compiler which already exists on my host system.

 From what I understand from your comments so far I have to do this:

1. download GCC source
2. build GCC 1 (native host - i.e. x86_64 - environment) following the 
3-stage guide
3. then use GCC 1 to build GCC 2 and its toolchain (single stage, 
bootstrap disabled) which is for --host=x86_64 and target= either 
powerpc or i586/i686 (depending on the scenario I would need either of 
these architectures, but not both, hence this is one compiler with 
different cross-tool chains depending on the need I have). For this I 
guess I just need to run configure with the appropriate options 
(including --disable-bootstrap) and then make to finish the job.
4. use GCC 2 to build GCC 3 which would form part of the target software 
system allowing compilation of software for the target architecture 
only. I am still unclear as to whether I need to (or should!) use the 
3-stage or single-stage path for this compiler.
5. use GCC 2 to build the rest of the software and create the final 
image which is then deployed to the target machine(s)

GCC1 & GCC 2 are 'temporary' and will be deleted before the final image 
is assembled. Also, the way I see it steps 3, 4 and 5 will be in 
chroot-ed environment as by then I will have a good, tested GCC built.

>> 2. Cross compiler (single-stage?) which is able to compile for the two
>> target environments I am interested in - powerpc and i586/i686. Its
>> main task is to compile and build my software for the selected target
>> environment as well as building another GCC compiler (described in 3).
>>     
>
> Yes.  If I'm following you correctly, which I may not be, then that is
> two different cross-compilers, one for each target.
>   
True, but if I need a compiler able to build on host=x86_64 and 
target=powerpc that's one (cross) compiler isn't it, I don't need to run 
the build process twice for that, do I or have I got this wrong?


>> GCC No 2 (single-stage, no bootstrap?) would have to be also x86_64
>> and have libraries and tools built for both arches (cross-compilation)
>> - 
>> x86_64 and powerpc.
>>     
>
> This is two compilers.  Both have use x86_64 as the host and build
> environment, and use the appropriate target as the target environment.
>   
So, if I want a cross compiler which is x86_64 and cross-compiles for 
ppc is that one or two compilers (and chain tools) I need to build? I am 
confused now!


>> GCC No 3 would have to be powerpc only and have the libraries and
>> tools for that arch only.
>>     
>
> Yes, I guess so, though I'm not sure what happened to the other target.
>   
The two possible scenarios are

x86_64 (GCC1) -> x86_64 (GCC2) -> powerpc (GCC3) or
x86_64 (GCC1) -> x86_64 (GCC2) -> i586/i686 (GCC3)

So, I would need three compilers for the above, the second one (GCC2) 
being the most tricky as it needs to be able to use the power of the 
host system (x86_64) in order to build either powerpc or i586/i686 code 
- all in chroot-ed environment. Well, at least that is my take on it.


>> Is that correct? If so, what process needs to be followed for building
>> GCC No 3 - 3-stage bootstrap or a single-stage and bootstrap disabled?
>>     
>
> For stage 3 build is x86_64 and host and target are both PPC or whatever.
>   
I still don't understand? Should I enable bootstrap (and the 3-stage 
build) when I run configure for GCC3 (which would only need to compile 
code for the target architecture and nothing more, though it needs to 
have the toolchain built for that architecture as well)?


>> If the above is all correct, this seems to be a long-drawn process. Is
>> there any other route of achieving this (bearing in mind that I have
>> to preserve the target environment as 'pure' as possible from the
>> host)?
>>     
>
> No, there are no shortcuts.  You may also want to look at
> http://crosstool.org , they have some scripts which may or may not help.
>   
Another gem, thank you. I will look at it in more detail as my head is 
turning into a mush right now and it is Friday!

MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> 3. then use GCC 1 to build GCC 2 and its toolchain (single stage,
> bootstrap disabled) which is for --host=x86_64 and target= either
> powerpc or i586/i686 (depending on the scenario I would need either of
> these architectures, but not both, hence this is one compiler with
> different cross-tool chains depending on the need I have). For this I
> guess I just need to run configure with the appropriate options
> (including --disable-bootstrap) and then make to finish the job.

Yes.  You can not bootstrap this compiler.  gcc will know that and so
--disable-bootstrap will be the default.

> 4. use GCC 2 to build GCC 3 which would form part of the target
> software system allowing compilation of software for the target
> architecture only. I am still unclear as to whether I need to (or
> should!) use the 3-stage or single-stage path for this compiler.

You must use the single-stage path here because no other path will work.
You can not bootstrap a compiler which does not run on the build system.

> True, but if I need a compiler able to build on host=x86_64 and
> target=powerpc that's one (cross) compiler isn't it, I don't need to
> run the build process twice for that, do I or have I got this wrong?

Yes, that is one cross-compiler.

>>> GCC No 2 (single-stage, no bootstrap?) would have to be also x86_64
>>> and have libraries and tools built for both arches (cross-compilation)
>>> - 
>>> x86_64 and powerpc.
>>>     
>>
>> This is two compilers.  Both have use x86_64 as the host and build
>> environment, and use the appropriate target as the target environment.
>>   
> So, if I want a cross compiler which is x86_64 and cross-compiles for
> ppc is that one or two compilers (and chain tools) I need to build? I
> am confused now!

If I'm following you, you have one "GCC No 2 compiler" for the i586/i686
target, and you have one for the PPC target.  I just wanted to make
clear that you can't have a single compiler which targets all of
i586/i686/PPC.


>>> GCC No 3 would have to be powerpc only and have the libraries and
>>> tools for that arch only.
>>>     
>>
>> Yes, I guess so, though I'm not sure what happened to the other target.
>>   
> The two possible scenarios are
>
> x86_64 (GCC1) -> x86_64 (GCC2) -> powerpc (GCC3) or
> x86_64 (GCC1) -> x86_64 (GCC2) -> i586/i686 (GCC3)
>
> So, I would need three compilers for the above, the second one (GCC2)
> being the most tricky as it needs to be able to use the power of the
> host system (x86_64) in order to build either powerpc or i586/i686
> code - all in chroot-ed environment. Well, at least that is my take on
> it.

You can't really describe these compilers using single names.  I would
say you have

x86_64-native (GCC1) -> x86_64-x-powerpc (GCC2) -> powerpc-native (GCC3)
x86_64-native (GCC1) -> x86_64-x-i586/i686 (GCC2) -> i586/i686-native (GCC3)


>>> Is that correct? If so, what process needs to be followed for building
>>> GCC No 3 - 3-stage bootstrap or a single-stage and bootstrap disabled?
>>>     
>>
>> For stage 3 build is x86_64 and host and target are both PPC or whatever.
>>   
> I still don't understand? Should I enable bootstrap (and the 3-stage
> build) when I run configure for GCC3 (which would only need to compile
> code for the target architecture and nothing more, though it needs to
> have the toolchain built for that architecture as well)?

You can't bootstrap or 3-stage gcc3, because the compiler you are
building can not run on the build system.

Ian

Re: building native cross compiler

[Michael Zintakis]

Thank you Ian - it is much clearer to me now. Further comments below!

>>> This is two compilers.  Both have use x86_64 as the host and build
>>> environment, and use the appropriate target as the target environment.
>>>   
>>>       
>> So, if I want a cross compiler which is x86_64 and cross-compiles for
>> ppc is that one or two compilers (and chain tools) I need to build? I
>> am confused now!
>>     
>
> If I'm following you, you have one "GCC No 2 compiler" for the i586/i686
> target, and you have one for the PPC target.  I just wanted to make
> clear that you can't have a single compiler which targets all of
> i586/i686/PPC.
>   
Correct - your (extended) schematics below describe perfectly what I had 
in mind. I actually have two very different scenarios for which I have 
to prepare. GCC2 will have to compile either i586/i686 or ppc (using the 
- native - x86_64 environment) but not both!

>> The two possible scenarios are
>>
>> x86_64 (GCC1) -> x86_64 (GCC2) -> powerpc (GCC3) or
>> x86_64 (GCC1) -> x86_64 (GCC2) -> i586/i686 (GCC3)
>>
>> So, I would need three compilers for the above, the second one (GCC2)
>> being the most tricky as it needs to be able to use the power of the
>> host system (x86_64) in order to build either powerpc or i586/i686
>> code - all in chroot-ed environment. Well, at least that is my take on
>> it.
>>     
>
> You can't really describe these compilers using single names.  I would
> say you have
>
> x86_64-native (GCC1) -> x86_64-x-powerpc (GCC2) -> powerpc-native (GCC3)
> x86_64-native (GCC1) -> x86_64-x-i586/i686 (GCC2) -> i586/i686-native (GCC3)
>   
Yep, that is *exactly* what I had in mind. The target systems could be 
of two different types and are two, completely different scenarios.

OK, speculating a bit and expanding this further with two more queries - 
if I do not know the target system in advance (i.e. the target for GCC2) 
but this target is specified when the whole build process is initiated, 
would the procedure we discussed on this thread differ?

In other words, if, via a command line parameter or some environment 
variable, the target system is specified when the build up process is 
initiated and is, say, m68, and if I follow the process as discussed on 
this thread, i.e.:- 1) build GCC1 (native-3stage-x86_64), then 2) build 
x86_64-x-m68 (GCC2), then 3) build m68-native (GCC3), 4) use GCC2 to 
compile the rest of the software for native m68 environment and 5) 
prepare the image file for installation. Would that be the right path to 
follow (i.e. same process but for different target system)?

And my second (speculative) query - would it be wise to skip the first 
step in this process (building GCC1) and build GCC2 instead and continue 
the path from there? What would be the implications if such path is to 
be followed (if at all possible that is)?

MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> OK, speculating a bit and expanding this further with two more queries
> - 
> if I do not know the target system in advance (i.e. the target for
> GCC2) but this target is specified when the whole build process is
> initiated, would the procedure we discussed on this thread differ?
>
> In other words, if, via a command line parameter or some environment
> variable, the target system is specified when the build up process is
> initiated and is, say, m68, and if I follow the process as discussed
> on this thread, i.e.:- 1) build GCC1 (native-3stage-x86_64), then 2)
> build x86_64-x-m68 (GCC2), then 3) build m68-native (GCC3), 4) use
> GCC2 to compile the rest of the software for native m68 environment
> and 5) prepare the image file for installation. Would that be the
> right path to follow (i.e. same process but for different target
> system)?

Yes.

> And my second (speculative) query - would it be wise to skip the first
> step in this process (building GCC1) and build GCC2 instead and
> continue the path from there? What would be the implications if such
> path is to be followed (if at all possible that is)?

It would be neither wise nor unwise.  It would save some time, and there
would be a very small risk that the compiler you used instead of GCC1
had a bug.  (That has actually happened to me--a bug in the first
compiler which subtly miscompiled the second compiler and caused
problems in the code it generated--but not for many years.)

Ian

Re: building native cross compiler

[Michael Zintakis]

Ian,


I spent the whole day yesterday trying to build GCC2, though 
unfortunately, I wasn't successful!

>> And my second (speculative) query - would it be wise to skip the first
>> step in this process (building GCC1) and build GCC2 instead and
>> continue the path from there? What would be the implications if such
>> path is to be followed (if at all possible that is)?
>>     
>
> It would be neither wise nor unwise.  It would save some time, and there
> would be a very small risk that the compiler you used instead of GCC1
> had a bug.  (That has actually happened to me--a bug in the first
> compiler which subtly miscompiled the second compiler and caused
> problems in the code it generated--but not for many years.)
>   
I did try this just as a 'test run', but hit a brick wall. Here is what 
I did:

I've downloaded and unpacked gcc 4.5.2 (didn't want to use the new 
version as 4.5.2 was already installed on my host system) in 
~/gcc-test/gcc-4.5.2. I then created ~/gcc-test/gcc-build, jumped to it 
and executed the following:

CC=gcc CFLAGS="-O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4" CXXFLAGS="-O2 -g -pipe -fexceptions 
-fstack-protector --param=ssp-buffer-size=4" XCFLAGS="-O2 -g -pipe -Wall 
-fexceptions -fstack-protector --param=ssp-buffer-size=4" TCFLAGS="-O2 
-g -pipe -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4" 
GCJFLAGS="-O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4" ../gcc-4.5.2/configure 
--target=powerpc-redhat-linux --host=x86_64-redhat-linux 
--build=x86_64-redhat-linux --prefix=/usr --disable-bootstrap 
--enable-shared --enable-threads=posix --enable-checking=release 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --disable-nls 
--enable-languages=c,c++,objc,obj-c++,fortran --disable-libgcj 
--with-ppl --with-cloog --disable-multilib

That went well. I then executed the following:

GCJFLAGS="-O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4" make BOOT_CFLAGS="-O2 -g -pipe -Wall 
-fexceptions -fstack-protector --param=ssp-buffer-size=4"

After a while I've got this error:

Configuring in powerpc-redhat-linux/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-redhat-linux-gnu
checking host system type... powerpc-redhat-linux-gnu
checking for powerpc-redhat-linux-ar... powerpc-redhat-linux-ar
checking for powerpc-redhat-linux-lipo... powerpc-redhat-linux-lipo
checking for powerpc-redhat-linux-nm... /home/mz/gcc-test/gcc-build/./gcc/nm
checking for powerpc-redhat-linux-ranlib... powerpc-redhat-linux-ranlib
checking for powerpc-redhat-linux-strip... powerpc-redhat-linux-strip
checking whether ln -s works... yes
checking for powerpc-redhat-linux-gcc... 
/home/mz/gcc-test/gcc-build/./gcc/xgcc 
-B/home/mz/gcc-test/gcc-build/./gcc/ -B/usr/powerpc-redhat-linux/bin/ 
-B/usr/powerpc-redhat-linux/lib/ -isystem 
/usr/powerpc-redhat-linux/include -isystem 
/usr/powerpc-redhat-linux/sys-include 
checking for suffix of object files... configure: error: in 
`/home/mz/gcc-test/gcc-build/powerpc-redhat-linux/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/home/mz/gcc-test/gcc-build'
make: *** [all] Error 2

Closer examination reveals that build-x86_64-redhat-linux is built, 
though the above error happens when the build up of the ppc branch 
starts. configure.log (which I have a copy of here and can attach, if 
needed) shows this:

configure:2993: /home/mz/gcc-test/gcc-build/./gcc/xgcc 
-B/home/mz/gcc-test/gcc-build/./gcc/ -B/usr/powerpc-redhat-linux/bin/ 
-B/usr/powerpc-redhat-linux/lib/ -isystem 
/usr/powerpc-redhat-linux/include -isystem 
/usr/powerpc-redhat-linux/sys-include    -V >&5
xgcc: '-V' must come at the start of the command line
configure:3004: $? = 1
configure:2993: /home/mz/gcc-test/gcc-build/./gcc/xgcc 
-B/home/mz/gcc-test/gcc-build/./gcc/ -B/usr/powerpc-redhat-linux/bin/ 
-B/usr/powerpc-redhat-linux/lib/ -isystem 
/usr/powerpc-redhat-linux/include -isystem 
/usr/powerpc-redhat-linux/sys-include    -qversion >&5
xgcc: unrecognized option '-qversion'
xgcc: no input files
configure:3004: $? = 1
configure:3020: /home/mz/gcc-test/gcc-build/./gcc/xgcc 
-B/home/mz/gcc-test/gcc-build/./gcc/ -B/usr/powerpc-redhat-linux/bin/ 
-B/usr/powerpc-redhat-linux/lib/ -isystem 
/usr/powerpc-redhat-linux/include -isystem 
/usr/powerpc-redhat-linux/sys-include    -o conftest -O2 -g -pipe -Wall 
-fexceptions -fstack-protector --param=ssp-buffer-size=4   conftest.c  >&5
/home/mz/gcc-test/gcc-build/./gcc/as: line 83: exec: : not found
configure:3023: $? = 2
configure:3211: checking for suffix of object files
configure:3233: /home/mz/gcc-test/gcc-build/./gcc/xgcc 
-B/home/mz/gcc-test/gcc-build/./gcc/ -B/usr/powerpc-redhat-linux/bin/ 
-B/usr/powerpc-redhat-linux/lib/ -isystem 
/usr/powerpc-redhat-linux/include -isystem 
/usr/powerpc-redhat-linux/sys-include    -c -O2 -g -pipe -Wall 
-fexceptions -fstack-protector --param=ssp-buffer-size=4  conftest.c >&5
/home/mz/gcc-test/gcc-build/./gcc/as: line 83: exec: : not found
configure:3237: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3251: error: in 
`/home/mz/gcc-test/gcc-build/powerpc-redhat-linux/libgcc':
configure:3254: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

There is obviously something I am missing, but do not know what.

When I build gcc, but without cross compilation (i.e. multilib x86_64 -> 
i586/i686) and execute this as a configure & make:

CC=gcc CFLAGS="-O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -mtune=core2" CXXFLAGS="-O2 -g -pipe 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=core2" 
XCFLAGS="-O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -mtune=core2" TCFLAGS="-O2 -g -pipe -Wall 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=core2" 
GCJFLAGS="-O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -mtune=core2" ../gcc-4.5.2/configure 
--prefix=/usr --disable-bootstrap --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-gnu-unique-object --disable-nls 
--enable-languages=c,c++,objc,obj-c++,fortran --disable-libgcj 
--with-ppl --with-cloog --with-tune-32=pentium4 --with-tune-64=core2 
--with-cpu-32=pentium4 --with-cpu-64=core2 --with-arch-32=pentium4 
--with-arch-64=core2 --enable-multilib

GCJFLAGS="-O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -mtune=core2" make BOOT_CFLAGS="-O2 -g -pipe 
-Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=core2"

I do not have the above error and everything is OK. I end up with 
"build-x86_64-redhat-linux" as well as "x86_64-redhat-linux" directories 
and they have their 32/ counterparts completely built as well. So, to me 
it is something to do with the cross-compilation I am attempting.

There is another 'weird' problem I am getting - when I execute 'make 
-j3' instead of just 'make' the build stops with the following error:

config.status: linking ../../gcc-4.5.2/gmp/mpn/generic/gmp-mparam.h to 
gmp-mparam.h
config.status: executing libtool commands
make[1]: Leaving directory `/home/mz/gcc-test/gcc-build'
make: *** [all] Error 2

When I restart make again with the same command after that error (i.e. 
execute the same 'make -j3' from that point) the build continues without 
problems! Weird!

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> checking for
> powerpc-redhat-linux-gcc... /home/mz/gcc-test/gcc-build/./gcc/xgcc
> -B/home/mz/gcc-test/gcc-build/./gcc/ -B/usr/powerpc-redhat-linux/bin/
> -B/usr/powerpc-redhat-linux/lib/ -isystem
> /usr/powerpc-redhat-linux/include -isystem
> /usr/powerpc-redhat-linux/sys-include checking for suffix of object
> files... configure: error: in
> /home/mz/gcc-test/gcc-build/powerpc-redhat-linux/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.

http://gcc.gnu.org/wiki/FAQ#Configuration_fails_with_.27.27configure:_error:_cannot_compute_suffix_of_object_files:_cannot_compile.27.27._What_is_the_problem.3F


> /home/mz/gcc-test/gcc-build/./gcc/as: line 83: exec: : not found

You must build and install a cross-binutils with the same --target and
--prefix option before you configure and build gcc.

Ian

Re: building native cross compiler

[Michael Zintakis]

Ian, thanks for your response!

>> /home/mz/gcc-test/gcc-build/./gcc/as: line 83: exec: : not found
>>     
>
> You must build and install a cross-binutils with the same --target and
> --prefix option before you configure and build gcc.
>   
I am a bit confused, I have to admit! It is true that I did use my own 
GCC compiler (on the host machine) to get the GCC2 built (skipping step 
one of the plan), so from what I gather from your response my host 
compiler needs to have all the binutils for the target platform 
installed as well, is that correct?

Also, if I build GCC1 should I specify the different target platform I 
am interested in (ppc in my example) so that it could build its own 
binutils for that platform? Would that work?

Following from the "Building a cross compiler" section it tells me that 
by issuing "make" it "Builds target tools for use by the compiler such 
as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they have 
been individually linked or moved into the top level GCC source tree 
before configuring." - what does that mean exactly I am unclear?

The strange thing is that my host machine GCC already has i686 and 
x86_64 binutils installed (though as a "ready-made" package - I haven't 
compiled this from source so can't vouch for the correctness of these 
packages) and when I attempted to build GCC2 with 
"--target=i686-redhat-linux" it also failed! I know the host GCC on that 
machine works as I also do compilation for boh x86_64 and i686 arches 
successfully. Maybe I am missing something else.

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

>>> /home/mz/gcc-test/gcc-build/./gcc/as: line 83: exec: : not found
>>>     
>>
>> You must build and install a cross-binutils with the same --target and
>> --prefix option before you configure and build gcc.
>>   
> I am a bit confused, I have to admit! It is true that I did use my own
> GCC compiler (on the host machine) to get the GCC2 built (skipping
> step one of the plan), so from what I gather from your response my
> host compiler needs to have all the binutils for the target platform
> installed as well, is that correct?

In order to build a cross-compiler (your GCC2) you must first build a
cross-binutils.

> Also, if I build GCC1 should I specify the different target platform I
> am interested in (ppc in my example) so that it could build its own
> binutils for that platform? Would that work?

No.

> Following from the "Building a cross compiler" section it tells me
> that by issuing "make" it "Builds target tools for use by the compiler
> such as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they
> have been individually linked or moved into the top level GCC source
> tree before configuring." - what does that mean exactly I am unclear?

This refers to a procedure which I do not recommend, as it will lead you
into even deeper complexities.  It is a way that experienced GCC
developers speed up the build.  You can copy the source directories
bfd/gas/ld/binutils from the binutils into your gcc directory, and then
build both the binutils and gcc at once, rather than doing separate
builds.  However, this only works if the shared directories such as
include and libiberty are exactly matched, which means in practice that
you need to be working with development sources rather than releases, or
you need to understand the code in sufficient detail to address the
conflicts which occur.

> The strange thing is that my host machine GCC already has i686 and
> x86_64 binutils installed (though as a "ready-made" package - I
> haven't compiled this from source so can't vouch for the correctness
> of these packages) and when I attempted to build GCC2 with
> "--target=i686-redhat-linux" it also failed! I know the host GCC on
> that machine works as I also do compilation for boh x86_64 and i686
> arches successfully. Maybe I am missing something else.

Read the FAQ entry I mentioned.

Ian

Re: building native cross compiler

[Michael Zintakis]

> In order to build a cross-compiler (your GCC2) you must first build a
> cross-binutils.
>   
Where do I get these as I did check the gcc web site, but could not find 
them anywhere (apologies for this daft request!)

>> Following from the "Building a cross compiler" section it tells me
>> that by issuing "make" it "Builds target tools for use by the compiler
>> such as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they
>> have been individually linked or moved into the top level GCC source
>> tree before configuring." - what does that mean exactly I am unclear?
>>     
>
> This refers to a procedure which I do not recommend, as it will lead you
> into even deeper complexities.  It is a way that experienced GCC
> developers speed up the build.  You can copy the source directories
> bfd/gas/ld/binutils from the binutils into your gcc directory, and then
> build both the binutils and gcc at once, rather than doing separate
> builds.
Ah! This is exactly what I did with mpc and gmp packages - copied them 
into the main gcc source directory (gcc-test/gcc-4.5.2) as this is what 
was suggested in the building requirements section. Is that wrong?

>   However, this only works if the shared directories such as
> include and libiberty are exactly matched, which means in practice that
> you need to be working with development sources rather than releases, or
> you need to understand the code in sufficient detail to address the
> conflicts which occur.
>   
OK, if I get binutils and gcc sources I presume if I run diff on both 
directories for all 3 packages and they match then I am OK and I could 
then dump all sources in the main gcc source directory and issue make, 
is that right?

I also presume that my 'bubble' error I described in one of my previous 
posts has something to do with the fact that I copied gmp and mpc 
sources to the main gcc source directory prior to starting the build or 
is that not the case (I am guessing here as I do not know what is 
causing it really)?

>> The strange thing is that my host machine GCC already has i686 and
>> x86_64 binutils installed (though as a "ready-made" package - I
>> haven't compiled this from source so can't vouch for the correctness
>> of these packages) and when I attempted to build GCC2 with
>> "--target=i686-redhat-linux" it also failed! I know the host GCC on
>> that machine works as I also do compilation for boh x86_64 and i686
>> arches successfully. Maybe I am missing something else.
>>     
>
> Read the FAQ entry I mentioned.
>   
I did and it refers to the three libraries I have (although as sources 
in the GCC source directory) or have I missed something?

MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

>> In order to build a cross-compiler (your GCC2) you must first build a
>> cross-binutils.
>>   
> Where do I get these as I did check the gcc web site, but could not
> find them anywhere (apologies for this daft request!)

http://sourceware.org/binutils/

>>> Following from the "Building a cross compiler" section it tells me
>>> that by issuing "make" it "Builds target tools for use by the compiler
>>> such as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they
>>> have been individually linked or moved into the top level GCC source
>>> tree before configuring." - what does that mean exactly I am unclear?
>>>     
>>
>> This refers to a procedure which I do not recommend, as it will lead you
>> into even deeper complexities.  It is a way that experienced GCC
>> developers speed up the build.  You can copy the source directories
>> bfd/gas/ld/binutils from the binutils into your gcc directory, and then
>> build both the binutils and gcc at once, rather than doing separate
>> builds.
> Ah! This is exactly what I did with mpc and gmp packages - copied them
> into the main gcc source directory (gcc-test/gcc-4.5.2) as this is
> what was suggested in the building requirements section. Is that
> wrong?

That works fine with mpc and gmp, as they are independent of the gcc
source directories.  It leads to more trouble with the binutils, as the
binutils and gcc share some source directories.

>>   However, this only works if the shared directories such as
>> include and libiberty are exactly matched, which means in practice that
>> you need to be working with development sources rather than releases, or
>> you need to understand the code in sufficient detail to address the
>> conflicts which occur.
>>   
> OK, if I get binutils and gcc sources I presume if I run diff on both
> directories for all 3 packages and they match then I am OK and I could
> then dump all sources in the main gcc source directory and issue make,
> is that right?

In principle, yes.

> I also presume that my 'bubble' error I described in one of my
> previous posts has something to do with the fact that I copied gmp and
> mpc sources to the main gcc source directory prior to starting the
> build or is that not the case (I am guessing here as I do not know
> what is causing it really)?

Putting gmp and mpc in your gcc source directory should work fine, that
is most likely not the issue here.

>>> The strange thing is that my host machine GCC already has i686 and
>>> x86_64 binutils installed (though as a "ready-made" package - I
>>> haven't compiled this from source so can't vouch for the correctness
>>> of these packages) and when I attempted to build GCC2 with
>>> "--target=i686-redhat-linux" it also failed! I know the host GCC on
>>> that machine works as I also do compilation for boh x86_64 and i686
>>> arches successfully. Maybe I am missing something else.
>>>     
>>
>> Read the FAQ entry I mentioned.
>>   
> I did and it refers to the three libraries I have (although as sources
> in the GCC source directory) or have I missed something?

What do you see in the config.log file?

Ian

Re: building native cross compiler

[Michael Zintakis]

>> Where do I get these as I did check the gcc web site, but could not
>> find them anywhere (apologies for this daft request!)
>>     
>
> http://sourceware.org/binutils/
>   
Thanks! Downloaded along with mpfr, ppl-0.11.2 (configure said that my 
existing version is "buggy" :-) ) and cloog-ppl-0.15.9.

If I dump mpfr, ppl and cloog-ppl in the main gcc source directory (and 
name those directories like that - "mpfr", "ppl" and "cloog-ppl") would 
that be enough for the GCC build or do I have to compile/install them 
separately?

>>>   However, this only works if the shared directories such as
>>> include and libiberty are exactly matched, which means in practice that
>>> you need to be working with development sources rather than releases, or
>>> you need to understand the code in sufficient detail to address the
>>> conflicts which occur.
>>>   
>>>       
>> OK, if I get binutils and gcc sources I presume if I run diff on both
>> directories for all 3 packages and they match then I am OK and I could
>> then dump all sources in the main gcc source directory and issue make,
>> is that right?
>>     
>
> In principle, yes.
>   
The copy of binutils is for version 2.21, my gcc version is 4.5.2, so I 
will check their corresponding include/ and libiberty directories with 
the ones of the gcc version I have. Quick look tells me that (at least) 
the include directory in binutils is very different (it has a lot of 
subdirectories) from the one in gcc-4.5.2/include.

If I copy binutils sources to the main gcc source directory what would 
be the sign that they are incompatible - the same error as I was getting 
before (line 83 etc)?

>>>> The strange thing is that my host machine GCC already has i686 and
>>>> x86_64 binutils installed (though as a "ready-made" package - I
>>>> haven't compiled this from source so can't vouch for the correctness
>>>> of these packages) and when I attempted to build GCC2 with
>>>> "--target=i686-redhat-linux" it also failed! I know the host GCC on
>>>> that machine works as I also do compilation for boh x86_64 and i686
>>>> arches successfully. Maybe I am missing something else.
>>>>     
>>>>         
>>> Read the FAQ entry I mentioned.
>>>   
>>>       
>> I did and it refers to the three libraries I have (although as sources
>> in the GCC source directory) or have I missed something?
>>     
>
> What do you see in the config.log file?
>   
The same one I was getting with the ppc target - line 83 etc etc.

MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

>>> Where do I get these as I did check the gcc web site, but could not
>>> find them anywhere (apologies for this daft request!)
>>>     
>>
>> http://sourceware.org/binutils/
>>   
> Thanks! Downloaded along with mpfr, ppl-0.11.2 (configure said that my
> existing version is "buggy" :-) ) and cloog-ppl-0.15.9.
>
> If I dump mpfr, ppl and cloog-ppl in the main gcc source directory
> (and name those directories like that - "mpfr", "ppl" and "cloog-ppl")
> would that be enough for the GCC build or do I have to compile/install
> them separately?

As far as I know that is fine.  I haven't done much with PPL myself.


> If I copy binutils sources to the main gcc source directory what would
> be the sign that they are incompatible - the same error as I was
> getting before (line 83 etc)?

No, the errors are much more subtle.  I really can't encourage this
unless you are prepared to investigate and solve problems yourself.


>>>>> The strange thing is that my host machine GCC already has i686 and
>>>>> x86_64 binutils installed (though as a "ready-made" package - I
>>>>> haven't compiled this from source so can't vouch for the correctness
>>>>> of these packages) and when I attempted to build GCC2 with
>>>>> "--target=i686-redhat-linux" it also failed! I know the host GCC on
>>>>> that machine works as I also do compilation for boh x86_64 and i686
>>>>> arches successfully. Maybe I am missing something else.
>>>>>             
>>>> Read the FAQ entry I mentioned.
>>>>         
>>> I did and it refers to the three libraries I have (although as sources
>>> in the GCC source directory) or have I missed something?
>>>     
>>
>> What do you see in the config.log file?
>>   
> The same one I was getting with the ppc target - line 83 etc etc.

I'm sorry, I don't recall what that was.  If it's a missing 'as' file
then the simple answer is still going to be to install the binutils.  At
one time gcc would fall back to running 'as' even for a cross-compiler,
but perhaps that is no longer the case.

Ian

Re: building native cross compiler

[Michael Zintakis]

>> Thanks! Downloaded along with mpfr, ppl-0.11.2 (configure said that my
>> existing version is "buggy" :-) ) and cloog-ppl-0.15.9.
>>
>> If I dump mpfr, ppl and cloog-ppl in the main gcc source directory
>> (and name those directories like that - "mpfr", "ppl" and "cloog-ppl")
>> would that be enough for the GCC build or do I have to compile/install
>> them separately?
>>     
>
> As far as I know that is fine.  I haven't done much with PPL myself.
>   
It says on the gcc pre-requisite pages that these packages are good for 
doing the optimisations, so I thought there is no harm to include these 
in the build as well. I'll try them when I do my 2nd pass.

Currently I took the plunge and dumped the whole binutils directory in 
the main gcc source...will see how it goes after I selected 
--host=x86_64 and --target=powerpc, fingers crossed!


>> If I copy binutils sources to the main gcc source directory what would
>> be the sign that they are incompatible - the same error as I was
>> getting before (line 83 etc)?
>>     
>
> No, the errors are much more subtle.  I really can't encourage this
> unless you are prepared to investigate and solve problems yourself.
>   
I hope there is no conflict, but if there is and I get an error I will 
build binutils separately.

>>> What do you see in the config.log file?
>>>   
>>>       
>> The same one I was getting with the ppc target - line 83 etc etc.
>>     
>
> I'm sorry, I don't recall what that was.  If it's a missing 'as' file
> then the simple answer is still going to be to install the binutils.  At
> one time gcc would fall back to running 'as' even for a cross-compiler,
> but perhaps that is no longer the case.
>   
I am a bloody moron! I forgot to rename the mpfr directory when dumping 
the source and this was the reason for the build to stop midway through 
- it is OK now, I just compiled GCC with the multilib option on without 
any glitches. We're getting there!!!

MZ

Re: building native cross compiler

[Michael Zintakis]

> Currently I took the plunge and dumped the whole binutils directory in 
> the main gcc source...will see how it goes after I selected 
> --host=x86_64 and --target=powerpc, fingers crossed!
Nope! :-(

Same error, though things are a bit different with the binutils package:

Configuring in powerpc-redhat-linux/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-redhat-linux-gnu
checking host system type... powerpc-redhat-linux-gnu
checking for powerpc-redhat-linux-ar... 
/home/mz/gcc-test/gcc-build/./binutils/ar
checking for powerpc-redhat-linux-lipo... powerpc-redhat-linux-lipo
checking for powerpc-redhat-linux-nm... /home/mz/gcc-test/gcc-build/./gcc/nm
checking for powerpc-redhat-linux-ranlib... 
/home/mz/gcc-test/gcc-build/./binutils/ranlib
checking for powerpc-redhat-linux-strip... 
/home/mz/gcc-test/gcc-build/./binutils/strip
checking whether ln -s works... yes
checking for powerpc-redhat-linux-gcc... 
/home/mz/gcc-test/gcc-build/./gcc/xgcc 
-B/home/mz/gcc-test/gcc-build/./gcc/ -B/usr/powerpc-redhat-linux/bin/ 
-B/usr/powerpc-redhat-linux/lib/ -isystem 
/usr/powerpc-redhat-linux/include -isystem 
/usr/powerpc-redhat-linux/sys-include  
checking for suffix of object files... configure: error: in 
`/home/mz/gcc-test/gcc-build/powerpc-redhat-linux/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/home/mz/gcc-test/gcc-build'
make: *** [all] Error 2


I see ar, ranlib and strip have been picked up from the binutils 
directory though the error is exactly the same as before - line 83 exec 
not found (what exec id doesn't say). So, I presume I have to build 
binutils first and place the executables in prefix/target/bin, right?


MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> I see ar, ranlib and strip have been picked up from the binutils
> directory though the error is exactly the same as before - line 83
> exec not found (what exec id doesn't say). So, I presume I have to
> build binutils first and place the executables in prefix/target/bin,
> right?

Yes, which should happen automatically if you configure the binutils
with the identical --target and --prefix options that you use when you
configure gcc.  When you run "make; make install" the binutils should be
installed where gcc expects to find them.

Ian

Re: building native cross compiler

[Michael Zintakis]

>> I see ar, ranlib and strip have been picked up from the binutils
>> directory though the error is exactly the same as before - line 83
>> exec not found (what exec id doesn't say). So, I presume I have to
>> build binutils first and place the executables in prefix/target/bin,
>> right?
>>     
>
> Yes, which should happen automatically if you configure the binutils
> with the identical --target and --prefix options that you use when you
> configure gcc.  When you run "make; make install" the binutils should be
> installed where gcc expects to find them.
>   
I have just noticed one other intriguing thing - this is the end of the 
output from configure:

checking where to find the target ar... just compiled
checking where to find the target as... pre-installed
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... just compiled
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... just compiled
checking where to find the target ld... pre-installed
checking where to find the target lipo... pre-installed
checking where to find the target nm... just compiled
checking where to find the target objdump... just compiled
checking where to find the target ranlib... just compiled
checking where to find the target strip... just compiled
checking where to find the target windres... just compiled
checking where to find the target windmc... just compiled


I presume 'just compiled' means that gcc will compile these and 
'pre-installed' means the executables on the host system will be used.

If that is the case then 'as' (the one executable which is the reason 
for the line 83 error I am getting) is listed as 'pre-installed' and 
that should be 'just-complied' because the 'as' executable on my system 
can't handle the ppc target ('as' from the compiled binutils should be 
used instead, right?). I am not sure whether the same should go for ld, 
lipo and gcj (although gcj - gc java - is disabled so it won't matter I 
think), what do you think Ian.

Re: building native cross compiler

[Michael Zintakis]

>> I see ar, ranlib and strip have been picked up from the binutils
>> directory though the error is exactly the same as before - line 83
>> exec not found (what exec id doesn't say). So, I presume I have to
>> build binutils first and place the executables in prefix/target/bin,
>> right?
>>     
>
> Yes, which should happen automatically if you configure the binutils
> with the identical --target and --prefix options that you use when you
> configure gcc.  When you run "make; make install" the binutils should be
> installed where gcc expects to find them.
>   
OK, I've just successfully compiled and installed binutils for x86_64 -> 
ppc with prefix ~/gcc-test/gcc-install. I then ran a (modified) 
configure for gcc with the same prefix. Configure picked up the right 
binaries this time, I think:

checking for ar... /home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/ar
checking for as... /home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/as
checking for dlltool... no
checking for powerpc-redhat-linux-dlltool... no
checking for ld... /home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/ld
checking for lipo... no
checking for powerpc-redhat-linux-lipo... no
checking for nm... /home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/nm
checking for objdump... 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/objdump
checking for ranlib... 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/ranlib
checking for strip... 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/strip
checking for windres... no
checking for powerpc-redhat-linux-windres... no
checking for windmc... no
checking for powerpc-redhat-linux-windmc... no
checking where to find the target ar... pre-installed in 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin
checking where to find the target as... pre-installed in 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... pre-installed
checking where to find the target gcc... just compiled
checking where to find the target gcj... pre-installed
checking where to find the target gfortran... just compiled
checking where to find the target ld... pre-installed in 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin
checking where to find the target lipo... pre-installed
checking where to find the target nm... pre-installed in 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin
checking where to find the target objdump... pre-installed in 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin
checking where to find the target ranlib... pre-installed in 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin
checking where to find the target strip... pre-installed in 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin
checking where to find the target windres... pre-installed
checking where to find the target windmc... pre-installed

I see dlltool, lipo, windres, windmc and gcj as 'pre-installed', i.e. 
using my host machine versions (if indeed that is the case).

When I ran make next I went much further than before, but, ultimately 
failed again with the following error:

/home/mz/gcc-test/gcc-build/./gcc/xgcc 
-B/home/mz/gcc-test/gcc-build/./gcc/ 
-B/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/bin/ 
-B/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/lib/ -isystem 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/include -isystem 
/home/mz/gcc-test/gcc-install/powerpc-redhat-linux/sys-include    -O2 -g 
-pipe -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4 
-O2  -O2 -g -pipe -Wall -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall 
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -mlong-double-128 
-I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. 
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include 
-I../../../gcc/libgcc/../libdecnumber/dpd 
-I../../../gcc/libgcc/../libdecnumber -DHAVE_CC_TLS  -o decContext.o -MT 
decContext.o -MD -MP -MF decContext.dep -c 
../../../gcc/libgcc/../libdecnumber/decContext.c
../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal error: 
string.h: No such file or directory
compilation terminated.
make[2]: *** [decContext.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory 
`/home/mz/gcc-test/gcc-build/powerpc-redhat-linux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/mz/gcc-test/gcc-build'
make: *** [all] Error 2

By quickly looking at decContext.c it references <string.h> on line 33. 
Quick search tells me that there is only one file named string.h in the 
source tree and it is located at 
./gcc-test/gcc/libstdc++-v3/include/c_compatibility/string.h. I am not 
sure whether that is the right place for it or whether that is indeed 
the right version of the file. Any ideas how to get pass this?

One other thing I discovered - I could place gmp, mpc, mpfr and ppl (but 
*not* cloog) sources in the binutils source tree and "make" picks them 
up, though I later on had to do the same with gcc, otherwise the build 
fails (I guess I was hoping that once built by binutils these packages 
will be installed by binutils and later used by gcc - I was wrong).

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> ../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal error: string.h: No such file or directory

The question now is whether you have a C library for your target system.

Ian

Re: building native cross compiler

[Michael Zintakis]

>> ../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal error: string.h: No such file or directory
>>     
>
> The question now is whether you have a C library for your target system.
>   
Please elaborate Ian - what do you mean?

Re: building native cross compiler

[Michael Zintakis]

>>> ../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal error: 
>>> string.h: No such file or directory
>>>     
>>
>> The question now is whether you have a C library for your target system.
>>   
> Please elaborate Ian - what do you mean?
Scratch that, do you mean glibc? If so, I just looked at 
http://ftp.gnu.org/gnu/glibc/ and there are various glibc-* files there. 
I take it I only need glibc-2.13 (as this is the latest version 
released) and ignore the rest (like glibc-crypt, glibc-libidn, 
glibc-linuxthreads, glibc-localedata, glibc-ports or do I need these as 
well?). Do I have to compile this separately or do I just drop it in the 
main gcc source tree?

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

>>> ../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal error: string.h: No such file or directory
>>>     
>>
>> The question now is whether you have a C library for your target system.
>>   
> Please elaborate Ian - what do you mean?

A C library contains things like <stdio.h>, <string.h>, and the
associated functions like fopen, strcpy, etc.  GCC does not provide a C
library.

You've described your target in terms of processor, but not in terms of
operating system.  Some operating systems have a C library.  Some do
not.  Either way, you're going to need one if you want to write C code.
And you're going to cross-compiler your C library in order to
cross-build programs that run on your target system.

Ian

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

>>>> ../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal
>>>> error: string.h: No such file or directory
>>>>     
>>>
>>> The question now is whether you have a C library for your target system.
>>>   
>> Please elaborate Ian - what do you mean?
> Scratch that, do you mean glibc? If so, I just looked at
> http://ftp.gnu.org/gnu/glibc/ and there are various glibc-* files
> there. I take it I only need glibc-2.13 (as this is the latest version
> released) and ignore the rest (like glibc-crypt, glibc-libidn,
> glibc-linuxthreads, glibc-localedata, glibc-ports or do I need these
> as well?). Do I have to compile this separately or do I just drop it
> in the main gcc source tree?

If you are going to build glibc, which is appropriate if you are
targeting a GNU/Linux system, then I strongly recommend that you use the
scripts at http://crosstool.org/ .  Cross-building glibc is more complex
than cross-building gcc.

Ian

Re: building native cross compiler

[Michael Zintakis]

>>>> ../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal error: string.h: No such file or directory
>>>>     
>>>>         
>>> The question now is whether you have a C library for your target system.
>>>   
>>>       
>> Please elaborate Ian - what do you mean?
>>     
>
> A C library contains things like <stdio.h>, <string.h>, and the
> associated functions like fopen, strcpy, etc.  GCC does not provide a C
> library.
>
> You've described your target in terms of processor, but not in terms of
> operating system.  Some operating systems have a C library.  Some do
> not.  Either way, you're going to need one if you want to write C code.
> And you're going to cross-compiler your C library in order to
> cross-build programs that run on your target system.
>   
Yes, apologies - I hit the send button a little bit too fast before 
thinking it through. My target system is Linux, though it would come 
with two known variants - LFS (Linux from scratch) and Fedora. It will 
be used with both architectures (i586/i686 and ppc).

 From what I gather by reading the INSTALL (and FAQ) files from the 
source archives I would need to build glibc separately, after I built 
binutils, use the same prefix and probably specify the "--with-headers" 
option as well. I take it glibc won't be relying on the GCC 
cross-compiler otherwise we have a chicken-and-egg scenario on our hands?

There are a couple of paragraphs from the same file which I am not sure of:

"You must first build the library (`make'), optionally check it
(`make check'), switch the include directories and then install (`make
install').  The steps must be done in this order.  Not moving the
directory before install will result in an unusable mixture of header
files from both libraries, but configuring, building, and checking the
library requires the ability to compile and run programs against the old
library."

Do I need to do this as i am building with a specific prefix and, I take 
it, my original system won't be affected (I won't be chrooted yet). If I 
do need to follow that what does the 'switch the include directories' mean?

"You may also need to reconfigure GCC to work with the new library.
The easiest way to do that is to figure out the compiler switches to
make it work again (`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should
work on GNU/Linux systems) and use them to recompile gcc."

Do I need to do that too? If so, should I specify the --dynamic-linker 
path to "prefix/target/lib/ld-linux.so.2"?

"You can install glibc somewhere other than where you configured it
to go by setting the `install_root' variable on the command line for
`make install'.  The value of this variable is prepended to all the
paths for installation.  This is useful when setting up a chroot
environment or preparing a binary distribution.  The directory should be
specified with an absolute file name."

Same here - I assumed when specifying the prefix that will be enough 
(without specifying 'install_root') or is it?

Finally, in the same file there is mention that I would also need the 
header files for the Linux arch (presumably the target arch as I already 
have the host ones installed) - is that really a requirement?

Also, I take it it is not possible to build glibc at the same time I 
build GCC (i.e. by dropping the source tree into the GCC main tree), right?

MZ

Re: building native cross compiler

[Michael Zintakis]

> If you are going to build glibc, which is appropriate if you are
> targeting a GNU/Linux system, then I strongly recommend that you use the
> scripts at http://crosstool.org/ .
Ah, right - I downloaded them but realised that the version of the 
cross-compiling tools has not been updated for more than 5 years and 
assumed that it is outdated and left it. Will look at them again then, 
thanks for the advice!

>   Cross-building glibc is more complex
> than cross-building gcc.
>   
And here it is me thinking that it was a doddle before I started :-)

MZ

Re: building native cross compiler

[Kai Ruottu]

14.3.2011 18:31, Michael Zintakis kirjoitti:
>
>>>>> ../../../gcc/libgcc/../libdecnumber/decContext.c:33:43: fatal
>>>>> error: string.h: No such file or directory
>>>> The question now is whether you have a C library for your target
>>>> system.
>>
>> You've described your target in terms of processor, but not in terms of
>> operating system. Some operating systems have a C library. Some do
>> not.
 >
> My target system is Linux, though it would come
> with two known variants - LFS (Linux from scratch) and Fedora. It will
> be used with both architectures (i586/i686 and ppc).

Targeting to known and existing targets like Fedora/i686 and Fedora/PPC
is easy as a pie : Just build binutils, copy the existing target glibc
and finally the GCC. But a "from scratch" target may involve really
weird attitudes which will disable using any "bootstrap" components
like a temporary replacement glibc for the still unexisting "totally
self built" target system, the "LFS". The famous "crosstool" method
takes it "heretic" to use anything from anything existing in any phase,
only the bare pristine sources are allowed! This is equal to making a
hammer without using any existing hammer during the production, only
a piece of iron and stones tied to sticks... When producing a complete
GCC with libgcc, libstdc++ etc. requires the target C library during
the GCC build for a system target, not being allowed to use some
suitable existing one, makes things really complicated :(

So cross GCCs for targets like 'i686-fedora14-linux' and
'powerpc-fedora3-linux' are easy as a pie to build but for targets like
'i686-mydistro-linux' and 'powerpc-mydistro-linux' it would be very
hard to produce tools if one is not allowed (politically) to bootstrap
the first GCCs with the Fedora or something glibcs, thinking them
being only "some" glibcs for the generic 'i686-linux-gnu' and
'powerpc-linux-gnu' target cases... Just as well as the equivalent
prebuilt Debian, Ubuntu, SuSE etc glibcs for i686 and PPC... Producing
glibcs with fully working GCCs is the default, the default for a glibc
build is a native build and nobody says that one is not allowed to have
any stuff in '/lib', '/usr/include' and '/usr/lib' then (some existing
old glibc)...

>  From what I gather by reading the INSTALL (and FAQ) files from the
> source archives I would need to build glibc separately, after I built
> binutils, use the same prefix and probably specify the "--with-headers"
> option as well. I take it glibc won't be relying on the GCC
> cross-compiler otherwise we have a chicken-and-egg scenario on our hands?

Maybe the "proprietary" targets like Sparc/Solaris, AIX, SVR4 etc. and
"custom" ones like FreeBSD, NetBSD, OpenBSD, Cygwin, MinGW etc. could
serve as models for normal targets for cross binutils, GCC and GDB. They
already have their own original fully tested headers and library
binaries without sources or with sources but no sanity to reinvent the
wheel by trying to produce something identical for the existing...

If one doesn't make Linux distros, one never needs to produce the target
C libraries for Linux targets because the already existing Linux distros
already have their target C libraries built and fully tested !

> There are a couple of paragraphs from the same file which I am not sure of:
>
> "You must first build the library (`make'), optionally check it
> (`make check'), switch the include directories and then install (`make
> install'). The steps must be done in this order. Not moving the
> directory before install will result in an unusable mixture of header
> files from both libraries, but configuring, building, and checking the
> library requires the ability to compile and run programs against the old
> library."
>
> Do I need to do this as i am building with a specific prefix and, I take
> it, my original system won't be affected (I won't be chrooted yet). If I
> do need to follow that what does the 'switch the include directories' mean?
>
> "You may also need to reconfigure GCC to work with the new library.
> The easiest way to do that is to figure out the compiler switches to
> make it work again (`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should
> work on GNU/Linux systems) and use them to recompile gcc."
>
> Do I need to do that too? If so, should I specify the --dynamic-linker
> path to "prefix/target/lib/ld-linux.so.2"?

All this stuff has nothing to do with producing a normal cross GCC for a
normal already existing target like a Linux distro, Fedora, SuSE, Ubuntu
etc. !

Re: building native cross compiler

[Michael Zintakis]

>> My target system is Linux, though it would come
>> with two known variants - LFS (Linux from scratch) and Fedora. It will
>> be used with both architectures (i586/i686 and ppc).
>
> Targeting to known and existing targets like Fedora/i686 and Fedora/PPC
> is easy as a pie : Just build binutils, copy the existing target glibc
> and finally the GCC.
So, if I drop the glibc source in the gcc source tree I should be OK 
with cross-compiler building is that what you are suggesting?

> But a "from scratch" target may involve really
> weird attitudes which will disable using any "bootstrap" components
> like a temporary replacement glibc for the still unexisting "totally
> self built" target system, the "LFS". The famous "crosstool" method
> takes it "heretic" to use anything from anything existing in any phase,
> only the bare pristine sources are allowed! This is equal to making a
> hammer without using any existing hammer during the production, only
> a piece of iron and stones tied to sticks... When producing a complete
> GCC with libgcc, libstdc++ etc. requires the target C library during
> the GCC build for a system target, not being allowed to use some
> suitable existing one, makes things really complicated :(
I am not sure what you mean by the above!

> So cross GCCs for targets like 'i686-fedora14-linux' and
> 'powerpc-fedora3-linux' are easy as a pie to build but for targets like
> 'i686-mydistro-linux' and 'powerpc-mydistro-linux' it would be very
> hard to produce tools if one is not allowed (politically) to bootstrap
> the first GCCs with the Fedora or something glibcs, thinking them
> being only "some" glibcs for the generic 'i686-linux-gnu' and
> 'powerpc-linux-gnu' target cases...
I will bootstrap the first compiler - GCC1, which is then going to be 
used to build GCC2 (the cross-compiler) and GCC2 will then have to build 
the entire target system (including another copy of gcc - GCC3, which 
will be solely used to build software on the target system only). I have 
no alternative with this, unfortunately!

> Just as well as the equivalent
> prebuilt Debian, Ubuntu, SuSE etc glibcs for i686 and PPC... Producing
> glibcs with fully working GCCs is the default, the default for a glibc
> build is a native build and nobody says that one is not allowed to have
> any stuff in '/lib', '/usr/include' and '/usr/lib' then (some existing
> old glibc)...
I assume you understand that my host system will *always* be x86_64 and 
will *always* be Fedora - just in case I wasn't clear with this. So, can 
I build glibc for system other than the host one or is this rapidly 
becoming chicken-and-egg scenario?


>>  From what I gather by reading the INSTALL (and FAQ) files from the
>> source archives I would need to build glibc separately, after I built
>> binutils, use the same prefix and probably specify the "--with-headers"
>> option as well. I take it glibc won't be relying on the GCC
>> cross-compiler otherwise we have a chicken-and-egg scenario on our 
>> hands?
>
> Maybe the "proprietary" targets like Sparc/Solaris, AIX, SVR4 etc. and
> "custom" ones like FreeBSD, NetBSD, OpenBSD, Cygwin, MinGW etc. could
> serve as models for normal targets for cross binutils, GCC and GDB. They
> already have their own original fully tested headers and library
> binaries without sources or with sources but no sanity to reinvent the
> wheel by trying to produce something identical for the existing...
LFS does have sources (and I presume headers too), but in order to build 
it I need GCC2 fully functioning, which is what I am trying to do as 
both host and target systems are different.

>> There are a couple of paragraphs from the same file which I am not 
>> sure of:
>>
>> "You must first build the library (`make'), optionally check it
>> (`make check'), switch the include directories and then install (`make
>> install'). The steps must be done in this order. Not moving the
>> directory before install will result in an unusable mixture of header
>> files from both libraries, but configuring, building, and checking the
>> library requires the ability to compile and run programs against the old
>> library."
>>
>> Do I need to do this as i am building with a specific prefix and, I take
>> it, my original system won't be affected (I won't be chrooted yet). If I
>> do need to follow that what does the 'switch the include directories' 
>> mean?
>>
>> "You may also need to reconfigure GCC to work with the new library.
>> The easiest way to do that is to figure out the compiler switches to
>> make it work again (`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should
>> work on GNU/Linux systems) and use them to recompile gcc."
>>
>> Do I need to do that too? If so, should I specify the --dynamic-linker
>> path to "prefix/target/lib/ld-linux.so.2"?
>
> All this stuff has nothing to do with producing a normal cross GCC for a
> normal already existing target like a Linux distro, Fedora, SuSE, Ubuntu
> etc. !
So, I should disregard this then...

Re: building native cross compiler

[Kai Ruottu]

14.3.2011 20:03, Michael Zintakis kirjoitti:
>
>>> My target system is Linux, though it would come
>>> with two known variants - LFS (Linux from scratch) and Fedora. It will
>>> be used with both architectures (i586/i686 and ppc).
>>
>> Targeting to known and existing targets like Fedora/i686 and Fedora/PPC
>> is easy as a pie : Just build binutils, copy the existing target glibc
>> and finally the GCC.
> So, if I drop the glibc source in the gcc source tree I should be OK
> with cross-compiler building is that what you are suggesting?

Of course not!  The existing targets ALREADY HAVE their C libraries
built and thoroughly tested!  So why on earth anyone would try to
reinvent the wheel?  The binutils and GCC binaries and the extra
target libraries produced during the GCC build using these new
"apps" don't exist in the beginning but all the glibc, X11, Gnome
etc. libraries for the target are already there!  Are you really
seriously trying to reproduce all this glibc, X11, Gnome etc. target
stuff?

> I am not sure what you mean by the above!

That when one only wants a crosstoolchain for instance for Fedora 14
x86_64 when having Ubuntu 10.04/i586, then one just builds binutils
and GCC with their associated target libs built during the GCC build.
BUT doesn't build any of the already existing Fedora 14 x86_64 target
stuff like its original target libraries, only copies them onto the
cross host into a suitable $sysroot...

> I will bootstrap the first compiler - GCC1, which is then going to be
> used to build GCC2 (the cross-compiler) and GCC2 will then have to build
> the entire target system (including another copy of gcc - GCC3, which
> will be solely used to build software on the target system only). I have
> no alternative with this, unfortunately!

Producing the GCC2 would normally happen via using the GCC1 as the build
and host compiler which uses the '/lib', '/usr/include' and '/usr/lib'
during compile and link. These will not be replaced with something made
with the GCC1 after it is ready. The GCC2 will need its own 'lib',
'usr/include' and 'usr/lib' stuff in the $sysroot when configuring the
'libstdc++' etc. GCC-version-specific target libraries and when
producing them... From where these will come is the bad ideological
problem :(  Can one simply copy these from some existing "similar" (to
the becoming target) system?  Or is that "heretic"?  Is one allowed to
use the existing native GCC to produce the GCC1?

I cannot tell what you may do or may not do... For me a component taken
from some existing is fully legal and sane and doesn't differ from using
some existing build and host systems and components from them.  The
world just is such that people don't need to produce tools and temporary
components from scratch before they will be replaced with self-made
ones.

> I assume you understand that my host system will *always* be x86_64 and
> will *always* be Fedora - just in case I wasn't clear with this. So, can
> I build glibc for system other than the host one or is this rapidly
> becoming chicken-and-egg scenario?

Yes you can but there may be requirements for the tools being used. For
instance that the GCC used to build glibc needs to be capable at least
to produce a "Hello World" app for the target, have a 'libgcc' with has
support for threads, exception-handling etc.

> LFS does have sources (and I presume headers too), but in order to build
> it I need GCC2 fully functioning, which is what I am trying to do as
> both host and target systems are different.

So the BIG question is : "Are you allowed to produce a complete and
working GCC2 which has a prebuilt temporary glibc as the target glibc
in some stage?" The process would be :

1. make binutils for the target
2. copy a temporary glibc for the target
3. make GCC for the target
4. make the final glibc for the target with the step 3 GCC and
    overwrite the temporary glibc

Trying to avoid the step 2 in a LFS case although the GCC build
expects the target C library being already there, is just what
the "crosstool" process is for... And is equivalent to the problem
"Can I borrow a knife from a neighbour or buy a knife if I want to
make my own self-made knife?" Producing the wooden handle for the
knife without a knife could sound quite hard :(

These ideological issues can make simple processes being very hard.
Maybe I'm an "opportunist" when just using what one has and not
understanding why using it is not allowed by some policy :(

> So, I should disregard this then...

If the previous 4 step process can be freely used... The goal is to
make first a working cross GCC which can produce apps for the
"virtual" target, first it can be some existing, later some self-
made (to be produced for which the self-made glibc is the first
step, its runtime parts would go to the target system).

Re: building native cross compiler

[Michael Zintakis]

> Are you really
> seriously trying to reproduce all this glibc, X11, Gnome etc. target
> stuff?
What I am trying to do is produce (i.e. compile from source) a 
pre-selected software bundle to a pre-defined target arch without using 
the various distributors binaries. I know I could easily grab some 
random binary toolchain, copy it to my temporary sysroot and just start 
the building process (hell, I could even use kickstart), but that is not 
what I am after.

> Can one simply copy these from some existing "similar" (to
> the becoming target) system?
As I already pointed out - that is not an option for me.

>   Or is that "heretic"?  Is one allowed to
> use the existing native GCC to produce the GCC1?
Yes, that is precisely how I plan to do it - GCC1 will be bootstrapped 
and properly tested and used as a base to build GCC2 and then the rest 
of the software image.

> So the BIG question is : "Are you allowed to produce a complete and
> working GCC2 which has a prebuilt temporary glibc as the target glibc
> in some stage?" The process would be :
>
> 1. make binutils for the target
> 2. copy a temporary glibc for the target
Step 2 above is not an option.

> 3. make GCC for the target
> 4. make the final glibc for the target with the step 3 GCC and
>    overwrite the temporary glibc
>
> Trying to avoid the step 2 in a LFS case although the GCC build
> expects the target C library being already there, is just what
> the "crosstool" process is for... And is equivalent to the problem
> "Can I borrow a knife from a neighbour or buy a knife if I want to
> make my own self-made knife?" Producing the wooden handle for the
> knife without a knife could sound quite hard :(
Well, if it was easy I won't be coming on this mailing list asking for 
help, would I? ;-)

I am sure this has come up before (not just on this mailing list), so a 
solution simply *must* exist. I am currently looking through the 
crosstool scripts to see whether I could use something from them to 
resolve this.

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> From what I gather by reading the INSTALL (and FAQ) files from the
> source archives I would need to build glibc separately, after I built
> binutils, use the same prefix and probably specify the
> "--with-headers" option as well. I take it glibc won't be relying on
> the GCC cross-compiler otherwise we have a chicken-and-egg scenario on
> our hands?

There is a chicken-and-egg scenario.  You need to first build a vanilla
cross-compiler without building the library.  You need to use that to
build glibc.  Then you need to use glibc to build the full
cross-compiler.

> "You must first build the library (`make'), optionally check it
> (`make check'), switch the include directories and then install (`make
> install').  The steps must be done in this order.  Not moving the
> directory before install will result in an unusable mixture of header
> files from both libraries, but configuring, building, and checking the
> library requires the ability to compile and run programs against the old
> library."
>
> Do I need to do this as i am building with a specific prefix and, I
> take it, my original system won't be affected (I won't be chrooted
> yet). If I do need to follow that what does the 'switch the include
> directories' mean?

Right, if you use a different --prefix that shouldn't matter, I think.

> "You may also need to reconfigure GCC to work with the new library.
> The easiest way to do that is to figure out the compiler switches to
> make it work again (`-Wl,--dynamic-linker=/lib/ld-linux.so.2' should
> work on GNU/Linux systems) and use them to recompile gcc."
>
> Do I need to do that too? If so, should I specify the --dynamic-linker
> path to "prefix/target/lib/ld-linux.so.2"?

This is really only an issue when building glibc for your own system
which is not what you are doing.

> "You can install glibc somewhere other than where you configured it
> to go by setting the `install_root' variable on the command line for
> `make install'.  The value of this variable is prepended to all the
> paths for installation.  This is useful when setting up a chroot
> environment or preparing a binary distribution.  The directory should be
> specified with an absolute file name."
>
> Same here - I assumed when specifying the prefix that will be enough
> (without specifying 'install_root') or is it?

It is enough.

> Finally, in the same file there is mention that I would also need the
> header files for the Linux arch (presumably the target arch as I
> already have the host ones installed) - is that really a requirement?

As far as I know, it is a requirement.

> Also, I take it it is not possible to build glibc at the same time I
> build GCC (i.e. by dropping the source tree into the GCC main tree),
> right?

Right.

Anyhow look at http://kegel.com/crosstool/ .

Ian

Re: building native cross compiler

[Michael Zintakis]

>> From what I gather by reading the INSTALL (and FAQ) files from the
>> source archives I would need to build glibc separately, after I built
>> binutils, use the same prefix and probably specify the
>> "--with-headers" option as well. I take it glibc won't be relying on
>> the GCC cross-compiler otherwise we have a chicken-and-egg scenario on
>> our hands?
>>     
>
> There is a chicken-and-egg scenario.
:-(

I sort of thought as much by what I looked at so far...

>   You need to first build a vanilla
> cross-compiler without building the library.
What does constitute a "vanilla cross-compiler"? Is this a "limited" 
cross-compiler without the glibc dependencies (because that is the only 
way I think possible to have glibc and a fully-fledged cross compiler 
the way I want it)?

>   You need to use that to
> build glibc.  Then you need to use glibc to build the full
> cross-compiler.
>   
I see, thought as much. Small steps and all that!


>> Finally, in the same file there is mention that I would also need the
>> header files for the Linux arch (presumably the target arch as I
>> already have the host ones installed) - is that really a requirement?
>>     
>
> As far as I know, it is a requirement.
>   
I've just downloaded the headers, but (see below) I think I found 
exactly what I was looking for...

>> Also, I take it it is not possible to build glibc at the same time I
>> build GCC (i.e. by dropping the source tree into the GCC main tree),
>> right?
>>     
>
> Right.
>
> Anyhow look at http://kegel.com/crosstool/ .
>   
W-H-A-T a gem that crosstool.sh file is (provided it works though)!

According to the help page it even builds a canadian cross (build - 
x86_64, host & target - ppc) though I have to execute it 3 times to get 
that done - that is my GCC2 & 3 built straight away (again, on the 
proviso that it works - a big if though). I am looking at the various 
variables it requires right now and see if I can manage to include my 
own compiler/optimisation options before I fire it up.

If that little gem does what it is supposed to I will be extremely happy 
as about 40% of my job will be done - just like that! Fingers crossed 
though.

MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

>>   You need to first build a vanilla
>> cross-compiler without building the library.
> What does constitute a "vanilla cross-compiler"? Is this a "limited"
> cross-compiler without the glibc dependencies (because that is the
> only way I think possible to have glibc and a fully-fledged cross
> compiler the way I want it)?

Yes, build just the compiler, and none of the libraries.

Ian

Re: building native cross compiler

[Michael Zintakis]

>>>   You need to first build a vanilla
>>> cross-compiler without building the library.
>>>       
>> What does constitute a "vanilla cross-compiler"? Is this a "limited"
>> cross-compiler without the glibc dependencies (because that is the
>> only way I think possible to have glibc and a fully-fledged cross
>> compiler the way I want it)?
>>     
>
> Yes, build just the compiler, and none of the libraries.
>   
Hmm, that didn't go down well!

The crosstool.sh script is so outdated is unreal! I found it nigh 
impossible to use it in its present form, so I have to get what it does 
and, hopefully, adapt it. There are many things this script is trying to 
do and I am not sure I understand the reason for it. For example, before 
starting to build binutils it is trying to execute "make" in the main 
linux headers directory with ARCH specified and parameters "include/asm 
include/linux/version.h" (line 347) and that obviously fails as there 
isn't any target with that name. Why is it doing that it is a mystery to 
me! And why the hell do I need to execute "make oldconfig" in the main 
linux directory? I am not compiling the kernel (at least not yet).

One other thing is that ARCH named 'ppc' doesn't exist - it is 'powerpc' 
and that screws things up even more. The last error I've got after 
'patching up' the above "problems" is that during the binutils build 
make fails as it is apparently looking for <build_arch>-ar which does 
not exist either. Things like that...

So, I'll have a more thorough look tomorrow to see whether I could do 
these things 'manually', but I am not at all hopeful.

Has this been done recently? I can't believe there is no methodology for 
this and I have to rely on a bloody script which has been last updated 6 
years ago!!! Unreal!


MZ

Re: building native cross compiler

[Ian Lance Taylor]

Michael Zintakis <michael.zintakis@googlemail.com> writes:

> Has this been done recently? I can't believe there is no methodology
> for this and I have to rely on a bloody script which has been last
> updated 6 years ago!!! Unreal!

Believe it.  Very few people cross-compile GNU/Linux toolchains.  The
ones who do have all climbed the learning curve that you are on.

I wonder if there is a newer crosstool script out there somewhere.

Ian

RE: building native cross compiler

[Mick McCreath]

> From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On Behalf Of Ian Lance Taylor
> Sent: Tuesday, 15 March 2011 2:24 PM
> To: Michael Zintakis
> Cc: gcc-help@gcc.gnu.org
> Subject: Re: building native cross compiler
>
> Michael Zintakis <michael.zintakis@googlemail.com> writes:
>
> > Has this been done recently? I can't believe there is no methodology
> > for this and I have to rely on a bloody script which has been last
> > updated 6 years ago!!! Unreal!
>
> Believe it.  Very few people cross-compile GNU/Linux toolchains.  The
> ones who do have all climbed the learning curve that you are on.
>
> I wonder if there is a newer crosstool script out there somewhere.
>
> Ian

The revamped tool is called crosstool-ng and is available from here:

http://ymorin.is-a-geek.org/projects/crosstool

Cheers,

Mick

Re: building native cross compiler

[Michael Zintakis]

>> I wonder if there is a newer crosstool script out there somewhere.
>>
>> Ian
>>     
>
> The revamped tool is called crosstool-ng and is available from here:
>
> http://ymorin.is-a-geek.org/projects/crosstool
>   
Thanks Mick for posting the link - this crosstool seems to be in active 
development, and having already tried it, it gave me a lot of ideas as 
to how to automate the build processes on my own project.

This tool, however, is unable to overcome another glibbloodyc problem 
and I am really stuck this time, despite my best efforts, so I hope by 
posting it here there will be more than a pair of eyes looking into it 
and see if I could solve this.

I already posted this on the crosstool-ng mailing list, though don't 
know if I am going to get an answer.

The problem is the following (from make of the fully-blown glibc build):

  powerpc-unknown-linux-gnu-gcc      -nostdlib -nostartfiles -r -o 
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/librtld.map.o 
'-Wl,-(' 
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/dl-allobjs.os 
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/libc_pic.a 
-lgcc '-Wl,-)' 
-Wl,-Map,/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/librtld.mapT
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/libc_pic.a(dl-addr.os): 
In function `_dl_addr_inside_object':
  /home/mz/gcc-test/build/src/glibc-2.12.2/elf/dl-addr.c:157: multiple 
definition of `_dl_addr_inside_object'
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/dl-allobjs.os:/home/mz/gcc-test/build/src/glibc-2.12.2/elf/dl-open.c:659: 
first defined here
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/libc_pic.a(init-first.os):(.sdata+0x0): 
multiple definition of `__libc_multiple_libcs'
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/dl-allobjs.os:/home/mz/gcc-test/build/src/glibc-2.12.2/elf/rtld.c:792: 
first defined here
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/libc_pic.a(init-first.os): 
In function `_dl_start':
  
/home/mz/gcc-test/build/src/glibc-2.12.2/csu/../sysdeps/unix/sysv/linux/powerpc/../init-first.c:111: 
multiple definition of `_dl_start'
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/dl-allobjs.os:/home/mz/gcc-test/build/src/glibc-2.12.2/elf/rtld.c:400: 
first defined here
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/libc_pic.a(_itoa.os): 
In function `_itoa':
  /home/mz/gcc-test/build/src/glibc-2.12.2/stdio-common/_itoa.c:218: 
multiple definition of `_itoa'
  
/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/dl-allobjs.os:/home/mz/gcc-test/build/src/glibc-2.12.2/elf/dl-minimal.c:303: 
first defined here
  collect2: ld returned 1 exit status
  make[3]: *** 
[/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/librtld.map] 
Error 1
  make[3]: Leaving directory `/home/mz/gcc-test/build/src/glibc-2.12.2/elf'
  make[2]: *** [elf/subdir_lib] Error 2
  make[2]: Leaving directory `/home/mz/gcc-test/build/src/glibc-2.12.2'
  make[1]: *** [all] Error 2
  make[1]: Leaving directory 
`/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc'

This happens much further in the process that I have been before, during 
the glibc build after all the kernel headers, gmp, mpfr, ppl, cloog-ppl, 
mpc, libelf, binutils, core gcc, basic glibc (headers and files) and the 
shared core gcc have been built:

[INFO ]  Performing some trivial sanity checks
[INFO ]  Build started 20110316.035430
[INFO ]  Building environment variables
[INFO ]  Downloading forbidden by configuration, skipping downloads
[INFO ]  =================================================================
[INFO ]  Extracting and patching toolchain components
[INFO ]  Extracting and patching toolchain components: done in 101.93s 
(at 01:44)
[INFO ]  =================================================================
[INFO ]  Installing kernel headers
[INFO ]  Installing kernel headers: done in 12.83s (at 01:56)
[INFO ]  =================================================================
[INFO ]  Installing GMP
[INFO ]  Installing GMP: done in 65.69s (at 03:02)
[INFO ]  =================================================================
[INFO ]  Installing MPFR
[INFO ]  Installing MPFR: done in 16.17s (at 03:18)
[INFO ]  =================================================================
[INFO ]  Installing PPL
[INFO ]  Installing PPL: done in 72.93s (at 04:31)
[INFO ]  =================================================================
[INFO ]  Installing CLooG/ppl
[INFO ]  Installing CLooG/ppl: done in 5.96s (at 04:37)
[INFO ]  =================================================================
[INFO ]  Installing MPC
[INFO ]  Installing MPC: done in 7.97s (at 04:45)
[INFO ]  =================================================================
[INFO ]  Installing libelf
[INFO ]  Installing libelf: done in 4.36s (at 04:50)
[INFO ]  =================================================================
[INFO ]  Installing binutils
[INFO ]  Installing binutils: done in 43.16s (at 05:33)
[INFO ]  =================================================================
[INFO ]  Installing static core C compiler
[INFO ]  Installing static core C compiler: done in 230.83s (at 09:24)
[INFO ]  =================================================================
[INFO ]  Installing C library headers & start files
[INFO ]  Installing C library headers & start files: done in 47.99s (at 
10:12)
[INFO ]  =================================================================
[INFO ]  Installing shared core C compiler
[INFO ]  Installing shared core C compiler: done in 277.37s (at 14:49)
[INFO ]  =================================================================
[INFO ]  Installing C library
  make[3]: *** 
[/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/build-libc/elf/librtld.map] 
Error 1
  make[2]: *** [elf/subdir_lib] Error 2
  make[1]: *** [all] Error 2
  Build failed in step 'Installing C library'
  Error happened in '/home/mz/gcc/crosstool-ng-1.10.0/scripts/functions' 
in function 'CT_DoExecLog' (line unknown, sorry)
        called from 
'/home/mz/gcc/crosstool-ng-1.10.0/scripts/build/libc/glibc-eglibc.sh-common' 
at line # 251 in function 'do_libc'
        called from 
'/home/mz/gcc/crosstool-ng-1.10.0/scripts/crosstool-NG.sh' at line # 606 
in function 'main'
  Look at 
'/home/mz/gcc-test/install/powerpc-unknown-linux-gnu/build.log' for more 
info on this error.
(elapsed: 21:12.18)
 make: *** [build] Error 2


Any ideas as to what might be the cause for this. I used google and 
tried 3 of the things suggested, i.e. removing "-fstack-protector" (I 
use this option when building gcc), then force this by adding 
"-fno-stack-protector" to both the gcc and glibc builds and finally use 
"-j1" instead of (my usual) "-j3" but nothing worked, unfortunately!

Any ideas?

Re: building native cross compiler

[Michael Zintakis]

> The revamped tool is called crosstool-ng and is available from here:
>
> http://ymorin.is-a-geek.org/projects/crosstool
>   
Last night, after about 11 hours non-stop on it, I tasted success at last!!!

The culprit seems to be the version of gcc I have used up until now - 
gcc 4.5.2. This version seems to be not so well supported by this tool 
judging by the number of patches it had (yes, I know :-) !) and as soon 
as I switched to gcc 4.4.5 and made a few other tweaks the build was 
completed.

I was able to optimise the process as much as I could and found out that 
gcc 4.4.5 is having difficulty talking to ppl 0.11+ - there was a 
hard-coded check for the ppl version in gcc configure/configure.ac 
(something like "PPL_MINOR_VERSION != $ppl_version") which at first 
appeared to be completely wrong (and something I patched immediately to 
"PPL_MINOR_VERSION < $ppl_version" to accept versions 0.11 and above), 
but then the build failed as I was getting "undefined reference" errors 
like these:

/home/mz/gcc-test/build/powerpc-unknown-linux-gnu/build/static/lib/libppl_c.a(ppl_c_implementation_common.o): 
In function `Parma_Polyhedra_Library::Interfaces::C::reset_timeout()':
ppl_c_implementation_common.cc:(.text+0x771): undefined reference to 
`Parma_Watchdog_Library::Watchdog::in_critical_section'
ppl_c_implementation_common.cc:(.text+0x777): undefined reference to 
`Parma_Watchdog_Library::Watchdog::remove_watchdog_event(Parma_Watchdog_Library::EList_Iterator<Parma_Watchdog_Library::Pending_Element<Parma_Watchdog_Library::Time> 
 >)'

[...]

So, I had to use ppl version 0.10.2, otherwise gcc 4.4.5 won't be 
compiled. From what I had time to test I found that the optimum 
'combination' of packages for cross-compilation (at least in my case 
anyway) is gmp 5.0.1, mpfr 3.0.1, mpc 0.9,   cloog 0.15.10, ppl 0.10.2, 
binutils 2.20.1, glibc 2.13 + ports.

Special mention needs to be done for the MPFR package - there is a 
patch, which is applied to gcc 4.5.x (but that patch is not done for 
previous gcc releases - like 4.4.5 for example) which enables it to use 
MPFR version 3.0 and above. If that patch is not applied I am stuck with 
MPFR 2.4.2, so I had to apply this to the earlier version of gcc I was 
using. I do not know who maintains gcc, but it is nice to have it 
submitted and "propagated" for earlier gcc versions to allow the above 
package to be used.

I tried to create executables using the new toolchain (simple programs, 
just to test the functionality - nothing complex) - it works, but when I 
apply "file" on these executables, it gives me some information I cannot 
quite understand. For example:

[mz@test1 install]$ file nano
nano: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
(SYSV), dynamically linked (uses shared libs), stripped

[mz@test1 install]$ file fractal_simple
fractal_simple: ELF 32-bit MSB executable, PowerPC or cisco 4500, 
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 
2.6.35, with unknown capability 0x41000000 = 0x13676e75, with unknown 
capability 0x10000 = 0xb0401, stripped

In the above, "nano" is the famous screen editor, stock-compiled for my 
system (PPC - G2/603e CPU) and "file" detects it, though for my program 
(fractal_simple) although it lists the same system it has two "unknown 
capability" fields which I am not certain what that means. Any ideas 
what these are?

Finally, is there a way to remove the 'dependency' on the kernel version 
("GNU/Linux 2.6.35" in the above example)? Many thanks in advance!