Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3CB8BFC8.50407@ece.gatech.edu>
Date: Sat, 13 Apr 2002 19:31:20 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Cygwin-Apps <cygwin-apps AT sources DOT redhat DOT com>
Subject: Re: libtool devel package still  dll crippled.
References: <FC169E059D1A0442A04C40F86D9BA7600C5E28 AT itdomain003 DOT itdomain DOT net DOT au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:


> What Ralfs patch does is change
> allow_undefined_flag to no (as opposed to unsupported) and


??  what's the difference between "...=unsupported" and "...=no" and 
"...="?  Shouldn't the SAME answer be given in all sections, with 
respect to whether "allow_undefined_flag" is a legal option?

Granted, you can't build a DLL -- in any language -- if there are 
undefined symbols.  But if I want to use libtool to build a static lib, 
I should be allowed to have undefined symbols.  Fine -- by default 
cygwin-libtool asserts -no-undefined, so I need to override that.  SO, 
allow_undefined_flag needs to be "yes" or "supported" or "...=", right?

I don't understand how merely allowing a user to supply a flag hurts 
Ralf's KDE build -- unless he is (mistakenly) USING that flag (even 
though he shouldn't when building a DLL).

And I REALLY don't want to disallow people from building static libs 
with undefined symbols using cygwin libtool.


> always_export_symbols to no (as opposed to yes).
> 
> Now I'm not entirely sure what always_export_symbols does...

> 
> Anyway, the reason there are multiple locations is that libtools guts
> are horrendous. There are folk putting time into factoring libtool to be
> a little bit more consistent and efficient though...
> 
> The location I refer to us in  AC_LIBTOOL_PROG_LD_SHLIBS, where as Ralf
> altered AC_LIBTOOL_LANG_CXX_CONFIG (which needed the alteration too - it
> effectively includes a copy of AC_LIBTOOL_PROG_LD_SHLIBS).


Okay, my patch conflicts with his.  Original CVS (20020316) (ignoring 
the always_export_symbols thing):

_LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported

My patch:

_LT_AC_TAGVAR(allow_undefined_flag, $1)=

Ralf's patch

_LT_AC_TAGVAR(allow_undefined_flag, $1)=no

Again, the "...=" came from you, Rob.  So, what's the difference between 
"...=" and "...=no" or "...=unsupported" (or "...=yes", for that 
matter).  And which do we want/need?

--Chuck