This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [avail for test] libtool-devel-20030121-1

Ralf Habacker wrote:

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.

How do you get `file` to do that??? "if filesize < 16kb, then...' etc?

That means, if the above mentioned string is found in that area, this archive
will be identified as import library otherwise as static archive.

That sounds okay. You'd get false negatives (very few), and no false positives. That's good -- false positives are really bad. False negatives, we let the slower code deal with.

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
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.

Hmm...but, if the `file`-based test misses an import lib, the slower could could be used to catch it. And, that slower could *does* successfully detect that libcrypto.dll.a is an import lib, even though it only looks at the first 100 lines of the `nm` output. So, I see no problems there.

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.

I assume you mean because you're going to link directly to the DLL. A request: in your packaged releases, include a symlink with the "official" import lib name:
lib/libkdefoo.dll.a --> ../bin/cygkdefooX.dll

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.

this is okay. See above.

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.

right. What's the holdup there? IIRC, there are two outstanding patches to binutils with cygwin impact; one of yours, I think, plus another one from Fabrizio Gennari (as modified by Danny Smith). Last I heard, we were still waiting on Fabrizio's copyright assignment; it doesn't appear that the patch has been added. Are we still waiting? Anybody know what's up with that?


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]