This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: 64bit: cygstdc++-6.dll
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 11 Apr 2013 12:16:39 +0200
- Subject: Re: 64bit: cygstdc++-6.dll
- References: <514C9EB4 dot 4000203 at gmail dot com> <20130323095047 dot GC2387 at calimero dot vinschen dot de> <514EBA42 dot 7010701 at users dot sourceforge dot net> <20130325085219 dot GF2387 at calimero dot vinschen dot de> <5163BE7B dot 3020809 at gmail dot com> <5163EDD0 dot 4040303 at users dot sourceforge dot net> <51643DC1 dot 2070407 at gmail dot com> <5165377D dot 3080208 at users dot sourceforge dot net> <516589ED dot 3090909 at gmail dot com> <20130410161622 dot GC5138 at calimero dot vinschen dot de>
- Reply-to: cygwin-apps at cygwin dot com
On Apr 10 18:16, Corinna Vinschen wrote:
> On Apr 10 16:49, Dave Korn wrote:
> > On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:
> >
> > > Could you explain the necessity of the dllimport's in the same patch?
> >
> > The idea is to one day be able to move away from having auto-import enabled
> > by default in binutils, so that .rdata can go back into the read-only-mapped
> > .rdata section and be shared between processes as it ought.
>
> Doesn't that affect applications which use something like
>
> extern int optind;
>
> in their code? Kai did quite a job to get this working on x86_64 by
> implementing the medium/large code models for x86_64, and Cygwin's
> x86_64 gcc uses the medium code model by default. Disabling this again
> would be rather counterproductive.
What about this issue? If the idea is to revert all automatism which
allows to declare external variables in DLL s without dllimport, then
I don't think that's a good idea for Cygwin.
If I misunderstand the issue, please say so.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat