161900 2016-09-13 03:38:17 -0700 [GTK] [armel] multiple definition of `__sync_add_and_fetch_8' 2020-04-13 02:58:31 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Other Linux RESOLVED WORKSFORME https://bugs.webkit.org/show_bug.cgi?id=182622 P2 Normal --- 1 berto webkit-unassigned aperez bugs-noreply cgarcia clopez mcatanzaro oldest_to_newest 1229119 0 berto 2016-09-13 03:38:17 -0700 2.13.4 fails to build in armel: /usr/lib/gcc/arm-linux-gnueabi/5/libgcc.a(linux-atomic-64bit.o): In function `__sync_add_and_fetch_8': (.text+0x2c0): multiple definition of `__sync_add_and_fetch_8' ../../lib/../Source/WTF/wtf/CMakeFiles/WTF.dir/Atomics.cpp.o:/«PKGBUILDDIR»/Source/WTF/wtf/Atomics.cpp:64: first defined here /usr/lib/gcc/arm-linux-gnueabi/5/libgcc.a(linux-atomic-64bit.o): In function `__sync_sub_and_fetch_8': (.text+0x32c): multiple definition of `__sync_sub_and_fetch_8' ../../lib/../Source/WTF/wtf/CMakeFiles/WTF.dir/Atomics.cpp.o:/«PKGBUILDDIR»/Source/WTF/wtf/Atomics.cpp:69: first defined here collect2: error: ld returned 1 exit status I haven't tested 2.13.91 yet but that file hasn't changed so I believe the problem is still there. 1229989 1 berto 2016-09-15 06:13:02 -0700 2.13.92 is also affected. I tried with a few versions of gcc and clang and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 doesn't seem to be defined, however a simple test with clang fails because __sync_add_and_fetch_8 and __sync_sub_and_fetch_8 are builtin functions. 1232042 2 289444 berto 2016-09-21 05:16:07 -0700 Created attachment 289444 Detect __sync_add_and_fetch_8() at compile time Here's what I'm doing in Debian to solve this, instead of checking for __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1232053 3 mcatanzaro 2016-09-21 06:43:04 -0700 How is it that it builds at all after removing this file? 1232056 4 berto 2016-09-21 06:47:28 -0700 (In reply to comment #3) > How is it that it builds at all after removing this file? Because libgcc already provides the same functions 1287465 5 clopez 2017-03-13 19:46:37 -0700 I noticed openembedded its also carrying this patch downstream with 2.14.5. So I guess this is an still an issue. I suggest to add a changelog to the patch and request for review? 1287480 6 mcatanzaro 2017-03-13 20:28:01 -0700 Please add preprocessor guards inside the .cpp file instead of adding further complexity to the CMake file! 1287564 7 berto 2017-03-14 01:47:23 -0700 (In reply to comment #6) > Please add preprocessor guards inside the .cpp file instead of adding > further complexity to the CMake file! You have to find the right guards, though :) The ones that are there don't solve the problem. 1287608 8 mcatanzaro 2017-03-14 08:06:00 -0700 More accurately, whoever wants armel support has to find the right guards. :D 1419915 9 aperez 2018-05-02 16:09:41 -0700 I think that a proper solution for bug #182622 would also solve this one. 1640819 10 berto 2020-04-13 02:58:31 -0700 No longer a problem 289444 2016-09-21 05:16:07 -0700 2016-09-21 05:16:07 -0700 Detect __sync_add_and_fetch_8() at compile time webkit.diff text/plain 887 berto ZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3RmL0NNYWtlTGlzdHMudHh0IGIvU291cmNlL1dURi93 dGYvQ01ha2VMaXN0cy50eHQKaW5kZXggODY3OTk5ZS4uZWE2OTMyMiAxMDA2NDQKLS0tIGEvU291 cmNlL1dURi93dGYvQ01ha2VMaXN0cy50eHQKKysrIGIvU291cmNlL1dURi93dGYvQ01ha2VMaXN0 cy50eHQKQEAgLTE3MSw3ICsxNzEsNiBAQCBzZXQoV1RGX0hFQURFUlMKIAogc2V0KFdURl9TT1VS Q0VTCiAgICAgQXNzZXJ0aW9ucy5jcHAKLSAgICBBdG9taWNzLmNwcAogICAgIEJpdFZlY3Rvci5j cHAKICAgICBDb21waWxhdGlvblRocmVhZC5jcHAKICAgICBDcm9zc1RocmVhZENvcGllci5jcHAK QEAgLTI3Niw2ICsyNzUsMTUgQEAgaWYgKE5PVCBVU0VfU1lTVEVNX01BTExPQykKICAgICBsaXN0 KEFQUEVORCBXVEZfTElCUkFSSUVTIGJtYWxsb2MpCiBlbmRpZiAoKQogCitmaWxlKFdSSVRFICR7 Q01BS0VfQklOQVJZX0RJUn0vdGVzdF9hdG9taWNzLmNwcAorICAgICAiaW50IG1haW4odm9pZClc biIKKyAgICAgInsgbG9uZyBsb25nIHggPSAxOyByZXR1cm4gKGludCkgX19zeW5jX2FkZF9hbmRf ZmV0Y2hfOCgmeCwgMSk7IH1cbiIpCit0cnlfY29tcGlsZShBVE9NSUNTX0JVSUxEX1NVQ0NFRURF RCAke0NNQUtFX0JJTkFSWV9ESVJ9ICR7Q01BS0VfQklOQVJZX0RJUn0vdGVzdF9hdG9taWNzLmNw cCkKK2lmIChOT1QgQVRPTUlDU19CVUlMRF9TVUNDRUVERUQpCisgICAgbGlzdChBUFBFTkQgV1RG X1NPVVJDRVMgQXRvbWljcy5jcHApCitlbmRpZiAoKQorZmlsZShSRU1PVkUgJHtDTUFLRV9CSU5B UllfRElSfS90ZXN0X2F0b21pY3MuY3BwKQorCiBsaXN0KEFQUEVORCBXVEZfU09VUkNFUwogICAg IHVuaWNvZGUvaWN1L0NvbGxhdG9ySUNVLmNwcAogKQo=