Ralf Habacker wrote:
Now that's an idea, but we'd need to get it into the "real" file distribution -- otherwise, cross-compile builds won't work.1) x86 DLL (and EXE) 2) x86 archive static 3) x86 archive import 4) otherDo NOT try to combine 2) and 3) -- which is what all of your suggestions in this email would do.[1] What about extending the 'file' tool, which supports already 1, (2 combined with 3) and 4 ? You have written (and I have checked this too) that 'file's execution time is independend from the object file size, so this would speedup this detecion.
Yep. Believe it or not, I *did* look at this idea early on -- and you've hit on the reason I didn't pursue it.I've taken a look into the file source and have seen the only thing I don't know is how to define a rule for a string with a variable fileoffset, because '_dll_iname' is, as far as i can see, one of major identifier of import libraries.
Sure -- but as you say, that only works for fixed offsets. Now, **most** import libs will need only the fixed offset, especially if you hunt for _dll_iname instead of " I " in $NM's output as I was doing. This is a very good idea.For an example how to add support with fixed file offset /usr/lib/libintl.dll.a): $ diff -ubB archive.orig archive --- MagDir/archive.orig 2003-02-10 09:01:41.000000000 +0100 +++ MagDir/archive 2003-02-10 09:00:36.000000000 +0100 @@ -79,6 +79,8 @@ >0 beshort 3 - shared library module >0 beshort 4 - debug break-pointed module >0 beshort 5 - absolute code program module +>866 string _dll_iname import library + 0 string \<ar> System V Release 1 ar archive 0 string =<ar> archive #
But, you'd still need to check all "static libs" to see if they are really import libs after all. The good news it that we expect this to happen only rarely: when an import lib is a "hybrid" lib with static objs "in front" --> the modified 'file' test incorrectly identifies it as a static archive.
Question: for "normal" import libs (that is, excluding the hybrids like libcygwin.a), does your version work always? Or does _dll_iname 'float around' even within otherwise normal import libs?
Downside: we can't use this idea in libtool-1.5. We have to wait until after your change (after suitable debugging, of course) makes it into not just OUR file distribution, but the "real" file distribution.
Summary: sounds good. Please pursue, and once your modification has been accepted into 'file' and the upgrade has reasonable penetration on non-cygwin platforms, then we can *really* speed up win32_libid() -- maybe by libtool-1.5.1 or .2. But for now, I think we'll have to stick with the moderate speedup that my proposal allows.
--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/
