libtool
[Top][All Lists]
Advanced

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

Re: Disable --whole-archive when using convenience archives


From: Alon Bar-Lev
Subject: Re: Disable --whole-archive when using convenience archives
Date: Mon, 22 Mar 2010 21:00:19 +0200

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 <address@hidden> wrote:
> On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev <address@hidden> wrote:
>> On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues <address@hidden> 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!
>




reply via email to

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