bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug with dlpreopening c++ modules (shared objects)


From: Ralf Wildenhues
Subject: Re: bug with dlpreopening c++ modules (shared objects)
Date: Mon, 1 Oct 2007 00:03:10 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Christian,

* Christian Keil wrote on Mon, Sep 24, 2007 at 05:14:44PM CEST:
> 
> 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.

Thanks for the report and the small example to reproduce it.  Please
post the libtool link command that fails and all its output.

FWIW I can't reproduce the failure yet, but there are several things in
the setup that may cause this (one of them being Libtool version used).
Which libstdc++ version(s) are you linking against?

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]