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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
