bug with dlpreopening c++ modules (shared objects)

[Christian Keil]

Hi,

I might have discovered a bug with regard to dlpreopening when dealing
with c++ modules.

The attached tar.gz contains a very small project that just tries to
open a module specified on the command line and runs the contained
method `run'. There's one module contained in two version `run.c' and
`run.cpp'. The program should be run with `./dlpreopen ./run.la'
Using `run.c' everything runs fine with or without --disable-shared.
Using `run.cpp' for the module (as is specified in `Makefile.am') the
module correctly builds as an so. But specifying --disable-shared when
configuring, the build fails when linking the final executable with
several undefined references. There seems to be a discrepancy in defined
symbols between `libstdc++.a' and `libstdc++.so'. The former one is used
to extract the global C symbols, while the latter one is used to build
the final executable. When I substitute `libstdc++.a' for `libstdc++.so'
in the command everything seems to work fine.

libtool --version gives:
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

Copyright (C) 2005  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

config.guess:
i686-suse-linux-gnu

The output of configure is contained as `configure.log' in the archive.

Please let me know if you need any more info or if I'm getting things
wrong, and there's no bug here.

Cheers,
Christian

-- 
Christian Keil                        /"\
Institute for Reliable Computing      \ /    ASCII Ribbon Campaign
Hamburg University of Technology       X  against HTML email & vCards
mail:address@hidden             / \

c++static.tar.gz
Description: GNU Zip compressed data