Mail Archives: cygwin/2003/02/21/12:26:21
>
> > 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?
I'm not sure, ifc I have understand you right.
file provides a variable nbytes, which will be HOWMANY, if the archive is bigger
or the archive len otherwise.
file.h:# define HOWMANY 16384 /* how much of the file to look at */
Currently I'm discussing the implementation with the 'file' author.
> > 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
> > 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.
>
> 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.
>
me too
> >
> > 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
Yes, i will use chucks-great-directly-linking-to-dll-compatibility-trick :-)
BTW: Currently I'm using a hacked libtool with directly-linking-to-dll support,
which works for mostly cases. It works great. May be you can benefit for a
future libtool support.
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/
- Raw text -