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:

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.

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?


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


Unsubscribe info:
Bug reporting:

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