Problem trying to configure / build when using "--program-prefix" option

[David Paterson]

Hi all,

I'm running into a strange problem when using the "--program-prefix"
option during configuration. I've built Newlib successfully before
without it, and now want to "personalise" the cross toolchain I'm
working on.

I'm configuring with :-

../newlib-1.19.0/configure --target=sparc-elf --disable-shared --disable-nls \
--disable-werror --disable-newlib-supplied-syscalls --enable-interwork \
--enable-multilib --with-gnu-as --with-gnu-ld --prefix=/usr/local/SparcTools \
--program-prefix="test-elf-"

and during the config I'm seeing the following messages :-

checking for sparc-elf-cc... no
checking for sparc-elf-gcc... no
checking for sparc-elf-c++... no
checking for sparc-elf-g++... no
checking for sparc-elf-cxx... no
checking for sparc-elf-gxx... no
checking for sparc-elf-gcc... no
checking for sparc-elf-gcj... no
etc. for several more tool names...

Then, when I try to build (make all) I get :-

/bin/sh: sparc-elf-cc: command not found

Which of course is correct, since there isn't any "sparc-elf-" tools, as they're
all named "test-elf-gcc" and the like. GCC and Binutils all seem to be happy
with the program prefix option, and create their outputs as expected.

If I rebuild everything without using "--program-prefix" then I get :-

checking for sparc-elf-cc... no
checking for sparc-elf-gcc... sparc-elf-gcc
checking for sparc-elf-c++... sparc-elf-c++
etc.

as if finds the tools correctly, and Newlib builds without problems.

I'm guesing there's a config option I need to add to specify that I'm using a
non-target-triplet prefix system, but I've read through the list of options
several times and can't see what I need to use.

I'd appreciate a hint or two as to where I'm going wrong :-) I'd really like to
use a project-specific prefix for these tools, but if I can't, I guess
I can live
with it...

Regards,

David P.

[Federico Terraneo]

Post by David Paterson
Hi all,
I'm running into a strange problem when using the "--program-prefix"
option during configuration. I've built Newlib successfully before
without it, and now want to "personalise" the cross toolchain I'm
working on.
I'm configuring with :-
../newlib-1.19.0/configure --target=sparc-elf --disable-shared --disable-nls \
--disable-werror --disable-newlib-supplied-syscalls --enable-interwork \
--enable-multilib --with-gnu-as --with-gnu-ld --prefix=/usr/local/SparcTools \
--program-prefix="test-elf-"
and during the config I'm seeing the following messages :-
checking for sparc-elf-cc... no
checking for sparc-elf-gcc... no
checking for sparc-elf-c++... no
checking for sparc-elf-g++... no
checking for sparc-elf-cxx... no
checking for sparc-elf-gxx... no
checking for sparc-elf-gcc... no
checking for sparc-elf-gcj... no
etc. for several more tool names...
Then, when I try to build (make all) I get :-
/bin/sh: sparc-elf-cc: command not found
Which of course is correct, since there isn't any "sparc-elf-" tools, as they're
all named "test-elf-gcc" and the like. GCC and Binutils all seem to be happy
with the program prefix option, and create their outputs as expected.

I ran into the same problem and found a workaround, which consists in
passing those options to the configure:
CC_FOR_TARGET=<your compiler prefix>-gcc
CXX_FOR_TARGET=<your compiler prefix>-g++
GCC_FOR_TARGET=<your compiler prefix>-gcc
AR_FOR_TARGET=<your compiler prefix>-ar
AS_FOR_TARGET=<your compiler prefix>-as
LD_FOR_TARGET=<your compiler prefix>-ld
NM_FOR_TARGET=<your compiler prefix>-nm
RANLIB_FOR_TARGET=<your compiler prefix>-ranlib

The full command line I'm using to call newlib's configure is this:
./newlib-1.18.0/configure --target=arm-eabi
- --prefix=/opt/arm-miosix-eabi --enable-interwork --enable-multilib
- --with-float=soft --disable-newlib-io-pos-args --disable-newlib-mb
- --enable-newlib-multithread CC_FOR_TARGET=arm-miosix-eabi-gcc
CXX_FOR_TARGET=arm-miosix-eabi-g++ GCC_FOR_TARGET=arm-miosix-eabi-gcc
AR_FOR_TARGET=arm-miosix-eabi-ar AS_FOR_TARGET=arm-miosix-eabi-as
LD_FOR_TARGET=arm-miosix-eabi-ld NM_FOR_TARGET=arm-miosix-eabi-nm
RANLIB_FOR_TARGET=arm-miosix-eabi-ranlib

