On Mon, Dec 21, 2009 at 6:21 PM, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > On Thu, Dec 3, 2009 at 10:39 PM, Ralf Wildenhues <ralf.wildenh...@gmx.de> > wrote: >> * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 09:28:59PM CET: >> > On Thu, Dec 3, 2009 at 10:17 PM, Ralf Wildenhues wrote: >> > > * Alon Bar-Lev wrote on Thu, Dec 03, 2009 at 07:08:03PM CET: >> > > > I have some convenience archives linked against several modules. >> > > > >> > > > I wish only required objects to be included in modules. >> > > >> > > Then make the convenience archives not be convenience archives any >> > > longer, i.e., make them libtool libraries. >> [...] >> > > In either case, they may end up being shared libraries (or both), so if >> > > you don't want that, add -static to libbar_la_LDFLAGS. >> > >> > I had to add -prefer-pic to CFLAGS in order it to work properly... :) >> > >> > Wow... this is an ugly workaround... Any reason why a simple switch to >> > "libtool --mode=link" is not supported? >> >> Yes, I think this is by intention. What you do is, at least most of the >> time, ugly. Why do you need the library to be PIC? Usually, the reason >> for that is that lib1.la does end up included in a, or a couple of, shared >> libraries or modules somewhere. And at that point, you risk (exposing >> your users to) subtle bugs: if code from lib1 is present in several >> places, and contains static state (example: last random number of a >> RNG), then on some systems, different parts of the running executable >> might suddenly use different instances of that state. Eww. >> >> Typically, that's the point at which developers reconsider to make lib1 >> a proper shared library. >> >> > Is it the first time someone needs this? >> >> No, but we've been able to convince most of the other guys that asked >> for this to reconsider. ;-) > > Hello Ralf, > > For some strange reason this workaround does not work in Windows when > creating a DLL. > > I get: > --- > /bin/sh ../../../../libtool --tag=CC --mode=link > x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module > -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la > -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 > > *** Warning: This system can not link to static lib archive > ../../../../src/lib/core/libcore.la. > *** I have the capability to make that library automatically link in > when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** But as you try to build a module library, libtool will still create > *** a static module, that should work as long as the dlopening application > *** is linked with the -dlopen flag to resolve symbols at runtime. > --- > > If I modify libtool: > if test "$deplibs_check_method" != pass_all; then > To: > if false && test "$deplibs_check_method" != pass_all; then > > It works... > > Any ideas? >
Hello Ralf, Any idea how to workaround/solve this on windows host? Thanks! _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool