Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3E47FA28.9030302@ece.gatech.edu> Date: Mon, 10 Feb 2003 14:14:48 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Habacker CC: cygwin AT cygwin DOT com Subject: Re: [avail for test] libtool-devel-20030121-1 References: <000c01c2d0db$54c64390$d8a907d5 AT BRAMSCHE> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Ralf Habacker wrote: >>1) x86 DLL (and EXE) >>2) x86 archive static >>3) x86 archive import >>4) other >> >>Do 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. Now that's an idea, but we'd need to get it into the "real" file distribution -- otherwise, cross-compile builds won't work. > 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. 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. > 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 \ System V Release 1 ar archive > 0 string = archive > # 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. 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/