This is the mail archive of the cygwin 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: Bug in gcc and/or binutils?


* 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/


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