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 -O2 conftest.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!
On Thu, Aug 18, 2016 at 12:21 PM, stimits@comcast.net wrote:
configure:14589: checking for library containing dlopen configure:14620: gcc -o conftest -g -O2 conftest.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
...
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/%22%7C /* 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!
On Thu, Aug 18, 2016 at 7:50 PM, stimits@comcast.net 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
/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.
The whole cross-architecture situation complicates things...in particular I'm wondering "which" binutils (host versus target sysroot) we are talking about? I'm trying to figure out if the missing binutils is from the armhf sysroot or from the x86_64 host I'm building on. There is an armhf binutils-dev package on the armhf build sysroot, and binutils-dev package on the aarch64 build sysroot (both the armhf and aarch64 sysroots include everything needed to build, link, and develop for their particular architecuture on the systems they were cloned from).
The x86_64 host has native packages for everything, but in a few cases has some cross-architecture packages. "as" is missing according to the config.log, but the assembler is present for native x86_64 and aarch64 cross-assembling. Would it be correct that the missing packages are cross-architecture armhf needing to be installed on the x86_64 host, and that build sysroot is unrelated to the missing package? It seems I probably need x86_64 host binutils cross-assembling to armhf.
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
I did create an empty tmp.c in the gcc directory, and it seems "as" just doesn't exist according the test. It isn't a case of seeing "as" being called and complaining about something, the case is that the shell script found no assembler at all (there are assemblers on this host, just not armhf, so presumably I have to conclude that this supports the idea of needing a cross-binutils which is armhf on my x86_64 host, and not just in build sysroot).
If I need to build cross-binutils and such, is there any reason to not use pre-compiled binaries from Linaro 5.2 or 5.3 tool chains?
Thanks!
On Sat, Aug 20, 2016 at 7:38 PM, stimits@comcast.net wrote:
The whole cross-architecture situation complicates things...in particular I'm wondering "which" binutils (host versus target sysroot) we are talking about? I'm trying to figure out if the missing binutils is from the armhf sysroot or from the x86_64 host I'm building on. There is an armhf binutils-dev package on the armhf build sysroot, and binutils-dev package on the aarch64 build sysroot (both the armhf and aarch64 sysroots include everything needed to build, link, and develop for their particular architecuture on the systems they were cloned from).
The assembler in the sysroot is an armhf binary, which won't run on the x86_64 host (well, maybe with QEMU but that isn't the right approach). You need a x86_64 cross to armhf binutils on the host. You apparently don't have one.
Normal process is to configure/build/install binutils first, and then configure/build/install gcc, using the same configure options for binutils and gcc, in particular prefix and sysroot. A cross gcc can't be built without a cross binutils. A cross binutils doesn't have dependencies on anything else. So binutlis has to be built first.
The x86_64 host has native packages for everything, but in a few cases has some cross-architecture packages. "as" is missing according to the config.log, but the assembler is present for native x86_64 and aarch64 cross-assembling. Would it be correct that the missing packages are cross-architecture armhf needing to be installed on the x86_64 host, and that build sysroot is unrelated to the missing package? It seems I probably need x86_64 host binutils cross-assembling to armhf.
Yes, if you are on a debian/ubuntu host, then installing the gcc-arm-linux-gnueabihf package might be sufficient to get the cross binutils that you need.
If I need to build cross-binutils and such, is there any reason to not use pre-compiled binaries from Linaro 5.2 or 5.3 tool chains?
You could try this, but it might end up a bit awkward. GCC needs to be able to find the assembler both at build time, and at run time. The normal way this works is that binutils and gcc must be configured with the same prefix. If you use an assembler from a linaro toolchain, it might not be the same prefix. Perhaps you can arrange to install your gcc build over top the linaro binutils binaries, so that the prefix can be the same.
Yes, building cross compilers is complicated. It takes some time to learn how to do it.
Jim
linaro-toolchain@lists.linaro.org