Mail Archives: cygwin/2005/09/15/23:30:11
FWIW, this is not a "recent" regression --- nothing "changed" in
binutils or gcc. I just installed binutils-20040725-2 from the Cygwin
Time Machine and got identical output. This was a surprise to me:
*I* thought that we no longer needed the DATA flag in .def files because
binutils was smart enough to figure that out on its own -- obviously, it
does so when auto-EXporting, so why can't it do so when using a .def
file? Using .def files turns off the auto-EXport logic (which it
should, because if you specify a specific set of exports you don't want
binutils adding a few more on its own).
However, this "turn off the auto-EXport logic" seems to include turning
off the "is this symbol a DATA item or a function" logic. I never knew
that.
So, given my mistaken understanding, I wanted to know if this was a
recent "regression" in binutils. But, it's always been like that -- it
is not a regression at all.
The question is, should binutils be "fixed" to keep the "is this symbol
a DATA item or a function" logic active even when using .def files? I'm
not sure the answer is yes. Wouldn't this imply giving binutils
override power, if I marked a *function* symbol with 'DATA' in the .def
file -- the converse of the case described by Gerritt? Basically, we'd
be making binutils IGNORE any 'DATA' (or lack thereof) decoration in the
.def file, and just "do what it thinks is best".
This doesn't seem to be the path of wisdom, to me. If I'm using a .def
file, it's likely because in the specific situation I don't trust
binutils to "do what it thinks is best"; if I did, I'd let the
auto-EXport logic do its thing. So, to me it looks more and more that
libtool ought to be more careful when creating its .def file...
Which is the long-winded way of saying that I agree with Gerritt.
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -