--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: libstdc++6-4.5-dev: Using some part of the STL increase the linkage requirement
- From: Vincent Danjean <vdanjean@debian.org>
- Date: Thu, 15 Apr 2010 17:04:54 +0200
- Message-id: <20100415150454.3269.85825.reportbug@eyak.imag.fr>
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:
vdanjean@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/
vdanjean@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;
}
vdanjean@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
vdanjean@eyak:/tmp/test$ make clean
rm -f *.o libkapi.so.0 mymain kapi.cc libkapi.so mymain2
vdanjean@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
vdanjean@eyak:/tmp/test$ g++ -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi
vdanjean@eyak:/tmp/test$ make clean
rm -f *.o libkapi.so.0 mymain kapi.cc libkapi.so mymain2
vdanjean@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
vdanjean@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
vdanjean@eyak:/tmp/test$ g++-4.5 -o mymain -Wall -fPIC -std=gnu++0x mymain.o -L. -lkapi -lpthread
vdanjean@eyak:/tmp/test$ nm mymain.o | grep pthread
w pthread_cancel
vdanjean@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
--- End Message ---