Re: getopt: ugly linker messages
From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
To: cygwin at cygwin dot com
Date: Fri, 19 Sep 2003 17:34:09 +0200
Subject: Re: getopt: ugly linker messages
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Reply-to: cygwin at cygwin dot com
--------------------------------------------------------------------------------
On Fri, Sep 19, 2003 at 11:18:03AM -0400, Christopher Faylor wrote:
> > On Fri, Sep 19, 2003 at 09:49:25AM -0400, Charles Wilson wrote:
> > >Perhaps a cygwin-special (e.g. doesn't go back to binutils CVS) patch?
> > >In that case, it's a one-liner -- just change the default value of
> > >link_info.pei386_auto_import to '1' instead of '-1' in pe.em (you might
> > >also need to change the default in ldmain.c, but I don't think that's
> > >necessary.)
> >
> > I'm willing to do this but I have the same reservations that I think
> > you're expressing above, Chuck. Also, the auto-import of data variables
> > is slower than a normal dllimport so I don't feel real comfortable about
> > making this the default.
> >
> > I don't feel really strongly about this however, so if the consensus is
> > that this should be turned on, I'll make a cygwin-specific change to
> > binutils.
>
I share Chris's opinion about the warning. To me the auto-import
feature has always been a last resort. Usually, I want to know about
the missing attribute in declarations.
> No need. It's just a bit annoying.
>
> However, isn't that an error in binutils? If I have
>
> extern int __declspec(dllimport) foo;
>
> and 100 lines later I have a
>
> extern int foo;
>
> why is then the information about the __declspec removed? Shouldn't
> that information be kept? AFAIK, the "extern" storage class shouldn't
> change any information already known about the variable in question.
> It should complain about e.g. conflicting types but it should never
> change what's already there.
That is done in GCC itself, noy binutils. It is done that way to conform
to MS 'rules' about how ___declspec(dllimport) is handled.
Overriding the attribute also prevents an ICE in gcc so I believe the
behaviour is justified. There are actually testcases in the gcc
testsuite that test whether this happens
Here's one (g++.dg/ext/dllimport2.C):
// { dg-do compile { target i?86-*-cygwin* i?86-*-mingw*} }
// PR c++/9738 Dllimport attribute is overriden by later definition/redeclaration
void __attribute__((dllimport)) Bar(void);
void __attribute__((dllimport)) Baz(void);
__attribute__((dllimport)) int Biz;
__attribute__((dllimport)) int Boz;
void Foo(void)
{
Bar();
Baz();
Biz++;
Boz++;
}
void Bar(void)
{ // { dg-warning "defined" }
}
void Baz(void); // { dg-warning "redeclared" }
extern int Biz; // { dg-warning "redeclared" }
int Boz; // { dg-warning "defined" }
void foo()
{
Biz++;
}
Danny
>
> Corinna
>
>
http://search.yahoo.com.au - Yahoo! Search
- Looking for more? Try the new Yahoo! Search
--
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/
