sniffing "uname -m" instead of doing proper detection, is a bad idea - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: May 26, 2025, 11:37:54 am
content: Code:2025-05-22--21-46-06---2025-05-22--21-59-41 - [ net-libs/webkit-gtk ] - failure - DiTBho@dev2.38/13spent 2 days compling this bloody stuff, as it's a dependency for dev-util/geany-plugins, which is required to make dev-util/geany able to operate with MarkDown documents.Code:2025-05-23--23-22-29---2025-05-24--19-40-36 - [ net-libs/webkit-gtk ] - success - DiTBho@dev2.38/132025-05-25--14-58-57---2025-05-26--11-41-30 - [ dev-util/geany-plugins ] - success - DiTBho@dev2.38/13net-libs/webkit-gtk is a big and complex package; it uses C++ and consumes a lot of resources (up to 400 Mbyte of stack, lot of cpu cycles), but it always failed with this error, which does not depend on the available memory (I allocated 8Gbyte).Code:No magic values found. Skipping offsets extractor file generation.that I didn't understand what he was referring to.Until I looked at all the logs, and discovered that there is a bug in that the build system is apparently sniffing `uname -m`Instead of doing proper detectionIt's a problem with the building system is 64-bit profiled, and you are working in a chroot-ed 32-bit rootfs.(Catalyst here ...)Code:# uname -mx86_64 <------------ wrong, the chroot-ed rootfs is 32bit!How to fix? This way!Code:# setarch linux32# uname -mi686----------------Code:# uname -mppc64 <------------ wrong, the chroot-ed rootfs is 32bit!Code:# setarch linux32# uname -mppcCode:# uname -mmips64 <------------ wrong, the chroot-ed rootfs is 32bit!Code:# setarch linux32# uname -mmips(HPPA2 doesn't have a working 64bit userland, so ... it's not affectedI don't know about ARM)

author: DiTBho
author_rank: Super Contributor
timestamp: May 26, 2025, 11:39:47 am
content: Anyway, 5min celebration time!I can finally use geanyall's well that ends well

author: radiolistener
author_rank: Super Contributor
timestamp: May 26, 2025, 12:22:59 pm
content: just wonder what CMAKE_SYSTEM_PROCESSOR shows on your environment. Could you add something likeCode:message(STATUS "CMAKE_SYSTEM_PROCESSOR: \"${CMAKE_SYSTEM_PROCESSOR}\"")to your CMakeLists.txt?

author: DiTBho
author_rank: Super Contributor
timestamp: May 27, 2025, 12:04:02 pm
content: the check should be done on the libc, with an additional problem with multi library libc, hybrid 32 and 64bit

author: shapirus
author_rank: Super Contributor
timestamp: May 27, 2025, 02:44:09 pm
content: That's by design.uname -mis not supposed to return the userspace libraries' and executables' build architecture. It returns hardware arch (or probably actually kernel build arch, not sure):-m, --machineprint the machine hardware nameYour chrooted environment may be 32-bit, but the machine (or kernel) is still 64-bit.

author: ejeffrey
author_rank: Super Contributor
timestamp: May 27, 2025, 06:01:02 pm
content: Quote from: DiTBho on May 26, 2025, 11:37:54 amWhat's "proper" detection? Most build systems assume you will build for the current platform architecture by default unless you explicitly override that and provide a target architecture. Not having the correct build tools and libraries for the auto-detected platform could equally well be considered a user error.Some projects won't have a build environment that lets you specify a target architecture which is annoying but understandable. That's essentially the type of issue setarch is for.I'm not sure why libc is special and you should detect based on that. As you have said, multiple versions of libc could be present. Not only that, libc might have both 32 and 64-bit versions while other dependencies only have one or the other. It's not the job of the build system to track down every dependency for all possible platforms and pick the best one.

author: DiTBho
author_rank: Super Contributor
timestamp: May 27, 2025, 10:11:16 pm
content: Quote from: shapirus on May 27, 2025, 02:44:09 pmthat's precisely the bug I found.I neither wrote the net-libs/webkit-gtk package, nor its (gentoo) ebuild.I simply found a workaround to compile.

author: DiTBho
author_rank: Super Contributor
timestamp: May 27, 2025, 10:19:25 pm
content: Quote from: ejeffrey on May 27, 2025, 06:01:02 pmI have no idea, but "uname -m" is definitely NOT good because it fails.Quote from: ejeffrey on May 27, 2025, 06:01:02 pmAs "workaround", I put "setarch" inside /etc/profileSince Catalyst calls "source /etc/profile" as the very first thing when it chrootsThis allows me to decouple the stage from the guest system without having to manually interveneObviously it is put in /etc/profile when the profile is created, so ...... there is a "minimum of coherence"at least for { x86, ppc, mips } if they are not multiprofiledNot optimal, but hey? I need a way to move forward.I just saw that a bug was reported around ~2021, it hasn't been fixed yetI think it's not a simple matter

author: shapirus
author_rank: Super Contributor
timestamp: May 27, 2025, 10:22:24 pm
content: Quote from: DiTBho on May 27, 2025, 10:11:16 pmAh I see. I'm not sure it can be considered a bug exactly... Looks more like a missing feature to me. But yes I see what you mean.

author: paulca
author_rank: Super Contributor
timestamp: July 11, 2025, 08:38:42 am
content: Quote from: DiTBho on May 26, 2025, 11:37:54 amYou need to use a cross compiler. I went though this with basic "i586 on i686". uname will not help you.Its complex. Unix compiles take a lot from their parents.uname I believe uname reads from /procSo you should have /proc mapped into chroot. Without doing so will cause more chaos. You'll need minimal /dev /sys /proc pseudo FS's.As these all come from your host, the compile will be for that host.If you want to cross compile you need a special setup for cross compiling.chroot will not help with native compiles being native compiles.

author: DiTBho
author_rank: Super Contributor
timestamp: July 14, 2025, 10:02:10 am
content: Quote from: paulca on July 11, 2025, 08:38:42 amdevs="dev proc sys dev/shm dev/pts ...for dev in $devsdoI didn't wrote but catalyst "binds" dev (mount -o bind) before invoking chroot