This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [avail for test] libtool-devel-20030121-1

Ralf Habacker wrote:
BTW: Do you know which libraries are also hybrid execpt of cygwin1.dll ?

There are about a half-dozen in /usr/lib/w32api -- and worse, the static
members are "bad" variable  types; if you make the static members part of the
DLL, then these vars can't be auto-imported without using pseudo-relocs. Of
course, since the DLLs are provided by MS, we can't really modify what is in

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

After the ar header, there is a vector with pointers to each file. The first
points to the first objectfile. The first bytes at the offset position is a
string of the object file name, which is build
for import library like d<6-digit-num>.o, which could be easily identified with
one indirect file magic rule line and two addition simple lines.

(0x48l)  byte 0x64

(0x48l+7) leword 0x2e6f	import libray

What dou you think ?
If I understand correctly, you look at the first object file in the archive, and check that the first letter of the name is 'd', and that the 8th and ninth letters are '.o' I don't think that is sufficient...

The problem is, that I have tried this indirecting mode in several way, but
without success. It seems to me that this functionality is broken in recent file
release. Do anyone has got same experiences ?
...even if it works properly in well-controlled circumstances -- which apparently it doesn't. And in poorly controlled circumstances, I could have an object file in my archive named "delayby.orig.o" and you couldn't distinguish it from "d000000.o".

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.

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.


. '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!

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

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?

win32_libid () {
  win32_fileres=`file -L $1 2>/dev/null`
  case $win32_fileres in
  *ar\ archive\ import\ library*) # definitely import
    win32_libid_type="x86 archive import"
  *ar\ archive*) # could be an import, or static
    if eval $OBJDUMP -f $1 | head -n 10 2>/dev/null | \
      grep -E 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
      win32_nmres=`eval $NM -f posix -A $1 | \
        sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;}}'`
      if [ "x$win32_nmres" = "ximport" ] ; then
        win32_libid_type="x86 archive import"
        win32_libid_type="x86 archive static"
    win32_libid_type="x86 DLL"
  *executable*) # but shell scripts are "executable" too...
    case $win32_fileres in
    *MS\ Windows\ PE\ Intel*)
      win32_libid_type="x86 DLL"
  echo $win32_libid_type

win32_libid $1

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]