[Top][All Lists]
[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.
complain-then-attempt-anyway-demo.tar.bz2
Description: Binary data
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Cygwin List O' Issues...,
Charles Wilson <=