X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49DB3991.10407@gmail.com>
Date: Tue, 07 Apr 2009 12:31:29 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: All clear [was Re: [1.7]: For the love of god, don't update!]
References: <49D97797 DOT 9080902 AT gmail DOT com> <49DA0FE6 DOT 6020603 AT gmail DOT com> <20090406141856 DOT GA19965 AT ednor DOT casa DOT cgf DOT cx> <49DA244E DOT 3080401 AT gmail DOT com> <20090406162943 DOT GA8149 AT calimero DOT vinschen DOT de> <20090406173354 DOT GA20463 AT ednor DOT casa DOT cgf DOT cx> <20090406180833 DOT GR852 AT calimero DOT vinschen DOT de> <20090406212230 DOT GB15228 AT ednor DOT casa DOT cgf DOT cx> <49DA8C77 DOT 3030005 AT gmail DOT com> <20090407074551 DOT GA20277 AT calimero DOT vinschen DOT de>
In-Reply-To: <20090407074551.GA20277@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen wrote:
> On Apr  7 00:12, Dave Korn wrote:

>> Grepping through library symbols seems quite
>> fragile when so many standard C library functions are permitted to be
>> implemented as macros.
> 
> I assume they use nm rather than grep.

  Sorry, I was just using the term in the extended sense of searching for
something, rather than the specific meaning of invoking the grep executable.
(cf. the verb "to google").

> But maybe we should give up on such broken configure scripts?

  Well, I guess the answer as ever is "Just how common is this problem and how
much upheaval would it cause to drop support as compared to trying to keep
them working"?  I can't see any /fundamental/ problem in making these static
libs work.  (It does make me wonder if it wouldn't be worth making this an
integrated feature in LD and/or DLLTOOL, so that we can do it with BFD instead
of having to programmatically hexedit the file with a script.)

  BTW, I've put this problem aside for a day or so while I finish off my weak
symbols design, but I do promise to come back to it after that and analyze in
detail exactly what is going wrong.

  (I said there didn't "appear" to be any overlap in the tables, but that was
on the basis of a quick look at the headers in PEview etc., and not a full
byte-by-byte dump of the tables.  I suspect it may yet turn out to be what's
happening; the corrupt nature of the EXEs I was building mangled the debug
info and meant I couldn't be sure of what I was seeing in the debugger, but it
looked an awful lot like it was getting an unexpected error in response to
attempting to seek back 16 bytes after reading the AR header magic, and this
could happen for instance if the IATs were overwriting each other so that the
syscall went to the wrong imported API from the DLL and ended up looking like
some random syscall with invalid arguments).

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/