getopt: ugly linker messages

getopt: ugly linker messages

[Bryan Higgins]

How can I suppress the linker messages

Info: resolving _opterr by linking to __imp__opterr (auto-import)
Info: resolving _optarg by linking to __imp__optarg (auto-import)
Info: resolving _optopt by linking to __imp__optopt (auto-import)
Info: resolving _optind by linking to __imp__optind (auto-import)

which now appear?
--------
Bryan Higgins, Albany, California

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

Re: getopt: ugly linker messages

[Christopher Faylor]

On Thu, Sep 18, 2003 at 12:53:22PM -0700, Bryan Higgins wrote:
>How can I suppress the linker messages
>
>Info: resolving _opterr by linking to __imp__opterr (auto-import)
>Info: resolving _optarg by linking to __imp__optarg (auto-import)
>Info: resolving _optopt by linking to __imp__optopt (auto-import)
>Info: resolving _optind by linking to __imp__optind (auto-import)
>
>which now appear?

#include <getopt.h>

and don't define any of the getopt variables yourself.

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

Re: getopt: ugly linker messages

[Charles Wilson]

Christopher Faylor wrote:
> On Thu, Sep 18, 2003 at 12:53:22PM -0700, Bryan Higgins wrote:
> 
>>How can I suppress the linker messages
>>
>>Info: resolving _opterr by linking to __imp__opterr (auto-import)
>>Info: resolving _optarg by linking to __imp__optarg (auto-import)
>>Info: resolving _optopt by linking to __imp__optopt (auto-import)
>>Info: resolving _optind by linking to __imp__optind (auto-import)
>>
>>which now appear?
> 
> 
> #include <getopt.h>
> 
> and don't define any of the getopt variables yourself.
> 

