This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Ralf Habacker <Ralf dot Habacker at freenet dot de>
- Cc: cygwin at cygwin dot com
- Date: Wed, 12 Feb 2003 19:57:11 -0500
- Subject: Re: [avail for test] libtool-devel-20030121-1
- References: <003701c2d26f$d184f670$0a1c440a@BRAMSCHE>
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.
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.
BTW: Do you know which libraries are also hybrid execpt of cygwin1.dll ?
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?
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"
That mean, we onbly have to figure out the relative pointer to the 'dll_iname'
When I have time, I will look into the coff file format or is someone else here,
who can give a pointer to this ?
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html