Your message dated Tue, 22 Jun 2010 14:49:01 +0200
with message-id <4c20b13d.3050...@debian.org>
and subject line Re: Bug#577961: libstdc++6-4.5-dev: Using some part of the STL
increase the linkage requirement
has caused the Debian Bug report #577961,
regarding libstdc++6-4.5-dev: Using some part of the STL increase the linkage
requirement
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
577961: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577961
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On 15.04.2010 17:04, Vincent Danjean wrote:
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.
I can't reproduce this with current unstable and current g++-4.5 from
experimental. Please reopen if appropriate.
--- End Message ---
