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: <3CB9C1F4.5090909@ece.gatech.edu>
Date: Sun, 14 Apr 2002 13:52:52 -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: Ralf Habacker <Ralf DOT Habacker AT freenet DOT de>
CC: Cygwin-Apps <cygwin-apps AT cygwin DOT com>
Subject: Re: libtool devel package still  dll crippled.
References: <000301c1e3b8$2164db30$ea6007d5 AT BRAMSCHE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ralf Habacker wrote:


>>must be some way to prevent ld outputting the imported
>>
> symbols as
> 
>>well as the exported symbols...
>>
> 
> I'm using a special patched ld (based on the recent official
> ld) which rejects exporting of all imported libs with a one
> line patch
> 
> binutils/ld/pe-dll.c:234
> /* Do not specify library suffix explicitly, to allow for
> dllized versions.  *
> static autofilter_entry_type autofilter_liblist[] =
> {
>   { "libgcc.", 7 },
>   { "libstdc++.", 10 },
>   { "libmingw32.", 11 },
> +// RH: workaround to allow using static libs in multiple
> dlls
> +  { ".a", 2 },
>   { NULL, 0 }
> };


I really think this is a mistake.  What if I want to build a shared 
library using libtool, and it is composed of a number of object files 
but also some convenience libs?  And those convenience libs contains 
symbols that I want to export?

Blindly refusing to export the symbols from anything that ends in .a is 
a mistake, IMO.  (I could be convinced that re-exporting symbols 
obtained from a .dll.a is always bad, and should be screened out using 
the brute-force, non-overrideable method in the patch above, but not .a)

--Chuck