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 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.That means, if the above mentioned string is found in that area, this archive will be identified as import library otherwise as static archive.
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.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.
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: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.
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.
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?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.
--Chuck
--
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/