Gnu GCC 4.8 cross compiler.

Has anyone had any luck building the new 4.8 version as a
cross-compiler? I've successfully built it as a native compiler for
Ubuntu but the cross compile is failing with a config error late in the
compile. This is my configure statement:

./configure --build=arm-angstrom-linux-gnueabi
--host=arm-angstrom-linux-gnueabi --prefix=/usr/arm-linux-gnueabi-4.8
-bindir=/usr/arm-linux-gnueabi-4.8 --disable-fortran --disable-java
--disable-lto --disable-objc -enable-neon

Any helpful comments would be most appreciated.

John

Hi John,

I am currently using GCC 4.8 built through OpenEmbedded with patches recently posted, I don't know how the Ubuntu work flow works, but do they have -next or -testing repositories that would possibly have the installable 4.8 toolchain in?

Otherwise, what is in the configure error, I'm no GCC guru but it would at least maybe give a hint to the underlying problem.

Cheers,
Jack.

Hi John,

I am currently using GCC 4.8 built through OpenEmbedded with patches
recently posted, I don't know how the Ubuntu work flow works, but do
they have -next or -testing repositories that would possibly have the
installable 4.8 toolchain in?

Can the compiler build be had without getting the whole OE system? I
looked on their site and didn't see anything.

Otherwise, what is in the configure error, I'm no GCC guru but it would
at least maybe give a hint to the underlying problem.

Thanks Jack,

Here's my slightly modified configure command line.

./configure --host=arm-angstrom-linux-gnueabi
--prefix=/usr/arm-linux-gnueabi -exec-prefix=/usr/arm-linux-gnuabi
-bindir=/usr/arm-linux-gnueabi --disable-fortran --disable-java
--disable-lto --disable-objc -enable-neon

It runs for quite a long time and then the following is output to the screen

checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
/home/jgd/gcc/gcc-4.8.0/gcc-4.8.0-arm/libgcc/configure: line 2551: cc:
command not found
checking for arm-angstrom-linux-gnueabi-ar... ar
checking for arm-angstrom-linux-gnueabi-lipo... lipo
checking for arm-angstrom-linux-gnueabi-nm... nm
checking for arm-angstrom-linux-gnueabi-ranlib... ranlib
checking for arm-angstrom-linux-gnueabi-strip... strip
checking whether ln -s works... yes
checking for arm-angstrom-linux-gnueabi-gcc... cc
checking for suffix of object files... configure: error: in
`/home/jgd/gcc/gcc-4.8.0/gcc-4.8.0-arm/arm-angstrom-linux-gnueabi/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/jgd/gcc/gcc-4.8.0/gcc-4.8.0-arm'
make: *** [all] Error 2

I've dug around in the configure file as much as I can with the limited
knowledge I have of it. I don't understand the part about

"line 2551: cc: command not found"

Why would it be trying to use cc? I don't see anything in configure in
that vicinity that would generate that error message.

The error message is generated in the vicinity of line 4432 in configure.

That's about all I've figured out so far.

BTW, where do you get the patches from? I just looked at the official
GCC site and it is still at 4.8.0 and not patches in sight.

Thanks,
John

Hi John,

I am currently using GCC 4.8 built through OpenEmbedded with patches
recently posted, I don't know how the Ubuntu work flow works, but do
they have -next or -testing repositories that would possibly have the
installable 4.8 toolchain in?

Can the compiler build be had without getting the whole OE system? I
looked on their site and didn't see anything.

There are other ways of building toolchains, one of which I have heard recommend is crosstool-ng, this allows the building of _only_ the tool chain, unlike OpenEmbedded which is a bit more involved.

Otherwise, what is in the configure error, I'm no GCC guru but it would
at least maybe give a hint to the underlying problem.

Thanks Jack,

Here's my slightly modified configure command line.

./configure --host=arm-angstrom-linux-gnueabi
--prefix=/usr/arm-linux-gnueabi -exec-prefix=/usr/arm-linux-gnuabi
-bindir=/usr/arm-linux-gnueabi --disable-fortran --disable-java
--disable-lto --disable-objc -enable-neon

> -exec-prefix=/usr/arm-linux-gnuabi

Shouldn't this be:

-exec-prefix=/usr/arm-linux-gnueabi

It runs for quite a long time and then the following is output to the screen

checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
/home/jgd/gcc/gcc-4.8.0/gcc-4.8.0-arm/libgcc/configure: line 2551: cc:
command not found
checking for arm-angstrom-linux-gnueabi-ar... ar
checking for arm-angstrom-linux-gnueabi-lipo... lipo
checking for arm-angstrom-linux-gnueabi-nm... nm
checking for arm-angstrom-linux-gnueabi-ranlib... ranlib
checking for arm-angstrom-linux-gnueabi-strip... strip
checking whether ln -s works... yes
checking for arm-angstrom-linux-gnueabi-gcc... cc
checking for suffix of object files... configure: error: in
`/home/jgd/gcc/gcc-4.8.0/gcc-4.8.0-arm/arm-angstrom-linux-gnueabi/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/jgd/gcc/gcc-4.8.0/gcc-4.8.0-arm'
make: *** [all] Error 2

I've dug around in the configure file as much as I can with the limited
knowledge I have of it. I don't understand the part about

"line 2551: cc: command not found"

