Mail Archives: cygwin/2005/09/16/05:50:31
* Charles Wilson wrote on Friday, September 16, 2005 05:28 CEST:
> 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.
Oh, I can see how you think I thought it was a regression. But I
didn't, I was having the same trouble before upgrading the install
and only upgraded to check if the behaviour had changed. Sorry
for the confusion...
> 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 Gerrit.
Yes, I also agree. I too can see the value of not overriding the
explicit input given by the user. Thanks everyone for clarifying
things.
So, libtool needs a fix...
Cheers,
Peter
--
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 -