Hello Ralf, It is find if you don't want to solve this, but please acknowledge that you don't. So far I did not get any response regarding this issue.
When using: AM_CFLAGS = $(PCAP_CFLAGS) -prefer-pic AM_LDFLAGS = -rpath $(libdir) -static In order to make whole-archive go away, it works in *NIX but not in Windows. In order to fix it I need to modify libtool: elif test "$build_libtool_libs" = yes; then # Not a shared library - if test "$deplibs_check_method" != pass_all; then + if false && test "$deplibs_check_method" != pass_all; then Any chance this will be solved properly? Thanks, Alon. On Mon, Jan 25, 2010 at 6:12 PM, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev <alon.bar...@gmail.com> wrote: >> On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues <ralf.wildenh...@gmx.de> >> wrote: >>> * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: >>>> > 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 idea how to workaround/solve this on windows host? >>> >>> I'm not sure I understand correctly. libtool prints a warning, but >>> should not fail. Is the result usable? If not, then the build should >>> end with an error in a later link: can you post it and its output? >>> >>> Thanks, >>> Ralf >>> >> >> Here it is: >> liba - should be static >> libb - should be dynamic, liking with liba without whole archive. >> >> Works on UNIX does not on Windows. >> >> Attached are the sources. >> >> Thanks, >> Alon. >> >> --- >> >> make all-am >> make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' >> /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc >> -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o >> b.lo b.c >> libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT >> b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o >> libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT >> b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o >/dev/null 2>&1 >> mv -f .deps/b.Tpo .deps/b.Plo >> /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc >> -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP >> -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo >> './'`a.c >> libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT >> liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT >> -DPIC -o .libs/liba_la-a.o >> libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT >> liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o >>>/dev/null 2>&1 >> mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo >> /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc >> -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la >> liba_la-a.lo >> libtool: link: warning: undefined symbols not allowed in >> i686-w64-mingw32 shared libraries >> libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o >> libtool: link: i686-w64-mingw32-ranlib .libs/liba.a >> libtool: link: ( cd ".libs" && rm -f "liba.la" && ln -s "../liba.la" >> "liba.la" ) >> /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 >> -module -shared -avoid-version -no-undefined -export-symbols >> ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la >> >> *** Warning: This system can not link to static lib archive liba.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. >> libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o >> libtool: link: i686-w64-mingw32-ranlib .libs/libb.a >> libtool: link: ( cd ".libs" && rm -f "libb.la" && ln -s "../libb.la" >> "libb.la" ) >> make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' >> > > Sorry to bother... but any news regarding this one? > Thanks! > _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool