Bug 161900 – [GTK] [armel] multiple definition of `__sync_add_and_fetch_8'

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: WebKitGTK

[Alberto Garcia]

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.

[Alberto Garcia]

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.

[Alberto Garcia]

Created attachment 289444 [details]
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

[Michael Catanzaro]

How is it that it builds at all after removing this file?

[Alberto Garcia]

(In reply to comment #3)
> How is it that it builds at all after removing this file?

Because libgcc already provides the same functions

[Carlos Alberto Lopez Perez]

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?

[Michael Catanzaro]

Please add preprocessor guards inside the .cpp file instead of adding further complexity to the CMake file!

[Alberto Garcia]

(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.

[Michael Catanzaro]

More accurately, whoever wants armel support has to find the right guards. :D

[Adrian Perez]

I think that a proper solution for bug #182622 would also
solve this one.

[Alberto Garcia]

No longer a problem