| Summary: | Non-obvious failure when NO32LIBS=0 but 32-bit toolchain is broken | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Laszlo Papp <lpapp> |
| Component: | core | Assignee: | Seebs <seebs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher, net147, ross.burton |
| 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) | |
|
Description
Laszlo Papp
2013-07-25 20:06:44 UTC
Is libpseudo really a blocker for building a distribution? I mean, there are so many distributions out there without it embedded into the core process, and they work. I believe the rationale would be to tell libpseudo to look into /usr/lib32 and /lib32 rather than /usr/lib and /lib. Is that possible somehow? It looks like you need to set EXTERNAL_TOOLCHAIN to the path of your Sourcery cross compiler toolchain in conf/local.conf. See usage & instuctions here: https://github.com/MentorEmbedded/meta-sourcery As you can see in the build configuration output, it is already set. This is a red herring. All the warnings about skipping incompatible libraries are irrelevant. You can easily verify that these warnings occur normally when specifying an incompatible (and thus irrelevant) directory with -L, and they have no effect, because -L adds on to the basic compiler search path. $ gcc -L/usr/lib32 -m64 -o h hello.c /usr/bin/ld: skipping incompatible /usr/lib32/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib32/libc.a when searching for -lc This link *succeeded*. So the real problem isn't all the incompatible stuff. It's the THIRD line: | /bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread | /bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread | /bin/ld: cannot find -lpthread If there were a suitable -lpthread wherever the 32-bit compiler looks for libraries, it wouldn't produce that third line. The fact is, we run on many machines which use /usr/lib32 for 32-bit libraries, and /usr/lib for 64-bit libraries, and they all work. Well, that is. They all work *when the development packages for those libraries are also installed*, not just the 32-bit runtimes. No no, it is not related in any way to -L/usb/lib32 as I tested. Besides, you apparently do not know Archlinux. As for what is relevant to you is the fact that Archlinux does not differentiate between development packages and runtime as you seem to think. Not to mention, pthread is coming with glibc32 if which was not installed, there would be a lot more trouble to it. I have just double checked again, and "libpthread" is definitely a red herring. Actually, the offending lines were what I suggested, and they can be fixed apparently by intalling gcc-multilib on Arch. In any case, the tools should warn me if I do not have something necessary installed rather than leaving us in the dark. That would have probably saved a lot of time for at least 3-4 people today... Anyway, it is 03:30 am'ish here, and I should have better than things to do than Yocto thingie, so see you tomorrow, good night. Please do not close the bug again, the conclusion is that the error diagnostics has to be improved. Let me know if you have anything to test for that. Please check 4921 for another blocker failure. :( That's really a pretty solidly different bug. You spent several hours yesterday insisting that the compiler was looking in the wrong directory. It wasn't. Arch Linux's wiki says to install gcc-multilib to build both 64-bit and 32-bit code. This bug report was on the Yocto build system "looking in the wrong directory" and not correctly handling systems which use lib32. That doesn't happen, and is not the problem. The concern that the system does not give useful diagnostics in the case where the host system is misconfigured and can't build 32-bit binaries is a legitimate concern, but it's not the same as the issue originally reported here. Leaving this open, but documentation bugs like this are usually a lower priority, as we sort of assume the user can discern what's happening from the compiler error messges. Yet, you could not without a _full_ day investigation of you, both. Good luck to the next person having the same issue. It is not necessarily a documentation bug. I wonder if it was possible to give a descriptive warning or even error on the command line. FWIW, stock oe-core doesn't have this problem. meta-sourcery sets NO32LIBS[1] as it only has a 32-bit toolchain. [1] https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc I attempted to replicate this on my Debian box (64-bit host, no 32-bit toolchain) and noticed that the log has the following warning right at the top: Log data follows: | DEBUG: Executing shell function do_compile | WARNING: Can't find stubs-32.h, but usually need it to build 32-bit libpseudo. | If the build fails, install 32-bit developer packages. | If you are using 32-bit binaries, the 32-bit libpseudo is NOT optional. Laszlo, would you be able to remove gcc-multilib and rebuild pseudo-native to see if this warning is in the log.do_compile? If it isn't then we could extend the sanity test, otherwise maybe the notice needs to be more obvious (repeated at the end on failure, for example). Thanks. Unfortunately, my current tasks are not related to Yocto, so it is unlikely I can put energy into helping with this. Apologies for that. Patch series to repeat the warning at the end of the log just sent, so it's visible on screen in the summary. If it's discovered that the basic sanity test in maybe_make32() is passing in the configuration that caused this bug the test can be extended. Merged into oe-core in 51950fcbe4b98bdbb8b3dde88a8729e540d9609f. |