This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin, libtool, dlpreopen, and .rdata
Brian Ford wrote:
On Wed, 22 Sep 2004, Charles Wilson wrote:
[cygwin list: I'm CC'ing this so that it goes into the archives, but
it's pretty technical about the innards of libtool...]
This doesn't seem libtool related at all to me (other than it's a gcc bug
that affects libtool).
Oh, except for the fact that there's a libtool patch included in the
email. Besides, it's not really a gcc bug; it's a new feature, that
does exactly what it should do -- except that it shouldn't be used in te
way that libtool is forcing it to be used. const "variables" exported
from a DLL absolutely should go in .rdata. Const "variables" in an
application absolutely should go in .rdata. No problems; and many benefits.
It's when an application declares a variable const, which is supposed to
hold the address of a DATA item imported from a DLL, that is the problem
-- because, thanks to the behind-the-scenes runtime-reloc stuff, *it
isn't really const*. In that case, it should not be declared const.
Libtool creates a little file that declares a const "variable" which
holds an address that falls under the definition above. Libtool
shouldn't do that -- at least until gcc/ld get a WHOLE lot smarter (and
With newer gcc's (cygwin version numbers 3.3.3-3, 3.4.1-1, but not
3.3.1-3), const variables are placed in an .rdata section. This causes
problems when those variables contain references to OTHER vars that are
imported from a dll -- because the runtime relocation machinery can't
fixup the address, since the variable holding the address is const --
and is in .rdata!
Yes, I see. I hope Danny Smith might weigh in here?
 DATA items imported into an app, when the DATA item itself is in the
DLL's .rdata section, is what is addressed by Danny's binutils patch.
The problem I'm pointing out is the opposite, and concerns the *pointer*
that should hold the address of the DLL's DATA item. That pointer is in
the application, and is declared const -- and therefore goes into the
*application's* .rdata section. Where the runtime-reloc machinery
can't update it.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html