This is the mail archive of the cygwin@cygwin.com 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


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


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