In general, these 'resolving blah by linking to __imp_blah' messages can 
be suppressed by using the '--enable-auto-import' flag to ld (or 
-Wl,--enable-auto-import' for gcc).

If you do that, ld figures that you really know what you're doing, and 
don't need the 'informational' messages concerning auto-import.

--
Chuck


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

Re: getopt: ugly linker messages

[Corinna Vinschen]

On Thu, Sep 18, 2003 at 11:48:00PM -0400, Charles Wilson wrote:
> >On Thu, Sep 18, 2003 at 12:53:22PM -0700, Bryan Higgins wrote:
> >>Info: resolving _opterr by linking to __imp__opterr (auto-import)
> 
> In general, these 'resolving blah by linking to __imp_blah' messages can 
> be suppressed by using the '--enable-auto-import' flag to ld (or 
> -Wl,--enable-auto-import' for gcc).
> 
> If you do that, ld figures that you really know what you're doing, and 
> don't need the 'informational' messages concerning auto-import.

Since that auto-import is working fine for a long while now and since
this sort of auto-import is normal for any other platform... isn't there
a time we can get rid of that message?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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

Re: getopt: ugly linker messages

[Charles Wilson]

Corinna Vinschen wrote:

> Since that auto-import is working fine for a long while now and since
> this sort of auto-import is normal for any other platform... isn't there
> a time we can get rid of that message?

auto-import is not the default for all pei386 versions of binutils, 
particularly mingw.

And auto-import is in no way "normal".  It provides functionality that, 
on the surface, appears to emulate the normal behavior of other 
platforms -- but under the hood, it's a bizzarre beast.

So, taking those two points into consideration, I'm not sure what the 
right thing to do is, without ticking somebody on some platform off. 
The current compromise seems to be mostly acceptable.

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.)

--
Chuck



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

Re: getopt: ugly linker messages

[Christopher Faylor]

On Fri, Sep 19, 2003 at 09:49:25AM -0400, Charles Wilson wrote:
>Corinna Vinschen wrote:
>
>>Since that auto-import is working fine for a long while now and since
>>this sort of auto-import is normal for any other platform... isn't there
>>a time we can get rid of that message?
>
>auto-import is not the default for all pei386 versions of binutils, 
>particularly mingw.
>
>And auto-import is in no way "normal".  It provides functionality that, 
>on the surface, appears to emulate the normal behavior of other 
>platforms -- but under the hood, it's a bizzarre beast.
>
>So, taking those two points into consideration, I'm not sure what the 
>right thing to do is, without ticking somebody on some platform off. 
>The current compromise seems to be mostly acceptable.
>
>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.

cgf

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

Re: getopt: ugly linker messages

[Corinna Vinschen]

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.

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.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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

Re: getopt: ugly linker messages

[Larry Hall]

At 11:18 AM 9/19/2003, Christopher Faylor you wrote:
>On Fri, Sep 19, 2003 at 09:49:25AM -0400, Charles Wilson wrote:
>>Corinna Vinschen wrote:
>>
>>>Since that auto-import is working fine for a long while now and since
>>>this sort of auto-import is normal for any other platform... isn't there
>>>a time we can get rid of that message?
>>
>>auto-import is not the default for all pei386 versions of binutils, 
>>particularly mingw.
>>
>>And auto-import is in no way "normal".  It provides functionality that, 
>>on the surface, appears to emulate the normal behavior of other 
>>platforms -- but under the hood, it's a bizzarre beast.
>>
>>So, taking those two points into consideration, I'm not sure what the 
>>right thing to do is, without ticking somebody on some platform off. 
>>The current compromise seems to be mostly acceptable.
>>
>>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.


My $.02 is that if auto import use is something that's worth questioning 
when it occurs, then the message should be a warning and not just info.  
It would signal a valid reason to inspect what happened and try to clean 
it up.  If one is not so motivated, it can be ignored like any other 
warning and the risk assumed.

If it's less of an issue than this, then the info message just raises
questions and generates traffic on the list.  While the warning may still
do this, it would then be clear to the poster and those reading the post
that this is something that should be remedied.  So my feeling is that if
this doesn't deserve the status of a warning, the informational message
should be off by default.  I don't see the problem of data variable import
as being a major issue for the clueless either.  If it is, the message won't
clarify anything for them so we'll still see list traffic about it either 
way.

Somehow, I don't believe my single opinion on this constitutes a consensus
so I'm sorry if this is just noise.

Now back to the regularly scheduled Cygwin email traffic already in 
progress...


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


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

RE: getopt: ugly linker messages

[Ivan Warren]

> 
> 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.
> 
> cgf

And.. Hmmm..

I *think* auto import of data variables may be somewhat broken (and declared
import of data variables too) if 

1) The import library is stripped with --strip-unneeded
   and/or
2) The import is from another DLL (.exe -> .dll[func] -> .dll[data])

(See msg dated 9/17/03 which seems to have been drowned.. There is a test
case in it)

--Ivan


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

RE: getopt: ugly linker messages

[Ivan Warren]

> And.. Hmmm..
>
> I *think* auto import of data variables may be somewhat broken
> (and declared
> import of data variables too) if
>
> 1) The import library is stripped with --strip-unneeded
>    and/or
> 2) The import is from another DLL (.exe -> .dll[func] -> .dll[data])
>
> (See msg dated 9/17/03 which seems to have been drowned.. There is a test
> case in it)
>
> --Ivan
>
Okies...

Does anyone know at least if it's a cygwin or core binutils issue ? Or if I
am at least looking in the right direction ?

--Ivan


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

RE: getopt: ugly linker messages

[Ivan Warren]

> -----Original Message-----
> From: cygwin-owner@cygwin.com 
> [mailto:cygwin-owner@cygwin.com] On Behalf Of Ivan Warren
> Sent: Saturday, September 20, 2003 2:43 AM
> To: cygwin@cygwin.com
> Subject: RE: getopt: ugly linker messages
> 
> 
> > And.. Hmmm..
> >
> > I *think* auto import of data variables may be somewhat broken (and 
> > declared import of data variables too) if
> >
> > 1) The import library is stripped with --strip-unneeded
> >    and/or
> > 2) The import is from another DLL (.exe -> .dll[func] -> .dll[data])
> >
> > (See msg dated 9/17/03 which seems to have been drowned.. 
> There is a 
> > test case in it)
> >
> > --Ivan
> >
> Okies...
> 
> Does anyone know at least if it's a cygwin or core binutils 
> issue ? Or if I am at least looking in the right direction ?
> 
> --Ivan
> 
> 

