Mail Archives: cygwin/2003/02/17/17:49:52
> > 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/
- Raw text -