EEVblog® Electronics Community Forum
Products => Computers => Programming => Topic started by: DiTBho on May 26, 2025, 11:37:54 am
-
2025-05-22--21-46-06---2025-05-22--21-59-41 - [ net-libs/webkit-gtk ] - failure - [email protected]/13
spent 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.
2025-05-23--23-22-29---2025-05-24--19-40-36 - [ net-libs/webkit-gtk ] - success - [email protected]/13
2025-05-25--14-58-57---2025-05-26--11-41-30 - [ dev-util/geany-plugins ] - success - [email protected]/13
net-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).
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 detection :o :o :o
It's a problem with the building system is 64-bit profiled, and you are working in a chroot-ed 32-bit rootfs.
(Catalyst here ...)
# uname -m
x86_64 <------------ wrong, the chroot-ed rootfs is 32bit!
How to fix? This way!
# setarch linux32
# uname -m
i686
----------------
# uname -m
ppc64 <------------ wrong, the chroot-ed rootfs is 32bit!
# setarch linux32
# uname -m
ppc
# uname -m
mips64 <------------ wrong, the chroot-ed rootfs is 32bit!
# setarch linux32
# uname -m
mips
(HPPA2 doesn't have a working 64bit userland, so ... it's not affected
I don't know about ARM)
-
Anyway, 5min celebration time!
I can finally use geany :scared:
all's well that ends well :D
-
just wonder what CMAKE_SYSTEM_PROCESSOR shows on your environment. Could you add something like
message(STATUS "CMAKE_SYSTEM_PROCESSOR: \"${CMAKE_SYSTEM_PROCESSOR}\"")
to your CMakeLists.txt?
-
the check should be done on the libc, with an additional problem with multi library libc, hybrid 32 and 64bit
-
That's by design.
uname -m is not supposed to return the userspace libraries' and executables' build architecture. It returns hardware arch (or probably actually kernel build arch, not sure):
-m, --machine
print the machine hardware name
Your chrooted environment may be 32-bit, but the machine (or kernel) is still 64-bit.
-
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 detection :o :o :o
What'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.
-
That's by design.
uname -m is not supposed to return the userspace libraries' and executables' build architecture. It returns hardware arch (or probably actually kernel build arch, not sure):
-m, --machine
print the machine hardware name
Your chrooted environment may be 32-bit, but the machine (or kernel) is still 64-bit.
that'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.
-
What's "proper" detection?
I have no idea, but "uname -m" is definitely NOT good because it fails.
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.
As "workaround", I put "setarch" inside /etc/profile
Since Catalyst calls "source /etc/profile" as the very first thing when it chroots
This allows me to decouple the stage from the guest system without having to manually intervene
Obviously 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 multiprofiled
Not 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 yet
I think it's not a simple matter :-//
-
That's by design.
uname -m is not supposed to return the userspace libraries' and executables' build architecture. It returns hardware arch (or probably actually kernel build arch, not sure):
-m, --machine
print the machine hardware name
Your chrooted environment may be 32-bit, but the machine (or kernel) is still 64-bit.
that'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.
Ah 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.
-
# uname -m
x86_64 <------------ wrong, the chroot-ed rootfs is 32bit!
You 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 /proc
So 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.
-
So you should have /proc mapped into chroot
devs="dev proc sys dev/shm dev/pts ...
for dev in $devs
do
I didn't wrote but catalyst "binds" dev (mount -o bind) before invoking chroot