If anyone knows a cleaner way to do so, let me know

[David Paterson]

Post by Federico Terraneo
I ran into the same problem and found a workaround, which consists in
CC_FOR_TARGET=<your compiler prefix>-gcc
CXX_FOR_TARGET=<your compiler prefix>-g++
GCC_FOR_TARGET=<your compiler prefix>-gcc
AR_FOR_TARGET=<your compiler prefix>-ar
AS_FOR_TARGET=<your compiler prefix>-as
LD_FOR_TARGET=<your compiler prefix>-ld
NM_FOR_TARGET=<your compiler prefix>-nm
RANLIB_FOR_TARGET=<your compiler prefix>-ranlib
./newlib-1.18.0/configure --target=arm-eabi
- --prefix=/opt/arm-miosix-eabi --enable-interwork --enable-multilib
- --with-float=soft --disable-newlib-io-pos-args --disable-newlib-mb
- --enable-newlib-multithread CC_FOR_TARGET=arm-miosix-eabi-gcc
CXX_FOR_TARGET=arm-miosix-eabi-g++ GCC_FOR_TARGET=arm-miosix-eabi-gcc
AR_FOR_TARGET=arm-miosix-eabi-ar AS_FOR_TARGET=arm-miosix-eabi-as
LD_FOR_TARGET=arm-miosix-eabi-ld NM_FOR_TARGET=arm-miosix-eabi-nm
RANLIB_FOR_TARGET=arm-miosix-eabi-ranlib

Thanks Federico, that works great :-) I'd seen those listed in the configure
options so should have given them a try. I did expect that setting the prefix
would point the configure system at the correct tools though...

Post by Federico Terraneo
If anyone knows a cleaner way to do so, let me know

Indeed! It may be that the configure script needs a tweak to use the prefix if
one is set (and if there's no explicit alternative given as above). I'm still
learning about all of this GCC configuration and building malarkey,
but I'll have
a look at modifying the script when I get a bit of spare time.

Cheers,

David P.

[Ralf Corsepius]

Post by David Paterson
Thanks Federico, that works great :-) I'd seen those listed in the configure
options so should have given them a try. I did expect that setting the prefix
would point the configure system at the correct tools though...

--program-prefix is not what you assume it to be ... it is the "prefix"
which is prepended to cross-tools when a package creates tools
(application). As newlib is a mere library, it do doesn't build any
tools, so --program-prefix is not meaningful to newlib.

That said, the toplevel configure script uses the value being passed to
--target=<TARGET> as "program-prefix" of the toolchain to be used. I.e.
if you are building for --target=<something>, it expects to find tools
named "<something>-*" in $PATH.


Ralf

[David Paterson]

On Tue, Apr 19, 2011 at 10:48 AM, Ralf Corsepius

Post by Ralf Corsepius

Thanks Federico, that works great :-)  I'd seen those listed in the
configure
options so should have given them a try.  I did expect that setting the
prefix
would point the configure system at the correct tools though...

--program-prefix is not what you assume it to be ... it is the "prefix"
which is prepended to cross-tools when a package creates tools
(application). As newlib is a mere library, it do doesn't build any tools,
so --program-prefix is not meaningful to newlib.

Yup, I understand that, and it makes more sense when building GCC and
Binutils, but it is listed in the configure options for Newlib so I'd
expect it to
have some effect on what happens during the build.

For consistency, and nice, neat build scripts, it would be ideal to set most
of the same set of options at each build stage (which is pretty much what
I'm doing in fact).

Post by Ralf Corsepius
That said, the toplevel configure script uses the value being passed to
--target=<TARGET> as "program-prefix" of the toolchain to be used. I.e. if
you are building for --target=<something>, it expects to find tools named
"<something>-*" in $PATH.

So would setting the "--target" option be the answer for Newlib? It makes it
a bit inconsistent when for the other bits of the toolchain build it
specifies the
target architecture, but for Newlib it's the name (or prefix) of the
target tools.

Time for a bit more experimenting I think...

Cheers,

David P.