Liliana Marie Prikler <liliana.prik...@ist.tugraz.at> writes: > Am Mittwoch, den 03.11.2021, 17:04 -0400 schrieb Mark H Weaver: >> Earlier, I wrote: >> > libwebkit2gtk-4.0.so fails to link on i686-linux, due to an >> > undefined reference to '__mulodi4'. >> >> Here are some relevant links: >> >> https://bugs.webkit.org/show_bug.cgi?id=190208 >> https://trac.webkit.org/changeset/272140/webkit >> https://github.com/android/ndk/issues/506 > This error does not occur when compiling with GCC [1].
Right. As mentioned in the first link above: "This is because clang generates code using the __mulodi4 symbol for __builtin_mul_overflow. But this symbol is available only in compiler-rt, and not in the libgcc runtime used by most Linux distributions of clang." So, one possible solution might be to link with compiler-rt, which is the 'clang-runtime-11' package in Guix. However, it's possible that this might cause other complications. A more conservative approach would be to apply a patch to trunk/Source/WTF/wtf/CheckedArithmetic.h analogous to the one in the second link I cited above, namely this one: https://trac.webkit.org/changeset/272140/webkit However, it would need to be changed slightly. The patch above arranges to avoid using __builtin_mul_overflow on 32-bit ARM systems. We would need to do the same for 32-bit x86 as well. So, where the patch above has this: --8<---------------cut here---------------start------------->8--- /* On Linux with clang, libgcc is usually used instead of compiler-rt, and it does * not provide the __mulodi4 symbol used by clang for __builtin_mul_overflow */ #if COMPILER(GCC) || (COMPILER(CLANG) && !(CPU(ARM) && OS(LINUX))) #define USE_MUL_OVERFLOW 1 #endif --8<---------------cut here---------------end--------------->8--- We would need to change "CPU(ARM)" to "(CPU(ARM) || CPU(XXX))", where XXX is the appropriate symbol for 32-bit x86. Or maybe there's another solution. I won't be able to look at this in the next couple of days, so hopefully someone else can pick this up. > However, now dependant packages fail to link Webkit [2]. We might have > to add GCC 11 to all of them -- or at least to a fair number. I've > verified that gnome-online-accounts builds with GCC 11 added, we might > want to make sure we check the rest of the gnome package as well. I'm not sure about this approach. Maybe it's feasible, but there might be problems if *any* C++ library built using GCC 7 is linked together with WebKitGTK. > On that note, which GCC will be the standard once core-updates-frozen > is merged? If it's not GCC 11 – say GCC 10 – we might want to try to > get Webkit building with that instead, so that at least after the merge > we're clean on that front. The standard compiler on 'core-updates-frozen' is GCC 10. As I wrote elsewhere, I think it's quite likely that these workarounds will not be needed on 'core-updates-frozen'. >> Also, I just noticed that "-mfpmath=sse -msse2" is being passed on >> the compile command line. Historically, we've chosen not to assume >> the availability of SSE or SSE2 on i686-linux, so it would be good to >> inhibit those flags. > This is still true for the GCC build. Could you add the necessary > flags to disable them? I don't know when I'll be able to look into it. It's a busy time for me. Regards, Mark -- Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.