Discussion:
GCC 4.7 on Android G++ Compiler Build Fail "This Linker Not Config To Use Sysroots"
Cyd Haselton
2014-09-27 11:00:43 UTC
Permalink
Background:
I'm using GCC 4.7.0 (without a c++ compiler) on an Android device in
an emulated Linux environment (KBOX) to build a C++ compiler. My goal
is to build a 4.7.0 C++ compiler, then build a 4.8.0 C++ compiler.

No matter which config flags I use, the build keeps failing with
"/usr/local/bin/ld" this linker is not configured touse sysroots"
I've checked the specs for the ld at that location, and it does
support sysroot.

What am I doing wrong?

Please let me know what logs, env vars, etc. I should send to aid in
troubleshooting...

Thanks,
Cyd
Brian Drummond
2014-09-27 11:46:49 UTC
Permalink
Post by Cyd Haselton
I'm using GCC 4.7.0 (without a c++ compiler) on an Android device in
an emulated Linux environment (KBOX) to build a C++ compiler. My goal
is to build a 4.7.0 C++ compiler, then build a 4.8.0 C++ compiler.
No matter which config flags I use, the build keeps failing with
"/usr/local/bin/ld" this linker is not configured touse sysroots"
I've checked the specs for the ld at that location, and it does
support sysroot.
What am I doing wrong?
Please let me know what logs, env vars, etc. I should send to aid in
troubleshooting...
First question would be : are you using those config flags to build
binutils (to support sysroots) and install it, then build gcc?

That's not entirely clear from the question

- Brian
Cyd Haselton
2014-09-27 23:33:52 UTC
Permalink
gcc-help Digest 27 Sep 2014 11:46:57 -0000 Issue 4675
GCC 4.7 on Android G++ Compiler Build Fail "This Linker Not Config To Use Sysroots"
55889 by: Cyd Haselton
55890 by: Brian Drummond
----------------------------------------------------------------------
---------- Forwarded message ----------
Date: Sat, 27 Sep 2014 06:00:43 -0500
Subject: GCC 4.7 on Android G++ Compiler Build Fail "This Linker Not Config To Use Sysroots"
I'm using GCC 4.7.0 (without a c++ compiler) on an Android device in
an emulated Linux environment (KBOX) to build a C++ compiler. My goal
is to build a 4.7.0 C++ compiler, then build a 4.8.0 C++ compiler.
No matter which config flags I use, the build keeps failing with
"/usr/local/bin/ld" this linker is not configured touse sysroots"
I've checked the specs for the ld at that location, and it does
support sysroot.
What am I doing wrong?
Please let me know what logs, env vars, etc. I should send to aid in
troubleshooting...
Thanks,
Cyd
---------- Forwarded message ----------
Date: Sat, 27 Sep 2014 12:46:49 +0100
Subject: Re: GCC 4.7 on Android G++ Compiler Build Fail "This Linker Not Config To Use Sysroots"
Post by Cyd Haselton
I'm using GCC 4.7.0 (without a c++ compiler) on an Android device in
an emulated Linux environment (KBOX) to build a C++ compiler. My goal
is to build a 4.7.0 C++ compiler, then build a 4.8.0 C++ compiler.
No matter which config flags I use, the build keeps failing with
"/usr/local/bin/ld" this linker is not configured touse sysroots"
I've checked the specs for the ld at that location, and it does
support sysroot.
What am I doing wrong?
Please let me know what logs, env vars, etc. I should send to aid in
troubleshooting...
First question would be : are you using those config flags to build
binutils (to support sysroots) and install it, then build gcc?
That's not entirely clear from the question
- Brian
Many apologies for the multiple replies...I was subscribed to the
digest...not the main help maillist and forgot to change the subject
when responding.

Apologies. I'm using the config flags to build GCC with mpc/mpfr/gmp.
I am not building binutils.
I am using the installed GCC's sysroot in the --sysroot option.

ADDENDUM: I should also mention that the GCC/binutils version
installed on device is 4.7.0/2.23.2

The config flags for the current run (which just failed) are:

