binutils status?

[Charles Wilson]

Danny Smith wrote:

 >>> I think we should keep the warnings if --auto-import isn't  specified
 >>>  on the command line but get rid of them if it is  explictly
 >>> specified.  Including --auto-import on the command  line would
 >>> indicate that the user knows what they're doing,  so they don't
 >>>  need to see warnings.
 >>>
 >> Works for me.
 >>
 >>
 > Agree  This addresses my main concern of no warnings and is similar
 > to the way --enable-stdcall-fixup works now.


How about this?

Since the tests in /bfd/ are against pei386_auto_import != 0, effectively:

./bfd/cofflink.c:         if (!h && info->pei386_auto_import)
./bfd/linker.c:   if (info->pei386_auto_import)

We can use the same
-1 == default, 1 == explicitly enabled, 0 == explicitly disabled
formuation that stdcall_fixup uses.

I also downgraded the message to 'info_msg' on stdout, instead of
'einfo' on stderr (this may be overkill given the 0/1/-1 changes)

Finally, I'm not sure if link_info.pei386_auto_import should be set to
'0' or to '-1' in ldmain.c.  It is *reset* to '-1' at the beginning of

gld_${EMULATION_NAME}_before_parse()

in pe.em...The question is, since pei386_auto_import is part of the 
global link_info structure, should a Solaris linker have that variable 
set to '0' or to '-1'?

I don't think it makes any functional difference, but I'm unsure of the
stylistic issues.

--Chuck
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: binutils.patch
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20020520/4a7e6e9b/attachment.ksh>