Created attachment 330661 [details] Build error TagBitsWasm is only defined in Source/JavaScriptCore/runtime/JSCJSValue.h inside `#elif USE(JSVALUE64)` block. On 32-bit OS the block is ignored leaving TagBitsWasm undefined.
Did you manually turn on ENABLE_WEBASSEMBLY? That should turned off on 32-bit, and we do have code in WebKitFeatures.cmake to ensure that it's only turned on for x86_64 and aarch64. If you did not manually turn it on, then we have a bug in our build system and need to figure out why that happened, but I suspect you manually turned it on. The hidden options (CMake advanced options) are not supported and likely to result in build failures. The WebAssembly implementation does rely on a 64-bit processor, so it simply won't work on 32-bit... sorry. Same for the FTL JIT tier, which it depends on.
Thanks for the fast reply. Are there plans to make webassembly work for 32-bit builds? It appeared to be an issue with my build environment. I have 32-bit userspace and 64-bit kernel. All the binaries (both existing and generated) are 32-bit while `uname -m` gives x86_64 and cmake sets *_SYSTEM_PROCESSOR to x86_64 in CMakeFiles/3.7.2/CMakeSystem.cmake. Build succeeds if I set *FLAGS for g-ir-scanner: --- webkitgtk-2.18.4.orig/Source/WebKit/PlatformGTK.cmake 2017-10-16 13:49:22.000000000 +0300 +++ webkitgtk-2.18.4/Source/WebKit/PlatformGTK.cmake 2018-01-08 15:59:23.044327352 +0300 @@ -1126,7 +1126,7 @@ add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir DEPENDS WebKit2 DEPENDS ${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir - COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=-Wno-deprecated-declarations LDFLAGS= + COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=${CMAKE_C_FLAGS}\ -Wno-deprecated-declarations LDFLAGS=${CMAKE_SHARED_LINKER_FLAGS} ${LOADER_LIBRARY_PATH_VAR}="${INTROSPECTION_ADDITIONAL_LIBRARY_PATH}" ${INTROSPECTION_SCANNER} --quiet @@ -1169,8 +1169,8 @@ add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/WebKit2WebExtension-${WEBKITGTK_API_VERSION}.gir DEPENDS ${CMAKE_BINARY_DIR}/JavaScriptCore-${WEBKITGTK_API_VERSION}.gir DEPENDS ${CMAKE_BINARY_DIR}/WebKit2-${WEBKITGTK_API_VERSION}.gir - COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=-Wno-deprecated-declarations - LDFLAGS="${INTROSPECTION_ADDITIONAL_LDFLAGS}" + COMMAND CC=${CMAKE_C_COMPILER} CFLAGS=${CMAKE_C_FLAGS}\ -Wno-deprecated-declarations + LDFLAGS=${CMAKE_SHARED_LINKER_FLAGS}\ ${INTROSPECTION_ADDITIONAL_LDFLAGS} ${LOADER_LIBRARY_PATH_VAR}="${INTROSPECTION_ADDITIONAL_LIBRARY_PATH}" ${INTROSPECTION_SCANNER} --quiet then explicitly pass -DENABLE_WEBASSEMBLY=OFF to cmake, and run $ sed -i "\'_SYSTEM_PROCESSOR's'x86_64'i686'" CMakeFiles/*/CMakeSystem.cmake after cmake is run (and before running make). An alternative way to fix the issue would be using `setarch i686` (I did not test it though).
... and, no, I did not manually turn on ENABLE_WEBASSEMBLY when having the issue.
(In reply to Vadim from comment #2) > Thanks for the fast reply. > > Are there plans to make webassembly work for 32-bit builds? Definitely not, sorry. It's unclear if even the baseline JIT will remain supported on 32-bit. > It appeared to be an issue with my build environment. I have 32-bit > userspace and 64-bit kernel. Wow! > All the binaries (both existing and generated) > are 32-bit while `uname -m` gives x86_64 and cmake sets *_SYSTEM_PROCESSOR > to x86_64 in CMakeFiles/3.7.2/CMakeSystem.cmake. OK, hm. It's not clear to me if this is a bug in our CMake build system or not. Clearly, testing CMAKE_SYSTEM_PROCESSOR (which we do in the toplevel CMakeLists.txt) is not a reliable way to detect the userspace architecture. But I doubt we can do better, and you have a *really* odd configuration, so maybe it's not worth worrying about.
>you have a *really* odd configuration, so maybe it's not worth worrying about. I don't see anything odd with this configuration, I remember using 32-bit Debian 4 and 5, it provided 64-bit kernel package in official repo and I was using it with no hassle. I guess now it's possible to install 64-bit kernel package via regular multiarch support Vadim: what does gcc -dumpmachine return for you? We could use its result instead of CMake's value, if compiler supports -dumpmachine. I've also encountered incomplete toolchain files for cross-compilation which didn't define CMAKE_SYSTEM_PROCESSOR (IIRC it was in MXE, ), so Vadim's use case is not the only one.
Vadim: if you are using Debian, you should better install necessary 64-bit packages and build WebKit as 64-bit application. 32-bit version is not only more limited in features, but also is slower and less secure
Another idea, maybe a bit nuts: perform compile test using our Platform.h and use result of it's CPU detection algorithm to set cmake variable
This seems a bug in your environment, distribution or build system as CMAKE_SYSTEM_PROCESSOR should evaluate to the target system and not the host one. I have a 32-bit chroot and I get the right machine definition inside it $ cmake --system-information /dev/stdout|grep CMAKE_SYSTEM_PROCESSOR CMAKE_SYSTEM_PROCESSOR "i686" (On the host I get "x86_64" as expected)
(In reply to Carlos Alberto Lopez Perez from comment #8) > This seems a bug in your environment, distribution or build system as > CMAKE_SYSTEM_PROCESSOR should evaluate to the target system and not the host > one. > > I have a 32-bit chroot and I get the right machine definition inside it > > $ cmake --system-information /dev/stdout|grep CMAKE_SYSTEM_PROCESSOR > CMAKE_SYSTEM_PROCESSOR "i686" > > > (On the host I get "x86_64" as expected) mmm, it seems that is only true because I entered into the chroot via schroot which sets a 32-bit personality on the kernel. Entering into it with a simple chroot call give a x86_64 value for the processor. You may consider running your session with the command "linux32" so that you get also a 32-bit personality. $ uname -m x86_64 $ linux32 uname -m i686 In any case, If there is any bug here I think this would be a bug in CMake (and not on WebKit). I don't think we should creatively try to workaround CMake default behaviour in this regard. Build systems that cross-compile (Yocto, buildroot) have already solved this problem by creating their own cmake toolchain files where they define all the necessary info about the target platform for CMake.
> > Are there plans to make webassembly work for 32-bit builds? > Definitely not, sorry. It's unclear if even the baseline JIT will remain supported on 32-bit. It's so cute how "portable" the "portable" web is :( It runs on everything if the everything is amd64... never mind. > Vadim: what does gcc -dumpmachine return for you? $ gcc -dumpmachine x86_64-unknown-linux-gnu $ gcc --version gcc (GCC) 6.4.1 20171004 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > you should better install necessary 64-bit packages and build WebKit as 64-bit application. 32-bit version is not only more limited in features, but also is slower and less secure Thanks for the explanation, I'm currently thinking about switching to pure 64 build. Getting browsers eat less memory was one of the primary reasons to have 32-bit userspace for me. If I switch webkit to 64-bit then there is no reason to keep the rest of userspace 32-bit. Browsers are the primary monsters eating memory on nowadays desktops. I sometimes think browser developers assume users have singletasking machines that only run a single application at a time so it's not an issue to allocate all the available memory to the browser. > I don't see anything odd with this configuration, I remember using 32-bit Debian 4 and 5, it provided 64-bit kernel package in official repo and I was using it with no hassle. I agree with Carlos on whether it's not a WebKit bug. I have built much software on such a configuration (64-bit kernel and 32-bit userspace) and I can tell that almost every software depending on bitness has to be fixed (environment variables, build script options, build script patching) to be built successfully. E.g. autotools allows to have a global CONFIG_SITE file where I can put target_alias=i686-unknown-linux-gnu, so I usually don't need to fix every autotool software. cmake does not have such a feature unfortunatelly. It seems there is no general way to fix the issue except using linux32 or setarch. I agree with Carlos that the issue shouldn't (and even cannot) be fixed on webkit level. Such issues must be fixed on build system level (cmake for webkit) if the fix is possbile at all. But imho it would be better to have something like #ifnot USE(JSVALUE64) # undef WEBASSEMBLY #endif in the sources to make WEBASSEMBLY dependency on JSVALUE explicit. Wrt debian, I think they build 32-bit software on 32-bit kernel host, and 64-bit software on 64-bit kernel host, and then just allow users to install 32-bit software with 64-bit kernel. It would be the simplest way.
(In reply to Vadim from comment #10) > > > Are there plans to make webassembly work for 32-bit builds? > > > Definitely not, sorry. It's unclear if even the baseline JIT will remain supported on 32-bit. > > It's so cute how "portable" the "portable" web is :( It runs on everything > if the everything is amd64... never mind. I hope the latter won't happen in nearby future, but B3 is not going to support 32-bit platform either (and our WASM has hard dependency on B3 now; this has a bit more chance to bid changed in future but don't hold your breath) Yes, WASM is marketed as a portable thing, but to be actually useful it has to run fast. This requires sophisticated JIT, close to native compilers, and these things are not easily portable. Try running asm.js stuff compiled from C++ without JIT, it will run "fine", but you probably would be more happy if it didn't. > $ gcc -dumpmachine > x86_64-unknown-linux-gnu I see, we cannot get it into account then. > Getting browsers eat less memory was one of the primary reasons to have > 32-bit userspace for me. I once was sharing this attitude, but in reality lack of general purpose registers and specifics of JS VM make 32-bit x86 an especially poor option.
* "to bid changed: -> "to be changed", sorry