libtool
[Top][All Lists]
Advanced

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

Re: Cygwin List O' Issues...


From: Charles Wilson
Subject: Re: Cygwin List O' Issues...
Date: Fri, 01 Nov 2002 14:34:40 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

Charles Wilson wrote:

Bob Friesenhahn wrote:


Yes, but I only saw that once.  I have not verified that it always
happens.   It might've been a fluke.  Have you seen this 'go ahead and
build the shared lib even though I just finished complaining that I
couldn't' behavior, too?


Yes, I have.  In this particular case, the library depends on another
project library (with .la file).



Ah -- like IM. The C shared lib builds fine, and then the dependent C++ lib complains, but tries to build anyway?

Okay, I'll whip up a simple testcase...


The testcase is attached, but that's not important. The real problem is that the LACK of a -no-undefined switch doesn't prevent building a sharedlib on cygwin/mingw. That's becauss of this change (one of mine. Sigh.)

2002-05-31  Charles Wilson  <address@hidden>

        * libtool.m4: ...
        For all tags, (and host=cygwin) set
        allow_undefined_flag="" so that the --auto-import magic
        works properly. ...

It appears that this bogosity is no longer necessary, and in fact now causes problems. The attached patch reverts. I will also post this to libtool-patches.

2002-11-01  Charles Wilson  <address@hidden>

        * libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG): restore setting
        allow_undefined_flag=unsupported for cygwin and mingw.
        (AC_LIBTOOL_PROG_LD_SHLIBS): ditto, for both "normal" gcc/ld
        and for the (unmaintained?) MSVC case.

Index: libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.273
diff -u -r1.273 libtool.m4
--- libtool.m4  31 Oct 2002 00:52:39 -0000      1.273
+++ libtool.m4  1 Nov 2002 01:34:18 -0000
@@ -2645,6 +2650,7 @@
     # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
     # as there is no search path for DLLs.
     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+    _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
     _LT_AC_TAGVAR(always_export_symbols, $1)=no
 
     if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then
@@ -2657,6 +2663,7 @@
 
   mingw* | pw32* )
     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+    _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
     _LT_AC_TAGVAR(always_export_symbols, $1)=no
 
     if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then
@@ -4649,6 +4656,7 @@
       # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
       # as there is no search path for DLLs.
       _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
       _LT_AC_TAGVAR(always_export_symbols, $1)=no
 
       if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then
@@ -4877,6 +4877,7 @@
       # hardcode_libdir_flag_spec is actually meaningless, as there is
       # no search path for DLLs.
       _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=' '
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
       # Tell ltmain to make .lib files, not .a files.
       libext=lib
       # FIXME: Setting linknames here is a bad hack.

Attachment: complain-then-attempt-anyway-demo.tar.bz2
Description: Binary data


reply via email to

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