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