Subject: RE: [avail for test] libtool-devel-20030121-1
From: "Ralf Habacker" <[email-masked]>
To: "Charles Wilson" <[email-masked]>
Cc: "cygwin" <[email-masked]>
Date: Mon, 17 Feb 2003 23:49:42 +0100

> > Thats very bad.
> >
>
> Yeah.  I don't know why these implibs need to declare these static
> structures; it's possible that w32api is just following the lead of the
> corresponding .lib files in the MSVC distribution.
>
> But, that's neither here nor there.  IF these crossbreed implibs are
> detected as "import libraries" then libtool will let you link a
> sharedlib using them as dependencies.  this could eventually lead to a
> data mismatch problem, if the static info is changed -- but since your
> DLL has a private copy of the old version...
>
> Fortunately, this isn't likely.  The static data consists of GUID
> structures for well-known services/programs/etc on windows.  MS would be
> insane to change those definitions at this point.
>
> >
> > There might be another (easier) way for identifiying. There are
> some resources
> > in the internet relating to the ar format for examples
<snip>
> the negative: Ralf, you keep trying to assume things based on filenames.
>   Filenames LIE.  Whether it is the name of the archive (foo.dll.a) or
> the name of an object in the archive (dxxxxxx.o), it's gonna fail -- and
> it will fail in EXTREMELY hard-to-track-down ways.

You may be right in this issue, but couldn't the symbol "_dll_iname" doesn't
change in future implementation too ? The important question seems to me like
this: [1] Which is the mostly stable identifier we build on ?

> the positive: I'm glad you're following thru on this.  Here's a plan: I
> can make arrangements so that WHEN we find the Right Thing to do in
> file, libtool can take advantage of it immediately.  thus, we can get my
> speedups into libtool now along with hooks for your super-speedup.
>
> Flowchart:
>
> .  'file -L $fn' # e.g. if symlink, check the target
> .  if file output has "DLL"
> .    exit "x86 DLL"
> .  elif file output has "executable"
> .    if "MS Windows PE Intel" # to screen out "executable" shell scripts
> .      exit "x86 DLL"
> .    endif
> .  elif file output has "ar archive import library"
> .    exit "x86 archive import"
> .  elif file output has "ar archive" # both static and import libs
> .    if objdump output is good       # make sure it's an ar of x86 objs
> .      if nm output has " I "        # fallback test for import libs
> .        exit "x86 archive import"
> .      else
> .        exit "x86 archive static"
> .      endif
> .    endif
> .  endif
> .  exit "unknown"
>
> This way, we get my speedups right away.  The "elif file output has "ar
> archive import library" isn't used right now (because stock 'file' won't
> ever generate that output string).  Thus, right now we use the "ar
> archive" section for both static libs and import libs.  No probs.
>
> Later, your code gets into 'file' -- and suddenly we see big speedups
> for most linking against import libs.  Even better, YOU can see those
> speedups immediately using (the new upcoming 'stock' libtool), simply by
> changing your magic file.  Thus, it helps testing.  Even better,
> anything that FAILS your new file test, will get checked again using the
> slower code!

This sounds good.

> 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".

see [1]

> Oh, and we MUST agree on the id string before hand.  You've suggested
> that import libs add 'import library' to the existing 'ar archive';
> thus: 'ar archive import library'.  sounds good to me -- I'll go with
> that.  But don't change it.
>
> sound good?

I have no problem with this.

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/