Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "cygwin" <cygwin AT cygwin DOT com>, "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Subject: RE: [avail for test] libtool-devel-20030121-1
Date: Thu, 20 Feb 2003 00:06:35 +0100
Message-ID: <009b01c2d86b$8ceabed0$c66307d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
In-Reply-To: <3E518ED7.7020401@ece.gatech.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

> > You may be right in this issue, but couldn't the symbol "_dll_iname" doesn't
> > change in future implementation too ? The important question seems
> to me like
> > this: [1] Which is the mostly stable identifier we build on ?
>
> filenames change because evil twisted pesky end-users change them, at
> any time, for any reason.  The _dll_iname symbol has been in every
> DLL/implib I've built in the four (five?) years I've been using cygwin.
>   The only way that symbol is going to change is if somebody
> deliberately changes that particular piece of binutils.
>
> Now, the relative *offset* of that symbol might move around.  But the
> symname is not likely to change.
>
Thanks for this additional note.

>from a previous mail:
>>So, it's important, Ralf, that your 'file' changes NEVER generate a
>>false positive (e.g. saying something is an import lib when it is not).
>>  If your code generates a false negative (saying something is static
>>when it's actually an import) -- because for false negatives, my slower
>>code will catch it, and mark it "import".

There is only one open issue : 'file' reads the first 16K into a buffer.

My currently proposal is to search for the string _dll_iname starting at the
position of the first object file until the end of the archive (if it is less
than 16KB) or at least the first 16 KB, if the archive is longer.
That means, if the above mentioned string is found in that area, this archive
will be identified as import library otherwise as static archive.

Because ar puts an offset table to each object file after it's ar header and a
symbol cache, (the first symbol is a dll_iname symbol, there are some
limitations.
I've recognized, that the limit is by about 4070 object files.
One can estimate, that this proposal will fail with import libs bigger than
about 1-1.5 MB. For cygwin I've found this true for only one library:
libcrypto.dll.a with 1.6 MB file size.

For kde I have found four import libraries which exceeds this limit (the biggest
import library is about 4.5 MB), but this is no problem, because definitly there
will not be any further kde releases with import libraries.

So as result I see the following:

1. the file patch would generate some false negative in case of very big import
libraries created  with recent binutils.

2. This could be fixed by using the new direct-linking-to-dll functionality for
libraries with many symbols rsp. big import libraries, which I hope will be
available soon.

Ralf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/