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

[Charles Wilson]

Ralf Habacker wrote:

> This depends on how the hybrid lib is created. If it starts with the static
> object files, it would be identified as static, if it starts with the import
> library as import library.

right.

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

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 ?

Can't help you there.  I'd hunt around in the binutils/bfd 
sources...because you're looking in an 'ar archive' for the first bfd, 
and the in that bfd for the string "_dll_iname"

--Chuck


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