This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: 1.5.0 - showstopper?
- From: "Max Bowsher" <maxb at ukf dot net>
- To: "Charles Wilson" <cygwin at cwilson dot fastmail dot fm>,<cygwin-developers at cygwin dot com>
- Date: Thu, 17 Jul 2003 07:40:46 +0100
- Subject: Re: 1.5.0 - showstopper?
- References: <20030717041130.21AF5739CE@smtp.us2.messagingengine.com>
Charles Wilson wrote:
> Corinna said:
>> I'm curious, does that still make sense now? Should libcygwin.a be added
>> to that list or is the problem ultimativly fixed by adding the
appropriate
>> symbols to libcygwin.a? Somehow I'm missing the conclusion in this
>> discussion.
>
> cgf's fix to newsym and rmsym solved this problem. I still believe that
> libcygwin.a should be in ld's exclude list, but it's not actually
> NECESSARY to do that, given cgf's fix.
>
> Max said:
>> There is at least one other problem that I think would be avoided if
>> libcygwin was in the excludes: currently, if you build a dll which uses
>> getopt, getopt will be reexported from the dll. Now try to link to the
dll -
>> the linker complains because getopt is available in both the dll and
>> libcygwin.a.
>
> Yes, but in that case you're simply pushing the problem farther down the
> food chain. What if we did this, and you try to build libfoo and libbar
> (which both export getopt or some other identical symbol). Then, you
> link baz.exe against both libfoo and libbar....boom!
Was I? Oops. I had imagined that the exclude would prevent the initial
export in the first place. Guess I need to understand ld better before
opening my mouth! :-)
Max.