Re: About gcc builtin atomics
On Fri, 22 Jun 2012 18:37:52 +0000 (UTC), Thorsten Glaser <tg@mirbsd.de> wrote:
> 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=3D/usr/lib/gcc/m68k-linux-gnu/4.6/libstdc++_p=
> ic.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/libs=
> tdc++.so -> /tmp/buildd/mesa-8.0.3/build/dri/src/gallium/targets/dri-nouvea=
> u/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=3Dc99 -fno-strict-aliasi=
> ng -fno-builtin-memcmp -Wall -g -O2 -fPIC -D_GNU_SOURCE -DPTHREADS -DTEX=
> TURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING=
> -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=3D=
> 1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XCB_DRI=
> 2 -fvisibility=3Dhidden -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
> =2E./../../../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.s=
> o)
> /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/libd=
> rm_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=E2=80=99m not
> very convinced I=E2=80=99m 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?
Check the input object files in the above link step to see which one
brings in the reference to __sync_sub_and_fetch_4. My suspicion is
that it's nouveau_dri.so.tmp, libdrm_nouveau.so, or libdrm.so; if so,
then that .so file must be rebuilt against the new libgcc_s.so linker
script.
.so files can include code from libgcc.a just fine, but every such
.so file must be produced by linking it explicitly against both the
shared and the static libgcc.
The occurrence in libstdc++.so is a private definition: it's used
for libstdc++.so's own references but cannot be used by other .so
files
/Mikael
Reply to: