| Summary: | Cannot build for i386 architecture | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | karogyoker2+webkit |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | berto, bugs-noreply, mcatanzaro |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | PC | ||
| OS: | Linux | ||
|
Description
karogyoker2+webkit
2018-08-11 07:49:41 PDT
As far as I'm aware Debian i386 packages are built for 686-class processors. See https://lists.debian.org/debian-devel/2015/09/msg00589.html Those atomic primitives need CPU instructions not available in older processors. You can try the following test.cpp file: #include <atomic> int main() { std::atomic<int64_t> i(0); i++; return 0; } And now: $ g++ -o test test.cpp $ g++ -o test test.cpp -march=i386 /usr/bin/ld: /tmp/ccJF5W0r.o: in function `std::__atomic_base<long long>::operator++(int)': test.cpp:(.text._ZNSt13__atomic_baseIxEppEi[_ZNSt13__atomic_baseIxEppEi]+0x41): undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status You need to add -latomic: $ g++ -o test test.cpp -march=i386 -latomic There's a test in Source/cmake/WebKitCompilerFlags.cmake that should detect automatically whether you need to pass -latomic or not. If that doesn't work in your case it must be because you're building with -march=i386 but the test is built for a more recent CPU. If you debug this issue and find a problem with the test, please tell us. That said, I'm not sure how well a recent WebKitGTK+ will work in such an old CPU (if at all). When I built like this: cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS="-march=i386 -latomic" -DCMAKE_CXX_FLAGS="-march=i386 -latomic" -DUSE_WOFF2=OFF -GNinja It built, and WebKit is also working. "Those atomic primitives need CPU instructions not available in older processors." Which instructions are these? After a quick search I found these atomic operations are using the lock instruction[1,2] but that's available since the 8086[3]. Maybe the 80386 doesn't support a hardware implementation for __atomic_fetch_sub and __atomic_compare_exchange but it only does for other atomic operations? We could fix the test in WebKitCompilerFlags.cmake by setting the CXX flags before running the test to include the flags which are provided by the user when it was initially starting cmake. This way "-march=i386" would be used by the compiler and it would fail the test. But this would only make sense if the 80386 would be able to run the compiled code. Currently I don't see why it could not. [1]: http://www.mohawksoft.org/?q=node/78 [2]: https://stackoverflow.com/questions/38447226/atomicity-on-x86 [3]: https://en.wikipedia.org/wiki/X86_instruction_listings#Original_8086/8088_instructions (In reply to karogyoker2+webkit from comment #2) > We could fix the test [...] But this would only make sense if the > 80386 would be able to run the compiled code. Currently I don't see > why it could not. I suppose my questions are: - Did you try it? Is it usable? Does it even run? :-) - What's the use case? Is there an actual machine where you are planning to run this? > - Did you try it? Is it usable? Does it even run? :-)
>
> - What's the use case? Is there an actual machine where you are
> planning to run this?
Sadly, I don't have a 386 yet, but then it is time to have one, so I can test this. I'm gonna buy one and try this out. Or, maybe it is easier to test this in Bochs with an emulated 386. I'll come back with the results.
(In reply to karogyoker2+webkit from comment #4) > > - Did you try it? Is it usable? Does it even run? :-) > > > > - What's the use case? Is there an actual machine where you are > > planning to run this? > Sadly, I don't have a 386 yet, but then it is time to have one, so I > can test this. You still didn't tell me the use case :-) Why do you need to make WebKitGTK+ work on a 386? Who is using a 386 in 2018, and why would anyone get one? > You still didn't tell me the use case :-)
>
> Why do you need to make WebKitGTK+ work on a 386?
>
> Who is using a 386 in 2018, and why would anyone get one?
The use case would be that I do a google search on a 386 (and possibly other things), for the same reason I did it on a Nokia 6030. It was fun, so the use case would be recreation, like watching cat videos, just much better. WebKit would be much usable because it is up to date, on the Nokia 6030 a lot of pages didn't load due to it didn't support modern TLS protocols.
(In reply to karogyoker2+webkit from comment #6) > > Why do you need to make WebKitGTK+ work on a 386? > The use case would be that I do a google search on a 386 (and > possibly other things), for the same reason I did it on a Nokia > 6030. It was fun, so the use case would be recreation, like watching > cat videos, just much better. Ok, if it's for personal recreation then you can make it work by passing -latomic manually as we saw earlier. If you think the compiler flag tests can be improved and you have a patch that does it we'll be happy to have a look at it, but please realize that detecting whether to use the -latomic flags properly in all supported architectures has been a small source of headaches for a while, so you'll need to convince me that it won't break anything :-) I'm closing this bug, you can reopen it if/when you have a patch. Yes, I absolutely agree, I can build it for myself and if somebody else wants to do the same in the future he will find the solution here. Do not risk to break something if it is working fine now, just because of this unimportant edge case. It seems it wouldn't work anyways: https://hothardware.com/news/sorry-intel-386dxsx-owners-no-new-linux-for-you |