../gcc-4.7.0/configure --prefix=/usr/gcc --host=arm-linux-androideabi
--build=arm-linux-androideabi --target=arm-linux-androideabi
--enable-ppl=no --enable-ld=no --enable-libquadmath=no
--enable-libada=no --enable-cloog=no --disable-bootstrap
--enable-multilib=no --enable-multiarch=no --enable-nls=no
--disable-dependency-tracking --enable-languages=c,c++
--with-sysroot=/usr/local/sysroot --with-ld=/usr/local/bin/ld
--with-build-time-tools=/usr/local/bin --enable-languages=c,c++
"LIBS=-lc -ldl -lm -lgcc -lstdc++" "CFLAGS=-marm -mandroid -mbionic"
"CXXFLAGS=-mandroid -mbionic" "CPPFLAGS=-mandroid -mbionic"
LDFLAGS=-Wl,--dynamic-linker=/system/bin/linker "LIB_PATHS=/lib
/usr/lib" "SHELL=/system/bin/sh" "CONFIG_SHELL=/system/bin/sh"

Do I need to download the source for binutils and build it as well?
Brian Drummond
2014-09-28 09:52:47 UTC
Permalink
Post by Cyd Haselton
Post by Cyd Haselton
No matter which config flags I use, the build keeps failing with
"/usr/local/bin/ld" this linker is not configured touse sysroots"
I've checked the specs for the ld at that location, and it does
support sysroot.
What am I doing wrong?
First question would be : are you using those config flags to build
binutils (to support sysroots) and install it, then build gcc?
Do I need to download the source for binutils and build it as well?
I can't be certain and I was hoping my dumb question would elicit "of
course" or "no" from the real experts...