I'm not sure on this, the only thing that springs to mind is if it tries to use

$CC for the compilerand that isn't set in your environment... maybe it can't find your host GCC.

Why would it be trying to use cc? I don't see anything in configure in
that vicinity that would generate that error message.

The error message is generated in the vicinity of line 4432 in configure.

That's about all I've figured out so far.

BTW, where do you get the patches from? I just looked at the official
GCC site and it is still at 4.8.0 and not patches in sight.

The OpenEmbedded patches for GCC 4.8 were posted to the OpenEmbedded mailing list about a week ago as an RFC. They will go in after 1.4 has been released (in the few weeks or so), I pulled them in early to do some testing and fix a bug I was encountering on GCC 4.7.x.

Thank you Thank you Thank you for that recommendation. After
spending a week trying to figure out the right configure options with
the help of some of the best on the GCC mailing list (and failing) I
tried this.

It took two shots to get it right. The first time the ARM gnuebi
default configuration was set for a hardware math processor. Instant
core dump with the first floating point math. I corrected that and
re-ran the build and it worked perfectly.

Unfortunately it makes slower code than the 4.6 version that's available
through the package channels for Ubuntu. Whomever built that compiler
really knew what he was doing. I'm going to study his config settings
and see if they'll work with 4.8.

One odd thing about it. I wanted the toolchain to reside in /usr where
it belongs. ct-ng would not execute as root. I had to chmod 0777 /usr
to let it build before resetting the permissions. strange.

Thanks again for the recommendation.

John

NeonJohn <jgd@neon-john.com> writes:

There are other ways of building toolchains, one of which I have heard
recommend is crosstool-ng, this allows the building of _only_ the tool
chain, unlike OpenEmbedded which is a bit more involved.

http://crosstool-ng.org/

Thank you Thank you Thank you for that recommendation. After
spending a week trying to figure out the right configure options with
the help of some of the best on the GCC mailing list (and failing) I
tried this.

It took two shots to get it right. The first time the ARM gnuebi
default configuration was set for a hardware math processor. Instant
core dump with the first floating point math. I corrected that and
re-ran the build and it worked perfectly.

What kind of antique hardware are you using that doesn't have
floating-point?

Unfortunately it makes slower code than the 4.6 version that's available
through the package channels for Ubuntu. Whomever built that compiler
really knew what he was doing. I'm going to study his config settings
and see if they'll work with 4.8.

That sounds odd. 4.8 has a lot of improvements compared to 4.6.

If you can get crosstool-ng to build the Linaro GCC that may provide better performance, Linaro quite often includes extra optimisation patches,.

Cheers,
Jack.

What kind of antique hardware are you using that doesn't have
floating-point?

Beaglebone.

Unfortunately it makes slower code than the 4.6 version that's available
through the package channels for Ubuntu. Whomever built that compiler
really knew what he was doing. I'm going to study his config settings
and see if they'll work with 4.8.

That sounds odd. 4.8 has a lot of improvements compared to 4.6.

I need to correct a bit of what I said last night. My reference
compiler is the Linaro 4.7.2 version. I had forgotten about installing
it until I went back through my log book.

The crosstools-NG package that Robert recommended only goes to 4.7.2. I
tried to sneak 4.8 in by editing the generated config file but it
crashed. I haven't taken the time yet to figure out why. I may yet be
able to slip it in there.

The 4.8 improvements are academic right now since I can't get it to
build. And as the Linaro package demonstrates, it takes a very skilled
compiler expert to get the optimizations just right.

John

NeonJohn <jgd@neon-john.com> writes:

What kind of antique hardware are you using that doesn't have
floating-point?

Beaglebone.

Has floating-point.

Unfortunately it makes slower code than the 4.6 version that's available
through the package channels for Ubuntu. Whomever built that compiler
really knew what he was doing. I'm going to study his config settings
and see if they'll work with 4.8.

That sounds odd. 4.8 has a lot of improvements compared to 4.6.

I need to correct a bit of what I said last night. My reference
compiler is the Linaro 4.7.2 version. I had forgotten about installing
it until I went back through my log book.

The crosstools-NG package that Robert recommended only goes to 4.7.2. I
tried to sneak 4.8 in by editing the generated config file but it
crashed. I haven't taken the time yet to figure out why. I may yet be
able to slip it in there.

The 4.8 improvements are academic right now since I can't get it to
build. And as the Linaro package demonstrates, it takes a very skilled
compiler expert to get the optimizations just right.

Have you tried the prebuilt packages from Linaro?
https://launchpad.net/linaro-toolchain-binaries

NeonJohn <jgd@neon-john.com> writes:

What kind of antique hardware are you using that doesn't have
floating-point?

Beaglebone.

Has floating-point.

Soft floating point. Set the optimization switch to hardware floating
point and that'll guarantee a core dump.

Have you tried the prebuilt packages from Linaro?
https://launchpad.net/linaro-toolchain-binaries

yes, that's my reference package. I'm working now to fit all their
optimizations into crosstools. I'm close - 32ms for the
crosstools-built Linaro vs 24 for their build.

John

NeonJohn <jgd@neon-john.com> writes:

--with-float=softfp

That's not my setting. That's the Linaro binary distribution setting.
I tried it set to hardfp and got core dumps on the first FP math.

John