gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question
Hi,
In a previous thread some sysroot issues were resolved, and I am able to build
cross-compilers under gcc-linaro-snapshot-6.1-2016.07 for languages c, c++, and
objc. My sysroot consisted of a loopback mounted dd copy of an Ubuntu 14.04
file system for aarch64. That particular file system runs on a quad core
Cortex-A57, and is fully capable of compiling many different types of software
(the file system is set up for development). The successful configuration was
like this (configuration and compile was from an independent directory not in
the source tree):
export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export
TRIPLET=aarch64-linux-gnuexport CLONE=/usr/local/sysroot/${TRIPLET}export
VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=arm64
${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID}
--target=${TRIPLET} \ --with-build-sysroot=${CLONE} \
--enable-languages=c,c++,objc \ --with-sysroot=/
Now I also need armhf (I must support both 32-bit and 64-bit), so I'm trying to
figure out host and sysroot differences (I have been unable to get armhf to
compile). The configuration is basically this variation of the above, plus some
sysroot additional support:
export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export
TRIPLET=arm-linux-gnueabihfexport CLONE=/usr/local/sysroot/${TRIPLET}export
VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=armhf ${SRC}/configure
--prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \
--with-build-sysroot=${CLONE} \ --enable-languages=c \ --with-sysroot=/
Note that for testing purposes I tried to compile only languages of c, c++, and
objc, each one at a time instead of together. Errors do not differ in any way
for picking of any of those three languages. I also have a complete Ubuntu
14.04 file system for armhf which is fully equipped for building of each of
those languages, and is perhaps in some ways more complete as a development
environment than the previously successful aarch64 file system (the sysroot
runs on a quad core Cortex-A15). I tried this purely armhf file system as the
sysroot to rule out incorrect multiarch support, and the error did not change.
I am guessing the issue is not the sysroot, but I wanted to verify this since
there may be other requirements for armhf instead of aarch64.
I am at a loss though to explain why the host would be at issue since it
appears all prerequisites were met and I had success with aarch64.
The details of the error seem to always occur in libcc1 build. I see this in
the libcc1/config.log as the failure regardless of sysroot or supported
language, and only while building for armhf:
configure:14569: checking for -rdynamicconfigure:14579: result:
yesconfigure:14589: checking for library containing dlopenconfigure:14620: gcc
-o conftest -g -O2conftest.c >&5/tmp/ccyhVkpp.o: In function
`main':/home/build/linaro/objdir/libcc1/conftest.c:38: undefined reference to
`dlopen'collect2: error: ld returned 1 exit statusconfigure:14620: $? =
1configure: failed program was:| /* confdefs.h */| #define PACKAGE_NAME
"libcc1"| #define PACKAGE_TARNAME "libcc1"| #define PACKAGE_VERSION
"version-unused"| #define PACKAGE_STRING "libcc1 version-unused"| #define
PACKAGE_BUGREPORT ""| #define PACKAGE_URL ""| #define STDC_HEADERS 1| #define
HAVE_SYS_TYPES_H 1| #define HAVE_SYS_STAT_H 1| #define HAVE_STDLIB_H 1| #define
HAVE_STRING_H 1| #define HAVE_MEMORY_H 1| #define HAVE_STRINGS_H 1| #define
HAVE_INTTYPES_H 1| #define HAVE_STDINT_H 1| #define HAVE_UNISTD_H 1| #define
__EXTENSIONS__ 1| #define _ALL_SOURCE 1| #define _GNU_SOURCE 1| #define
_POSIX_PTHREAD_SEMANTICS 1| #define _TANDEM_SOURCE 1| #define HAVE_DLFCN_H 1|
#define LT_OBJDIR ".libs/"| #define HAVE_DECL_BASENAME 1| /* end confdefs.h. */
Are there different host requirements when building armhf versus aarch64 which
might explain why dlopen is not found? FYI, both development and other support
for dlopen exists already on the system, so the failure to find dlopen is not
for lack of host support (related dlopen files all seem to be present on all
tested sysroots as well, both as armhf and aarch64). Is this a sysroot issue, a
host issue, or a configure issue?
Thanks!
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question
On Thu, Aug 18, 2016 at 12:21 PM, wrote: > configure:14589: checking for library containing dlopen > configure:14620: gcc -o conftest -g -O2conftest.c >&5 > /tmp/ccyhVkpp.o: In function `main': > /home/build/linaro/objdir/libcc1/conftest.c:38: undefined reference to > `dlopen' > collect2: error: ld returned 1 exit status > configure:14620: $? = 1 This is normal. Configure does two link tests when checking for dlopen. The first one is just "gcc conftest.c" and the second one is "gcc conftest.c -dl". It is expected that the first link will fail, and the second link will succeed. The failure of the first link is ignored because the second one succeeded. After the second link, you will see a "result: -ldl" line which means the check for dlopen did succeed and the result is that -ldl is required. If your build failed, the real failure is elsewhere. Jim ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question
...
> This is normal. Configure does two link tests when checking for> dlopen. The
> first one is just "gcc conftest.c" and the second one is> "gcc conftest.c
> -dl". It is expected that the first link will fail,> and the second link will
> succeed. The failure of the first link is> ignored because the second one
> succeeded. After the second link, you> will see a "result: -ldl" line which
> means the check for dlopen did> succeed and the result is that -ldl is
> required.
>
> If your build failed, the real failure is elsewhere.
>
> Jim
...
I see there was a second dlopen and this did indeed succeed; compile
successfully bulds and leaves the libcc1 directory. Following this I see build
fail while compiling in subdirectory "arm-linux-gnueabihf/libgcc". The command
line "make" shows this failure i libgcc:
checking for arm-linux-gnueabihf-gcc... /home/build/linaro/32bit/./gcc/xgcc
-B/home/build/linaro/32bit/./gcc/
-B/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/bin/
-B/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/lib/
-isystem
/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/include
-isystem
/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/sys-include
--sysroot=/usr/local/sysroot/arm-linux-gnueabihf checking for suffix of
object files... configure: error: in
`/home/build/linaro/32bit/arm-linux-gnueabihf/libgcc':configure: error: cannot
compute suffix of object files: cannot compileSee `config.log' for more
details.Makefile:11325: recipe for target 'configure-target-libgcc'
failedmake[1]: *** [configure-target-libgcc] Error 1
The libgcc config.log shows what seems to be the implication of needing to look
at yet a different config.log, but the message does not provide any indication
of what really went wrong:
configure:3653: checking for suffix of object filesconfigure:3675:
/home/build/linaro/32bit/./gcc/xgcc -B/home/build/linaro/32bit/./gcc/
-B/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/bin/
-B/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/lib/
-isystem
/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/include
-isystem
/usr/local/arm-linux-gnueabihf/gcc-linaro-6.1-2016.07/arm-linux-gnueabihf/sys-include
--sysroot=/usr/local/sysroot/arm-linux-gnueabihf -c -g -O2 conftest.c
>&5/home/build/linaro/32bit/./gcc/as: line 106: exec: -m: invalid optionexec:
usage: exec [-cl] [-a name] [command [arguments ...]] [redirection
...]configure:3679: $? = 1
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:3693: error: in
`/home/build/linaro/32bit/arm-linux-gnueabihf/libgcc':configure:3696: error:
cannot compute suffix of object files: cannot compileSee `config.log' for more
details.
Which config.log is the message referring to? I did not see anything which
would indicate which subdirectory config.log would be relevant (and I see no
other errors which are obvious). Since the same host PC is building the same
Linaro software with config being almost identical to the aarch64 version, it
seems like the armhf sysroot has to be involved, but I've seen nothing to
narrow this down. Are there any suggestions on where to look or a hint of the
true cause of the armhf build error?
Thanks!___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question
On Thu, Aug 18, 2016 at 7:50 PM, wrote: > /home/build/linaro/32bit/./gcc/as: line 106: exec: -m: invalid option > exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection > ...] The libgcc config.log is the right one to look at. The error is here, when gcc calls the assembler, the assembler gives an error. So something is wrong here. You need to configure, build, and install binutils before you configure and build gcc, using the same configure options for binutils and gcc. To look at this a bit more, you can cd into the gcc build dir and try touch tmp.c ./xgcc -B./ -v tmp.c which will show the options passed to the assembler, and what assembler binary is being used. You probably also want to look at the as file in the gcc build dir, which should be a shell script pointing at the installed assembler. This shell script is created at gcc configure time. Jim ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
