Re: About gcc builtin atomics
Mikael Pettersson dixit:
>As I mentioned before you need to replace the libgcc_s.so symlink
>with a linker script. Several gcc targets (at least powerpc, sh,
>hppa, and arm) do so already because they have helpers in their
>static libgcc that aren't present in their shared libgcc.
I tried to validate this before sacrificing three days in building
gcc, and could not get it to work.
# cat /usr/lib/gcc/m68k-linux-gnu/4.6/libgcc_s.so
GROUP ( /lib/m68k-linux-gnu/libgcc_s.so.2 libgcc.a )
I then rebuilt libstdc++.so from the -pic package:
gcc -shared-libgcc -shared -Wl,--whole-archive /usr/lib/gcc/m68k-linux-gnu/4.6/libstdc++_pic.a -Wl,--no-whole-archive -lm -lc -lgcc_s -Wl,-O1 -Wl,-z -Wl,relro -Wl,--version-script=/usr/lib/gcc/m68k-linux-gnu/4.6/libstdc++_pic.map -Wl,-soname -Wl,libstdc++.so.6 -o libstdc++.so.6.0.16
Then I replaced the symlink:
lrwxrwxrwx 1 root root 84 Jun 22 18:29 /usr/lib/gcc/m68k-linux-gnu/4.6/libstdc++.so -> /tmp/buildd/mesa-8.0.3/build/dri/src/gallium/targets/dri-nouveau/libstdc++.so.6.0.16*
(Erm well, yes, I just did it in $PWD for easiness.)
But linking still fails:
# g++ -Wall -g -O2 -Wall -Wmissing-prototypes -std=c99 -fno-strict-aliasing -fno-builtin-memcmp -Wall -g -O2 -fPIC -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI2 -fvisibility=hidden -o nouveau_dri.so.test ../../../../src/mesa/drivers/dri/common/dri_test.o nouveau_dri.so.tmp ../../../../src/mesa/libmesa.a -ldrm -lexpat -lm -lpthread -ldl -ldrm_nouveau -Wl,-t
/usr/bin/ld: mode m68kelf
/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/crt1.o
/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/crti.o
/usr/lib/gcc/m68k-linux-gnu/4.6/crtbegin.o
../../../../src/mesa/drivers/dri/common/dri_test.o
nouveau_dri.so.tmp
-ldrm (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libdrm.so)
-lexpat (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libexpat.so)
/lib/m68k-linux-gnu/libpthread.so.0
-ldl (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libdl.so)
-ldrm_nouveau (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libdrm_nouveau.so)
-lstdc++ (/usr/lib/gcc/m68k-linux-gnu/4.6/libstdc++.so)
-lm (/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/libm.so)
/lib/m68k-linux-gnu/libgcc_s.so.2
(/usr/lib/gcc/m68k-linux-gnu/4.6/libgcc.a)linux-atomic.o
/lib/m68k-linux-gnu/libc.so.6
(/usr/lib/m68k-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/m68k-linux-gnu/ld.so.1
/lib/m68k-linux-gnu/libgcc_s.so.2
/usr/lib/gcc/m68k-linux-gnu/4.6/crtend.o
/usr/lib/gcc/m68k-linux-gnu/4.6/../../../m68k-linux-gnu/crtn.o
/usr/bin/ld: nouveau_dri.so.test: hidden symbol `__sync_sub_and_fetch_4' in /usr/lib/gcc/m68k-linux-gnu/4.6/libgcc.a(linux-atomic.o) is referenced by DSO
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
However, ./libstdc++.so.6.0.16 contains the symbols, a nm(1) shows:
000ab7ba t __sync_sub_and_fetch_4
Stripping ./libstdc++.so.6.0.16 does not help either. So I’m not
very convinced I’m seeing the same issue.
Interestingly enough, an nm -D on the original libstdc++.so did
not reveal any symbol reference to __sync_sub_and_fetch_4 either.
My first reading of the error message let me think that the problem
was that the DSO to be *made* (nouveau_dri.so.test) uses them.
Maybe DSOs are not supposed to include code from libgcc.a at all?
Or maybe PIC is needed?
bye,
//mirabilos
--
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant. Therefore you cannot use ' in a preproces-
sing file in c99 mode. -- Ragge
No faith left in ISO C99, undefined behaviour, etc.
Reply to: