| Summary: | Building libtool_cross fails when using external cross-toolchain for 32 bit on 64 bit host | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Other YP Layers | Reporter: | Laszlo Papp <lpapp> | ||||
| Component: | layers | Assignee: | Christopher Larson <kergoth> | ||||
| Status: | RESOLVED MOVED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | kergoth, poky.bs.watcher, poky.watcher, ross.burton, sgw | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.5 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
|
Description
Laszlo Papp
2013-07-26 02:47:06 UTC
Looks like a bug in the meta-sourcery layer maybe? Arch does not do any package renaming for the new bleeding edge version: https://aur.archlinux.org/packages/ar/arm-none-linux-gnueabi/PKGBUILD I suspect that the problem boils down to the fact that MG has not tested meta-sourcery with the latest toolchain. This is the libc version that should be found: /usr/arm-none-linux-gnueabi/libc/lib/libc.so.6 lrwxrwxrwx 1 root root 12 Apr 30 10:22 /usr/arm-none-linux-gnueabi/libc/lib/libc.so.6 -> libc-2.17.so However, meta-sourcery seems to expect this prefix: ERROR: Unable to populate toolchain binary symlinks in /usr/arm-none-linux-gnueabi/bin/arm-poky-linux-gnueabi-* ERROR: Execution of event handler 'toolchain_metadata_setup' failed That is why I cannot use EXTERNAL_TOOLCHAIN = "/usr/arm-none-linux-gnueabi" because the binaries are called like this in there: ls /usr/arm-none-linux-gnueabi/bin/ ar as c++ g++ gcc ld nm objcopy objdump ranlib README.txt strip Note, how the prefix is missing. Instead, I have been forced to use /usr/bin/arm-none-linux-gnueabi-gcc, but then the wrong linker will be found. Do you have any workaround for this? I wonder if the workaround is just the override the prefix target with zero. I believe that could work with oe-core, but cannot be sure about the meta-sourcery layer. I need some documentation from the MG guys for this, even if it is inside meta-sourcery. See the upstream tarball content as well just to avoid the Arch blaming game: tar tvf arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 | grep gcc$ | grep -v doc -rwxr-xr-x root/root 503256 2013-04-30 10:51 arm-2013.05/arm-none-linux-gnueabi/bin/gcc -rwxr-xr-x root/root 503256 2013-04-30 10:51 arm-2013.05/bin/arm-none-linux-gnueabi-gcc hrwxr-xr-x root/root 0 2013-04-30 10:51 arm-2013.05/bin/arm-none-linux-gnueabi-gcc-4.7.3 link to arm-2013.05/bin/arm-none-linux-gnueabi-gcc Grep for libc.so.6 as well: tar tvf arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 | grep libc.so.6 lrwxrwxrwx root/root 0 2013-04-30 10:22 arm-2013.05/arm-none-linux-gnueabi/libc/lib/libc.so.6 -> libc-2.17.so lrwxrwxrwx root/root 0 2013-04-30 10:26 arm-2013.05/arm-none-linux-gnueabi/libc/armv4t/lib/libc.so.6 -> libc-2.17.so lrwxrwxrwx root/root 0 2013-04-30 10:31 arm-2013.05/arm-none-linux-gnueabi/libc/thumb2/lib/libc.so.6 -> libc-2.17.so You're incorrect. We use meta-sourcery with every version from 2009.01 up to *unreleased* toolchains we get internally before they even go public. We do all our builds today with the 2013.05 sourcery toolchains. Using "EXTERNAL_TOOLCHAIN = "/usr/arm-none-linux-gnueabi" " is completely invalid. As I already explain in the meta-sourcery readme, oe/yocto builds need to be able to run non-prefixed native binaries for the host machine. If 'gcc' is arm, then it's impossible to run 'gcc' for x86 anymore. You need to let it run ${TARGET_PREFIX}gcc, not gcc. We will *never* support a configuration in which 'gcc' is for the target.
Your comment seems to suggest that to me you have not bothered to read my post carefully here and in the other issue either. Please do that. (In reply to comment #2) > I wonder if the workaround is just the override the prefix target with zero. > I believe that could work with oe-core, but cannot be sure about the > meta-sourcery layer. I need some documentation from the MG guys for this, > even if it is inside meta-sourcery. This comment shows that you didn't understand the fact that using non-prefixed binaries will not work, and that clearing TARGET_PREFIX will break builds of native recipes, which is what my previous comment explained. It's not unreasonable to explain something you've indicated through your comments you don't understand. I do intend to look into the linking problem, however. It is in the very beginning of the build configuration: EXTERNAL_TOOLCHAIN = "/usr" Which is exactly why I tried everything that I had in my mind. /usr/arm... was not the main point of this report at all. The main point has been /usr as you can see in the configuration. I summarized it for you. So, can we get please some help now with fixing that? At a guess, it may be the use of the external toolchain unpacked to a standard path rather than being self contained which is breaking assumptions by the external toolchain. That's a configuration I've never personally tested. As I mentioned, I use meta-sourcery with 2013.05 every day, so I'm guessing its the location which is problematic, as the relative path it's using is climbing out to /lib, which is obviously a problem. I'd actually be rather surprised if your external toolchain in that location works even outside of Yocto. Would it be possible to do a hello, world compile test on the use of the external toolchain outside of oe/yocto context, to isolate the problem? Not for now as I am not from home where this issue happens. Note, we still use the old toolchain at the company. Perhaps, you could install it to this location to try yourself if you can get there earlier than me home at some point at the weekend? By the way, a couple of days ago I suggested /opt in here to the author under the name of "djszapi". https://aur.archlinux.org/packages/arm-none-linux-gnueabi/ Would that be an acceptable change from the Arch unofficial package maintainer or you have a better suggestion for the remote future? echo "int main(void) { return 0; }" > hello.c && /usr/bin/arm-none-linux-gnueabi-gcc hello.c
-> works fine, fwiw.
Thanks for testing, I'm currently attempting to reproduce the problem locally. Interesting data point: installed the pro version of the 2013.05 toolchain to /usr in a fresh chroot, set EXTERNAL_TOOLCHAIN = "/usr", and successfully built most of a core-image-minimal, so got past this error. It seems that it's either specific to the lite toolchain (testing that next), or it's not seen with ubuntu and I'll have to fire up an arch chroot. This setup succeeded, but since it is not what the archlinux package does, it should still be fixed: bitbake core-image-minimal WARNING: Host distribution "arch-rolling" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Loading cache: 100% |##################################################################################################################################################################| ETA: 00:00:00 Loaded 1176 entries from dependency cache. Build Configuration: BB_VERSION = "1.19.1" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "arch-rolling" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "qemuarm" DISTRO = "poky" DISTRO_VERSION = "1.4+snapshot-20130727" TUNE_FEATURES = "armv5 thumb dsp" TARGET_FPU = "soft" CSL_VER_MAIN = "2013.05-24" EXTERNAL_TOOLCHAIN = "/usr/local/arm-2013.05" meta-sourcery = "master:68ef23ab753467afc46947701e3809655aeea2e3" meta meta-yocto meta-yocto-bsp = "master:67864ca79da08df752487a3a4e1a975546da123d" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 1617 tasks of which 1613 didn't need to be rerun and all succeeded. Summary: There was 1 WARNING message shown. ============================================ config files were the same. Moved to meta-sourcery tracker: https://github.com/MentorEmbedded/meta-sourcery/issues/18. Ok, thanks. |