But given the way binutils and the compiler have to interoperate, I
think it's likely that you do. That's the normal process when building
crosscompilers (which you aren't) so it may also be when you're
selecting unusual config options (which you are).

Binutils is much faster to build than gcc so it's not a difficult
question to answer for yourself. Naively, I'd feed the same set of
config options to binutils and let it ignore the ones it doesn't need.

Then having a "synchronised" version of ld etc in the same sysroot, you
could eliminate the --with-ld= option pointing at the other one.

If you make progress that way, keep the list informed.

- Brian
Cyd Haselton
2014-09-28 17:14:35 UTC
Permalink
On Sun, Sep 28, 2014 at 4:52 AM, Brian Drummond
Post by Brian Drummond
Post by Cyd Haselton
Post by Cyd Haselton
No matter which config flags I use, the build keeps failing with
"/usr/local/bin/ld" this linker is not configured touse sysroots"
I've checked the specs for the ld at that location, and it does
support sysroot.
What am I doing wrong?
First question would be : are you using those config flags to build
binutils (to support sysroots) and install it, then build gcc?
Do I need to download the source for binutils and build it as well?
I can't be certain and I was hoping my dumb question would elicit "of
course" or "no" from the real experts...
But given the way binutils and the compiler have to interoperate, I
think it's likely that you do. That's the normal process when building
crosscompilers (which you aren't) so it may also be when you're
selecting unusual config options (which you are).
Binutils is much faster to build than gcc so it's not a difficult
question to answer for yourself. Naively, I'd feed the same set of
config options to binutils and let it ignore the ones it doesn't need.
Then having a "synchronised" version of ld etc in the same sysroot, you
could eliminate the --with-ld= option pointing at the other one.
If you make progress that way, keep the list informed.
- Brian
Initially sent this just to Brian, due to gmail's default quick reply settings:
****************************************************
As suggested, I've downloaded source for binutils 2.23.2, unpacked and
symlinked it in the gcc 4.7.0 source dir and re-run configure (minus
the --with-ld=no and --with-ld=/path/to/ld options. I also added the
BIONIC_LIBC #ifdef conditions to getpagesize.c in binutils/libiberty
to move past the error thrown by that file.

However, I'm now getting an error in bfd
in function bfd_ar_hdr_from_filesystem
../../../gcc-4.7.0/binutils/bfd/archive.c:1866:7: error: pointer
targets in passing argument 1 of 'time' differ in signedness
[-Werror-pointer-sign]

This is followed by
/usr/local/sysroot/usr/include/time.h:40:17: note: expected 'time_t
*' but argument is of type 'long unsigned int*'

I vaguely remember having to make some modifications to a source file
when porting GCC 4.8 to android, but it's been a while...I'd have to
dig up prior posts and resurrect an archived VM.

Any ideas before I do just that?

UPDATE: Question above answered; there's a patch available for
bfd/archive.c that involves a cast (?) for the problematic function,
but I've now run into another error in binutils/bucomm.c

..binutils/bucomm.c: In function 'make_tempdir'
..binutils/bucomm.c:532:3: error: implicit declaration of function
'mkdtemp' [-Werror=implicit-function-declaration]
..binutils/bucomm.c:532:3: error: return makes pointer from integer
without a cast [-Werror]

Looks like I'll be digging back into my C handbook. If someone knows
of an existing patch, please save me from doing this.
Cyd Haselton
2014-09-29 17:55:45 UTC
Permalink
Post by Cyd Haselton
On Sun, Sep 28, 2014 at 4:52 AM, Brian Drummond
Post by Brian Drummond
Post by Cyd Haselton
Post by Cyd Haselton
No matter which config flags I use, the build keeps failing with
"/usr/local/bin/ld" this linker is not configured touse sysroots"
I've checked the specs for the ld at that location, and it does
support sysroot.
What am I doing wrong?
First question would be : are you using those config flags to build
binutils (to support sysroots) and install it, then build gcc?
Do I need to download the source for binutils and build it as well?
I can't be certain and I was hoping my dumb question would elicit "of
course" or "no" from the real experts...
But given the way binutils and the compiler have to interoperate, I
think it's likely that you do. That's the normal process when building
crosscompilers (which you aren't) so it may also be when you're
selecting unusual config options (which you are).
Binutils is much faster to build than gcc so it's not a difficult
question to answer for yourself. Naively, I'd feed the same set of
config options to binutils and let it ignore the ones it doesn't need.
Then having a "synchronised" version of ld etc in the same sysroot, you
could eliminate the --with-ld= option pointing at the other one.
If you make progress that way, keep the list informed.
- Brian
****************************************************
As suggested, I've downloaded source for binutils 2.23.2, unpacked and
symlinked it in the gcc 4.7.0 source dir and re-run configure (minus
the --with-ld=no and --with-ld=/path/to/ld options. I also added the
BIONIC_LIBC #ifdef conditions to getpagesize.c in binutils/libiberty
to move past the error thrown by that file.
However, I'm now getting an error in bfd
in function bfd_ar_hdr_from_filesystem
../../../gcc-4.7.0/binutils/bfd/archive.c:1866:7: error: pointer
targets in passing argument 1 of 'time' differ in signedness
[-Werror-pointer-sign]
This is followed by
/usr/local/sysroot/usr/include/time.h:40:17: note: expected 'time_t
*' but argument is of type 'long unsigned int*'
I vaguely remember having to make some modifications to a source file
when porting GCC 4.8 to android, but it's been a while...I'd have to
dig up prior posts and resurrect an archived VM.
Any ideas before I do just that?
UPDATE: Question above answered; there's a patch available for
bfd/archive.c that involves a cast (?) for the problematic function,
but I've now run into another error in binutils/bucomm.c
..binutils/bucomm.c: In function 'make_tempdir'
..binutils/bucomm.c:532:3: error: implicit declaration of function
'mkdtemp' [-Werror=implicit-function-declaration]
..binutils/bucomm.c:532:3: error: return makes pointer from integer
without a cast [-Werror]
Looks like I'll be digging back into my C handbook. If someone knows
of an existing patch, please save me from doing this.
I managed to work through the above errors by making changes to the binutils
config.h file. However I'm back to the same problem with a twist: if I
exclude the --with-sysroot configure option, the header
files...specifically stdio.h included from tsystem.h...can't be found. If I
include the --with-sysroot option, I get the same 'this linker not
configured to use sysroots' error at the same point in the build process.

Any help would be appreciated.

Loading...