Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "cygwin" <cygwin AT cygwin DOT com>
Cc: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Subject: Re: [avail for test] libtool-devel-20030121-1 
Date: Sun, 16 Feb 2003 14:50:47 +0100
Message-ID: <001201c2d5c2$68cd4550$755f07d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal


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

>So these "extra bits" probably need to *stay* static, and appended to the end
of the import lib...but, because they are (currently) appended to the end of the
importlib portion, your code will get it "right'.


>>Question: for "normal" import libs (that is, excluding the hybrids like
>>libcygwin.a), does your version work always? Or does _dll_iname 'float
>>around' even within otherwise normal import libs?

<snip>


>>That mean, we onbly have to figure out the relative pointer to the 'dll_iname'
>>string.
>>When I have time, I will look into the coff file format or is someone else
here,
>>who can give a pointer to this ?

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.

$ dump /usr/lib/libz.dll.a
/usr/lib/libz.dll.a:

| ar header
|  Addr     0 1  2 3  4 5  6 7  8 9  A B  C D  E F 0 2 4 6 8 A C E
|--------  ---- ---- ---- ---- ---- ---- ---- ---- ----------------
|00000000  213c 6172 6368 3e0a 2f20 2020 2020 2020 !<arch>./
|00000010  2020 2020 2020 2020 3130 3135 3930 3739         10159079
|00000020  3138 2020 3020 2020 2020 3020 2020 2020 18  0     0
|00000030  3020 2020 2020 2020 3534 3132 2020 2020 0       5412
|00000040  2020 600a 0000 00fa


vector with objectfile offsets

                              0000 1568 0000 16a0   `....z...h...
                              ^^^^^^^^^ points to first object file.

00000050  0000 1820 0000 1820 0000 1820 0000 1a6c ... ... ... ...l
00000060  0000 1a6c 0000 1a6c 0000 1c9e 0000 1c9e ...l...l........


00001560  745f 636f 6465 0000 6430 3030 3039 342e t_code..d000094.
                              ^^^^^^^^^^^^^^^^^
00001570  6f2f 2020 2020 2020 3130 3135 3930 3739 o/      10159079

MagDir/archives
<snip>

>(0x48l)  byte 0x64
>>(0x48l+7) leword 0x2e6f	import libray

What dou you think ?

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 ?


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