This is the mail archive of the 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: getopt: ugly linker messages

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: <> <>
<> <>
<> <> 
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)
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()


> Corinna
> - Yahoo! Search
- Looking for more? Try the new Yahoo! Search

Unsubscribe info:
Problem reports:

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