<rant>
Sniff.. Why am I being ignored ?

I thought I had a quite thoroughly documented problem.

I have a test case which I posted 4 days ago..
(http://cygwin.com/ml/cygwin/2003-09/msg01132.html) and I asked again
yesterday if I was at least looking in the right direction. But it's just
like the messages are not even getting there (I know they are - they are on
the mailing list archive..)

I know this is a community effort and that no-one is obliged to answer (no,
I didn't go for the pay support.. I am working on an open source project, so
I don't have the monetary resource to spend).

But it's just frustrating.

The problem is I don't really understand the internals of the PE 386 binder
(or I would surelly propose a patch).

Also if the problem is a core "binutils" issue, please someone tell me (and
then I'll go bug the binutils folks !)

</rant>

However, in the meanwhile I have a workaround, so it's not an emergency..

(Workaround : The issue lies when the Makefile is generated with automake &
libtool - the 'make strip' insist on stripping the import library - the
workaround involves patching the libtool.m4 AC_LIBTOOL_SYS_LIBSTRIP macro to
force it NOT to strip libs on cygwin).

--Ivan


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

Re: getopt: ugly linker messages

[Christopher Faylor]

On Sat, Sep 20, 2003 at 09:32:52PM +0200, Ivan Warren wrote:
>I know this is a community effort and that no-one is obliged to answer
>(no, I didn't go for the pay support..  I am working on an open source
>project, so I don't have the monetary resource to spend).

Bingo.  Apparently, no one knows the answer to your question and,
apparently, no one is interested in researching the problem for you.
Also, as you noted, it has a trivially easy workaround -- don't strip
import libraries.

"Wah! No one is paying attention to me!" rants don't really help your
case, much.  Nor does sending messages to threads which have little to
do with your problem.

As far as your specific question on who to bug, yes, obviously, this is
a binutils problem.

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

RE: getopt: ugly linker messages

[Ivan Warren]

> 
> Bingo.  Apparently, no one knows the answer to your question 
> and, apparently, no one is interested in researching the 
> problem for you. Also, as you noted, it has a trivially easy 
> workaround -- don't strip import libraries.

Right..

- No one is interrested in researching the problem for me.. Now..
WAITAMINUTE ! I spent the entire week trying to find how I could document
this the best I could so that the entire community may benefit from it.
Because I am no ld/strip/binutils wiz doesn't mean I don't make any research
in the problems I run into. I documented and made an entirelly self
contained test case which demonstrates the problem. This is what *YOU* ask
from other people reporting problems (and it does make sense). I tried to
make it as easy as possible for you & your team to determine if this was
something that involved your portion of the software or not.

- I don't strip the libraries. Libtool does it. If you want an
autoconf/automake/libtool case which demonstrates this, I could do it.. But
to what avail ? As no-one is interrested in looking into a reported problem
(for which I may not be the only one affected.). The test case has a strip
in it because it is a TEST CASE ! The fix cannot be a to patch libtool to
workaround a flaw in the cygwin binutils implementation (I have all the
reasons to believe --strip-unneeded should work on import libraries..), that
would be a Bad Thing (tm)..

> 
> "Wah! No one is paying attention to me!" rants don't really 
> help your case, much.  Nor does sending messages to threads 
> which have little to do with your problem.

The thread as something to do with the problem. It exhibits somewhat
identical symptoms and it involves the same line of tools. The 'auto-import'
of .data and/or .bss defined sections is involved. It's not 'getopt' which
is the concern, it's the linker issuing 'ugly' messages - I just pushed it a
bit further and wanted people looking at what happened when you do push it
further.

However, getopt is ALSO involved. example would be if you build a project
which has only very little code in the executable but the rest of it in a
DLL/shared library. If the 'getopt' is invoked from that DLL, the program
will either not link ot crash at run time (provided you let libtool strip
the libraries).

As to the rant, it DID help : at least, I did get a response. The response
is Off Topic, but at least, it's a response.

> 
> As far as your specific question on who to bug, yes, 
> obviously, this is a binutils problem.

Thank for spending a little bit of effort informing me. I will not waste
more of your precious time. Hopefully, I'll get a better response from the
binutils folks who may find a solution to an issue that DOES affect cygwin
(and any other environment using the PE 386 object format).

--Ivan


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

Re: getopt: ugly linker messages

[Christopher Faylor]

On Sat, Sep 20, 2003 at 10:51:43PM +0200, Ivan Warren wrote:
>>Bingo.  Apparently, no one knows the answer to your question and,
>>apparently, no one is interested in researching the problem for you.
>>Also, as you noted, it has a trivially easy workaround -- don't strip
>>import libraries.
>
>Right..
>
>- No one is interrested in researching the problem for me..  Now..
>WAITAMINUTE ! I spent the entire week trying to find how I could
>document this the best I could so that the entire community may benefit
>from it.  Because I am no ld/strip/binutils wiz doesn't mean I don't
>make any research in the problems I run into.

Sigh.  By "research", I meant dive into the binutils code and figure out
what is going wrong.

>Hopefully, I'll get a better response from the binutils folks who may
>find a solution to an issue that DOES affect cygwin (and any other
>environment using the PE 386 object format).

You already posted to the binutils mailing list, remember?

http://sources.redhat.com/ml/binutils/2003-09/msg00296.html

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

RE: getopt: ugly linker messages

[Ivan Warren]

> 
> Sigh.  By "research", I meant dive into the binutils code and 
> figure out what is going wrong.

Geez.. You kidding me ? I mean, I wouldn't mind doing that.. But it would
probably take me a month or so to just figure out the basics of how it
works... Not to mention I have but very little understanding of how the 386
PE works (just enough to figure out there might be a problem with it when I
see one..). I really thought it'd be smarter to ask folks who are more
comfortable with it. (ps : I already did it for some gcc issues.. And it
took me ages just to figure out the architecture.. I'm pretty sure it'd be
the same with binutils)..

If I had made all that searching, spent a lot of time sorting out a
"binutils in 386 PE" environment issue, then I'm not spending time on the
project I usually work on.. And if I had found the issue & had a patch, I
definitelly wouldn't have asked a question. I would have proposed a patch.

> 
> >Hopefully, I'll get a better response from the binutils 
> folks who may 
> >find a solution to an issue that DOES affect cygwin (and any other 
> >environment using the PE 386 object format).
> 
> You already posted to the binutils mailing list, remember?

Yeah.. Of course I do remember that.. (not senile yet ;-) ).. But
unfortunatelly, I made the same mistake I did here : I told them I *DID*
post in the other forum. Thus leading to the effect that each list thinks
it's a problem that is in the other group field of expertise.

So my option is now to tell the binutils folks that the cygwin folks are
declaring this issue to be a binutils core issue and that it has nothing to
do with cygwin (although it does affect it).. Am I correct ?

--Ivan


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

Re: getopt: ugly linker messages

[Christopher Faylor]

On Sun, Sep 21, 2003 at 01:43:54AM +0200, Ivan Warren wrote:
>>Sigh.  By "research", I meant dive into the binutils code and figure
>>out what is going wrong.
>
>Geez..  You kidding me ?  I mean, I wouldn't mind doing that..

Are you not a native English speaker or are you just trolling now?

This is what I said:

"Apparently, no one knows the answer to your question and, apparently,
no one is interested in researching the problem for you."

In this context, it is clear what I was saying.  I was saying that no
one *else* wanted to *debug* your problem.  I wasn't saying "You do it",
even though, realistically speaking, that is probably your best
alternative.

(and now here comes another round of "I've already worked so hard and I
don't know nothing about no binutils"...)

>>You already posted to the binutils mailing list, remember?
>
>Yeah..  Of course I do remember that..  (not senile yet ;-) )..  But
>unfortunatelly, I made the same mistake I did here : I told them I
>*DID* post in the other forum.  Thus leading to the effect that each
>list thinks it's a problem that is in the other group field of
>expertise.

You're assuming here.  This is obviously a binutils issue.  The fact
that no one responded to it, is very likely the same reason that no
one responded here.

>So my option is now to tell the binutils folks that the cygwin folks
>are declaring this issue to be a binutils core issue and that it has
>nothing to do with cygwin (although it does affect it)..  Am I correct
>?

I would assume that anyone in the binutils mailing list who saw errors
with import libraries would not assume "Aha! It's obviously a problem
with the Cygwin DLL! I don't have to worry about this one".  So, anyone
who was interested in this problem would already be clear on where the
fault lies from your original message.

Just to be clear: I do provide the binutils package to the cygwin
community but I don't have the time or inclination to track the problem
down.  There are a few people reading the binutils mailing list who are
more facile with the code than I.  They are, of course, also volunteers.

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

RE: getopt: ugly linker messages

[Ivan Warren]

> 
> Are you not a native English speaker or are you just trolling now?
> 
> This is what I said:
> 
> "Apparently, no one knows the answer to your question and, 
> apparently, no one is interested in researching the problem for you."
> 
> In this context, it is clear what I was saying.  I was saying 
> that no one *else* wanted to *debug* your problem.  I wasn't 
> saying "You do it", even though, realistically speaking, that 
> is probably your best alternative.

I was just trying to uncover a problem that I ran into so that others don't
run into it. I have a workaround, so I am not directly affected. So it is
not *my* problem per-se.

> 
> (and now here comes another round of "I've already worked so 
> hard and I don't know nothing about no binutils"...)

Obviously this is getting nowhere. I wasn't whining, I was just explaining
my frustration.

> 
> >>You already posted to the binutils mailing list, remember?
> >
> >Yeah..  Of course I do remember that..  (not senile yet ;-) )..  But 
> >unfortunatelly, I made the same mistake I did here : I told them I
> >*DID* post in the other forum.  Thus leading to the effect that each 
> >list thinks it's a problem that is in the other group field of 
> >expertise.
> 
> You're assuming here.  This is obviously a binutils issue.  
> The fact that no one responded to it, is very likely the same 
> reason that no one responded here.

That is correct, this is one hypothesis. I reported a problem for which I am
not affected (because I have a workaround), but possibly noone is
interrested because it mainly affects the cygwin community. Yes.. I am
'assuming'.. But it's irrelevant. In either case the problem won't be fixed
and someone else, one day, will run into it.

> 
> >So my option is now to tell the binutils folks that the cygwin folks 
> >are declaring this issue to be a binutils core issue and that it has 
> >nothing to do with cygwin (although it does affect it)..  Am 
> I correct 
> >?
> 
> I would assume that anyone in the binutils mailing list who 
> saw errors with import libraries would not assume "Aha! It's 
> obviously a problem with the Cygwin DLL! I don't have to 
> worry about this one".  So, anyone who was interested in this 
> problem would already be clear on where the fault lies from 
> your original message.
> 
> Just to be clear: I do provide the binutils package to the 
> cygwin community but I don't have the time or inclination to 
> track the problem down.  There are a few people reading the 
> binutils mailing list who are more facile with the code than 
> I.  They are, of course, also volunteers.
> 

I am also a volunteer..

Never mind..

I'll drop the subject. It was obviously a bad idea to report a problem which
could affect the cygwin community. Again, I have a workaround, so I can live
with it. The same goes for ld merging .data globals between DLLs which
obviously doesn't work.. There is a problem in that field, and I have a test
case. But I have a workaround so I'll just keep it to myself.

And well.. I think I was wrong in *assuming* that this mailing list dealt
with the cygwin project as a whole. It seems that if it's not a problem with
the cygwin dll itself, then it doesn't belong here.

--Ivan


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

PE Linker and/or runtime error when importing data from DLL (was RE: getopt: ugly linker messages) - hopefully solved.

[Ivan Warren]

My apologies.

I finally decided to look for myself in binutils.. And found a way to fix
the issue.

I proposed a patch to the binutils folks.

--Ivan


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

Re: getopt: ugly linker messages

[Bryan Higgins]

On Thu, 18 Sep 2003 15:56:07 -0400, Christopher Faylor wrote:

>On Thu, Sep 18, 2003 at 12:53:22PM -0700, Bryan Higgins wrote:
>>How can I suppress the linker messages
>>
>>Info: resolving _opterr by linking to __imp__opterr (auto-import)
>>Info: resolving _optarg by linking to __imp__optarg (auto-import)
>>Info: resolving _optopt by linking to __imp__optopt (auto-import)
>>Info: resolving _optind by linking to __imp__optind (auto-import)
>>
>>which now appear?
>
>#include <getopt.h>
>
>and don't define any of the getopt variables yourself.

Since POSIX getopt is handled in unistd.h, shouldn't the magic appear there?

>there is no getopt(3)

Maybe there needs to be to document the need for getopt.h?

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

Re: getopt: ugly linker messages

[Christopher Faylor]

On Thu, Sep 18, 2003 at 01:08:14PM -0700, Bryan Higgins wrote:
>On Thu, 18 Sep 2003 15:56:07 -0400, Christopher Faylor wrote:
>>On Thu, Sep 18, 2003 at 12:53:22PM -0700, Bryan Higgins wrote:
>>>How can I suppress the linker messages
>>>
>>>Info: resolving _opterr by linking to __imp__opterr (auto-import)
>>>Info: resolving _optarg by linking to __imp__optarg (auto-import)
>>>Info: resolving _optopt by linking to __imp__optopt (auto-import)
>>>Info: resolving _optind by linking to __imp__optind (auto-import)
>>>
>>>which now appear?
>>
>>#include <getopt.h>
>>
>>and don't define any of the getopt variables yourself.
>
>Since POSIX getopt is handled in unistd.h, shouldn't the magic appear there?

You can use unistd.h if you want.  If you knew this already why were you
asking the question?

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

Re: getopt: ugly linker messages

[Bryan Higgins]

Christopher Faylor wrote:

>You can use unistd.h if you want.  If you knew this already why were you
>asking the question?

From the gnu getopt(3) man page (mysteriously missing in cygwin):

       #include <unistd.h>

       int getopt(int argc, char * const argv[],
                  const char *optstring);

       extern char *optarg;
       extern int optind, opterr, optopt;

If one does this with the latest cygwin, ugly linker messages result.

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

Re: getopt: ugly linker messages

[Rolf Campbell]

Bryan Higgins wrote:
> Christopher Faylor wrote:
> 
> 
>>You can use unistd.h if you want.  If you knew this already why were you
>>asking the question?
> 
> 
> From the gnu getopt(3) man page (mysteriously missing in cygwin):
> 
>        #include <unistd.h>
> 
>        int getopt(int argc, char * const argv[],
>                   const char *optstring);
> 
>        extern char *optarg;
>        extern int optind, opterr, optopt;
> 
> If one does this with the latest cygwin, ugly linker messages result.
> 

I believe you are interpreting the man page incorrectly.  You should 
only include <unistd.h> and not the 4 lines below that.  The rest of the 
lines are only to show you the signature.



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

Re: getopt: ugly linker messages

[Danny Smith]

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: <200309181953.h8IJrMWa017255@bolt.sonic.net> <20030918195607.GA11311@redhat.com>
<3F6A7C70.7030901@cwilson.fastmail.fm> <20030919064843.GM9981@cygbert.vinschen.de>
<3F6B0965.3050304@cwilson.fastmail.fm> <20030919151803.GE17232@redhat.com> 
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/

Re: getopt: ugly linker messages

[Corinna Vinschen]

On Sat, Sep 20, 2003 at 07:32:04AM +1000, Danny Smith wrote:
> > 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.
> 
> Overriding the attribute also prevents an ICE in gcc so I believe the
> behaviour is justified. There are actually testcases in the gcc

Well... I'm not quite sure if circumventing a potential compiler bug
actually justifies a potential misbehaviour...

> 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++;
> }

The above case is imho somewhat borderline.  It defines Biz with
dllimport, but it's missing an `extern'.  What I mean is, having two
extern declarations, one with and the second without dllimport.  The
second should not touch the already existing declaration.  I don't
see why this should result in an ICE.  The other cases in the testcase
are absolutely ok, though.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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