Package: libstdc++6-4.5-dev Version: 4.5.0-1 Severity: normal Tags: experimental
Hi, I'm not sure if this bug behave to libstdc++6-4.5-dev or g++-4.5 or if this is really a bug. Here is what I observed: when * a non-threaded application uses some part of the STL (such as <memory>) and * the application links to a library itself linked to libpthread and * the linker is g++-4.5 (not g++-4.4 or previous) then the application itself must be linked with libpthread. Example: vdanj...@eyak:/tmp/test$ cat Makefile CXXLD=$(CXX) CXXFLAGS=-Wall -fPIC -std=gnu++0x CPPFLAGS=-I. all: mymain2 mymain libkapi.so.0 mymain: mymain.o libkapi.so $(CXXLD) -o $@ $(CXXFLAGS) mymain.o -L. -lkapi mymain2: mymain.o $(CXXLD) -o $@ $(CXXFLAGS) mymain.o libkapi.so: libkapi.so.0 ln -fs $...@.0 $@ kapi.cc: touch $@ kapi.o: kapi.cc libkapi.so.0: kapi.o $(CXXLD) $(CXXFLAGS) -shared -Wl,-soname -Wl,$@ -o $@ $^ -pthread clean: $(RM) *.o libkapi.so.0 mymain kapi.cc libkapi.so mymain2 # mymain.cc is the example from http://www.cplusplus.com/reference/std/memory/uninitialized_copy/ vdanj...@eyak:/tmp/test$ cat mymain.cc #include <iostream> #include <memory> #include <string> using namespace std; int main () { string numbers[] ={"one","two","three"}; // get block of uninitialized memory: pair <string*,ptrdiff_t> result = get_temporary_buffer<string>(3); if (result.second>0) { uninitialized_copy ( numbers, numbers+result.second, result.first ); for (int i=0; i<result.second; i++) cout << result.first[i] << " "; cout << endl; return_temporary_buffer(result.first); } return 0; } vdanj...@eyak:/tmp/test$ make g++ -Wall -fPIC -std=gnu++0x -I. -c -o mymain.o mymain.cc g++ -o mymain2 -Wall -fPIC -std=gnu++0x mymain.o touch kapi.cc g++ -Wall -fPIC -std=gnu++0x -I. -c -o kapi.o kapi.cc g++ -Wall -fPIC -std=gnu++0x -shared -Wl,-soname -Wl,libkapi.so.0 -o libkapi.so.0 kapi.o -pthread ln -fs libkapi.so.0 libkapi.so g++ -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi vdanj...@eyak:/tmp/test$ make clean rm -f *.o libkapi.so.0 mymain kapi.cc libkapi.so mymain2 vdanj...@eyak:/tmp/test$ make CXX=g++-4.5 g++-4.5 -Wall -fPIC -std=gnu++0x -I. -c -o mymain.o mymain.cc g++-4.5 -o mymain2 -Wall -fPIC -std=gnu++0x mymain.o touch kapi.cc g++-4.5 -Wall -fPIC -std=gnu++0x -I. -c -o kapi.o kapi.cc g++-4.5 -Wall -fPIC -std=gnu++0x -shared -Wl,-soname -Wl,libkapi.so.0 -o libkapi.so.0 kapi.o -pthread ln -fs libkapi.so.0 libkapi.so g++-4.5 -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi /usr/bin/ld: .: invalid DSO for symbol `pthread_cancel@@GLIBC_2.2.5' definition /lib64/libpthread.so.0: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [mymain] Erreur 1 vdanj...@eyak:/tmp/test$ g++ -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi vdanj...@eyak:/tmp/test$ make clean rm -f *.o libkapi.so.0 mymain kapi.cc libkapi.so mymain2 vdanj...@eyak:/tmp/test$ make g++ -Wall -fPIC -std=gnu++0x -I. -c -o mymain.o mymain.cc g++ -o mymain2 -Wall -fPIC -std=gnu++0x mymain.o touch kapi.cc g++ -Wall -fPIC -std=gnu++0x -I. -c -o kapi.o kapi.cc g++ -Wall -fPIC -std=gnu++0x -shared -Wl,-soname -Wl,libkapi.so.0 -o libkapi.so.0 kapi.o -pthread ln -fs libkapi.so.0 libkapi.so g++ -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi vdanj...@eyak:/tmp/test$ g++-4.5 -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi /usr/bin/ld: .: invalid DSO for symbol `pthread_cancel@@GLIBC_2.2.5' definition /lib64/libpthread.so.0: could not read symbols: Bad value collect2: ld returned 1 exit status vdanj...@eyak:/tmp/test$ g++-4.5 -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi -lpthread vdanj...@eyak:/tmp/test$ nm mymain.o | grep pthread w pthread_cancel vdanj...@eyak:/tmp/test$ The STL emits a weak pthread_cancel symbols into the object file of the main program. I'm not sure this is a bug because I understand what happens. But it seems strange to me that libraries required for an application depends on libraries linked to libraries linked to the application... It seems to me that this behavior defeat one goal of using weak symbols. What do you think ? Regards, Vincent PS: when this happens in our software, the diagnostic has been difficult. I hope this bugreport will, at least, document the problem with google. -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libstdc++6-4.5-dev depends on: ii g++-4.5 4.5.0-1 The GNU C++ compiler ii gcc-4.5-base 4.5.0-1 The GNU Compiler Collection (base ii libc6-dev 2.11-0exp6 Embedded GNU C Library: Developmen ii libstdc++6 4.5.0-1 The GNU Standard C++ Library v3 libstdc++6-4.5-dev recommends no packages. Versions of packages libstdc++6-4.5-dev suggests: pn libstdc++6-4.5-doc <none> (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100415150454.3269.85825.report...@eyak.imag.fr