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

[Charles Wilson]

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
> them.
> 
> 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
> http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/files/aixfiles/ar_IA64.h
> tm
> 
> 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.

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!

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?

--Chuck
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygwin_libid
URL: <http://cygwin.com/pipermail/cygwin/attachments/20030217/0dc4672b/attachment.ksh>
-------------- next part --------------
--
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/