Summary: | net-libs/webkit-gtk-2.24.1 - /usr/bin/ruby24 .../work/webkitgtk-2.24.1/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb .../work/webkit-gtk-2.24.1_build/DerivedSources/JavaScriptCore/LLIntDesiredOffsets.h ARM64: FAILED: ... | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dion Moult <dion> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Dion Moult
2019-05-14 10:30:39 UTC
Odd, by my reading there should be magic values for ARM64 just fine. I should mention that this is Gentoo running in a chroot under a Samsung Galaxy S7 android. Could the chroot have anything to do with it? I haven't heard of the concept of magic values, how can I do tests to further debug if they exist? I'm slightly confused here, as your CPU is indeed 64-bit capable, but you are using a 32-bit 'march' setting, and I presume a 32-bit profile... If you have been running 32-bit successfully for a period of time, I suggest you stick with it, unless you want to make a clean start with 64-bit, as you will get into a mess should you try to mix both. It looks like the ninja config is getting confused with CPU types here, and you may need to force it one way or the other if it's mis-detecting something. Sorry for the bugspam - I just encountered exactly this on an i686 chroot on an x86_64 buildhost. There is a real bug here in that the build system is apparently useragent-sniffing `uname -a` instead of doing proper detection (_this_ upstream really ought to know better...), anyway for others stumbling across this via googling in future, the fix is to wrap the chroot command with `linux32`. |