This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [patch] --enable-dynamic-string default for mingw-w64


2011/9/20 Charles Wilson <cwilso11@users.sourceforge.net>:
> On 9/20/2011 9:20 AM, JonY wrote:
>> On 9/20/2011 13:59, Kai Tietz wrote:
>>> 2011/9/20 JonY:
>>>> Its been used in the automated toolchain builds for sometime,
>>>> seems like a good idea to enable it by default. It can be
>>>> easily changed to match for all mingw as well if needed.
>>>
>>> This patch looks reasonable to me. Note that this is no approval
>>> for it, as I'm not a libstdc++ maintainer. ?But I can confirm
>>> that patch is ok from perspective of windows-target maintainer.
>>> Just one question I have here. ?Why do we enable this option only
>>> for w64 flavor? ?AFAIK is mingw.org also building their libstdc++
>>> with enabling this configure-option
>>
>> OK "i?86-*-mingw* | x86_64-*-mingw*)" then, any mingw.org
>> developers care to comment?
>>
>
> Unfortunately, while very old (3.x?) versions of mingw.org gcc used
> this option IIRC, neither the latest official, nor the immediately
> previous official mingw.org version were compiled with that option:
>
> ?../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++
> --disable-sjlj-exceptions --with-dwarf2 --enable-shared
> --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug
> --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
>
> ?../gcc-4.5.2/configure
> --enable-languages=c,c++,ada,fortran,objc,obj-c++
> --disable-sjlj-exceptions --with-dwarf2 --enable-shared
> --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug
> --enable-version-specific-runtime-libs --disable-werror
> --build=mingw32 --prefix=/mingw
>
>
> To match native mingw.org behavior, the cygwin->mingw.org-ish cross
> toolchain is configured as:
> Configured with:
> /usr/src/packages/mingw-gcc/mingw-gcc-4.5.2-1/src/gcc-4.5.2/configure
> --srcdir=/usr/src/packages/mingw-gcc/mingw-gcc-4.5.2-1/src/gcc-4.5.2
> --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
> --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
> --sysconfdir=/etc --datarootdir=/usr/share
> --docdir=/usr/share/doc/mingw-gcc -C --build=i686-pc-cygwin
> --host=i686-pc-cygwin --target=i686-pc-mingw32
> --with-sysroot=/usr/i686-pc-mingw32/sys-root
> --with-build-sysroot=/usr/i686-pc-mingw32/sys-root --disable-multilib
> --disable-win32-registry --enable-languages=c,c++,fortran,objc,obj-c++
> --enable-libgomp --disable-sjlj-exceptions --enable-libstdcxx-debug
> --enable-version-specific-runtime-libs --with-dwarf2 --disable-werror
> --enable-lto
>
>
> So, this would be a change in current mingw.org behavior. ?I *was*
> under the impression that this workaround for the old "can't pass
> empty strings across DLL boundary" problem[1] was no longer necessary
> in the gcc-4.x era, but I haven't tested the proposition. ?Was I wrong
> about that?

Yes.  If you read last comment of the thread you are citing, then you
would notice that for static-libstdc++ version the issue is still
present.  So to allow users to use also static-libstdc++ variant, this
option is still necessary.

> I'm not really opposed to making this change for i*86-pc-mingw -- and
> now's the time to do it, as the recently released 4.6.1 mingw.org gcc
> broke the C++ abi anyway, thanks to thiscall.

Here I am a bit curious?  How is 4.6.1 affected by new thiscall
calling-convention?  Is it just its presence in 4.6.x, or what?  As
the thiscall-convention ABI change for C++ is done in 4.7.x only, and
4.6.x shouldn't be affected by it.

Regards,
Kai


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