| Message ID | orzhvtnnk2.fsf@lxoliva.fsfla.org |
|---|---|
| State | New |
| Headers | show |
| Series | introduce --enable-mingw-full32 to default to --large-address-aware | expand |
A new configure option needs documenting in install.texi.
On 10/05/2018 02:18 AM, Alexandre Oliva wrote: > Add a configure knob for mingw32 and 64 toolchains to default passing > --large-address-aware to the linker, when creating 32-bit binaries. > -Wl,--disable-large-address-aware can still reverse its effects. > > I've tested this with cross i686-pc-mingw32-gcc and > x86_64-w64-mingw64-gcc (is this the usual triplet name?), observing the > flags passed by gcc to the linker when asked to create an executable > program or a dynamic library, in 32- or, with the latter compiler, in > 64-bit mode. > > > I wonder if it makes any sense to extend/rename the configure flag to > apply to cygwin as well, though it should default to enabled for that > platform. > > I also wonder if it makes sense, at this point, for mingw to default to > --large-address-aware (I guess not, but it doesn't hurt to ask, does it? > :-) > > Yet another idea that comes to mind is to introduce gcc flags, say > -m32full and -m31, to imply -m32 and also pass either > --large-address-aware or --disable-large-address-aware, respectively, to > the linker. > > I suppose it might also make sense to approach this issue from the > linker, rather than from GCC, enabling its default to be configured. > Would that be preferred? I thought tweaking GCC would be better, for > the flag would be visible with -v, both the one passed to the linker and > the one passed to GCC configure. It wouldn't be quite as visible as a > linker configuration knob. > > > Given all this, is this patch below ok to install, or should I make > changes. I've included the configure and config.in changes because > they're small enough. > > Below this first patch, I enclose another patch for cygming.h. > They're both OK as far as I can see. I just don't like the configure name implying all 32bit pointers are used by userspace. Perhaps just --enable-large-address-aware? Be sure to also update the documentation as Joseph says.
On Oct 5, 2018, Joseph Myers <joseph@codesourcery.com> wrote: > A new configure option needs documenting in install.texi. Ah, yes, thanks for the reminder. On Oct 6, 2018, JonY <10walls@gmail.com> wrote: > They're both OK as far as I can see. I just don't like the configure > name implying all 32bit pointers are used by userspace. Perhaps just > --enable-large-address-aware? That might suggest the flag affects all targets, including Cygwin, so I'm following the existing (undocumented) practice in suggesting --enable-mingw-large-address-aware instead. Please let me know if you'd rather not have mingw in the option name, and for it to affect (in the --disable form) the Cygwin target as well. > Be sure to also update the documentation as Joseph says. *nod*, thanks. Here's the patch I'm testing now. Ok to install? Add a configure knob for mingw32 and 64 toolchains to default passing --large-address-aware to the linker, when creating 32-bit binaries. -Wl,--disable-large-address-aware can still reverse its effects. for gcc/ChangeLog * configure.ac: Introduce --enable-mingw-large-address-aware to define MINGW_DEFAULT_LARGE_ADDR_AWARE. * doc/install.texi: Document it. * configure, config.in: Rebuilt. * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define, based on MINGW_DEFAULT_LARGE_ADDR_AWARE. (LINK_SPEC): Insert it. * config/i386/mingw-264.h: Likewise. --- gcc/config.in | 6 ++++++ gcc/config/i386/mingw-w64.h | 9 +++++++++ gcc/config/i386/mingw32.h | 8 ++++++++ gcc/configure | 18 ++++++++++++++++-- gcc/configure.ac | 7 +++++++ gcc/doc/install.texi | 8 ++++++++ 6 files changed, 54 insertions(+), 2 deletions(-) diff --git a/gcc/config.in b/gcc/config.in index 4db8aa1ea154..44c3d04ab83c 100644 --- a/gcc/config.in +++ b/gcc/config.in @@ -1986,6 +1986,12 @@ #endif +/* Define if we should link with --large-address-aware by default */ +#ifndef USED_FOR_TARGET +#undef MINGW_DEFAULT_LARGE_ADDR_AWARE +#endif + + /* Value to set mingw's _dowildcard to. */ #ifndef USED_FOR_TARGET #undef MINGW_DOWILDCARD diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h index 484dc7a9e9f2..00b3f042a36c 100644 --- a/gcc/config/i386/mingw-w64.h +++ b/gcc/config/i386/mingw-w64.h @@ -81,6 +81,14 @@ along with GCC; see the file COPYING3. If not see #define MULTILIB_DEFAULTS { "m32" } #endif +#undef LINK_SPEC_LARGE_ADDR_AWARE +#if MINGW_DEFAULT_LARGE_ADDR_AWARE +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:%{" SPEC_32 ":--large-address-aware}}}" +#else +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#endif + #undef LINK_SPEC #define LINK_SPEC SUB_LINK_SPEC " %{mwindows:--subsystem windows} \ %{mconsole:--subsystem console} \ @@ -88,4 +96,5 @@ along with GCC; see the file COPYING3. If not see %{shared: --shared} %{mdll:--dll} \ %{static:-Bstatic} %{!static:-Bdynamic} \ %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \ + " LINK_SPEC_LARGE_ADDR_AWARE "\ %(shared_libgcc_undefs)" diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h index a66010894208..c9d8a7a31f30 100644 --- a/gcc/config/i386/mingw32.h +++ b/gcc/config/i386/mingw32.h @@ -114,12 +114,20 @@ along with GCC; see the file COPYING3. If not see #define SUBTARGET_EXTRA_SPECS \ { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC } +#if MINGW_DEFAULT_LARGE_ADDR_AWARE +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:--large-address-aware}}" +#else +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#endif + #define LINK_SPEC "%{mwindows:--subsystem windows} \ %{mconsole:--subsystem console} \ %{shared: %{mdll: %eshared and mdll are not compatible}} \ %{shared: --shared} %{mdll:--dll} \ %{static:-Bstatic} %{!static:-Bdynamic} \ %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \ + " LINK_SPEC_LARGE_ADDR_AWARE "\ %(shared_libgcc_undefs)" /* Include in the mingw32 libraries with libgcc */ diff --git a/gcc/configure b/gcc/configure index 9fb0eb57a8a1..17eb8d9a6154 100755 --- a/gcc/configure +++ b/gcc/configure @@ -927,6 +927,7 @@ enable_sjlj_exceptions with_gcc_major_version_only enable_secureplt enable_mingw_wildcard +enable_mingw_large_address_aware enable_leading_mingw64_underscores enable_cld enable_frame_pointer @@ -1644,6 +1645,8 @@ Optional Features: --enable-secureplt enable -msecure-plt by default for PowerPC --enable-mingw-wildcard Set whether to expand wildcard on command-line. Default to platform configuration + --enable-mingw-large-address-aware + Link mingw executables with --large-address-aware --enable-leading-mingw64-underscores enable leading underscores on 64 bit mingw targets --enable-cld enable -mcld by default for 32bit x86 @@ -12005,6 +12008,17 @@ _ACEOF fi +# Check whether --enable-mingw-large-address-aware was given. +if test "${enable_mingw_large_address_aware+set}" = set; then : + enableval=$enable_mingw_large_address_aware; +fi + +if test x"$enable_mingw_large_address_aware" = xyes; then : + +$as_echo "#define MINGW_DEFAULT_LARGE_ADDR_AWARE 1" >>confdefs.h + +fi + # Check whether --enable-leading-mingw64-underscores was given. if test "${enable_leading_mingw64_underscores+set}" = set; then : enableval=$enable_leading_mingw64_underscores; @@ -18463,7 +18477,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18466 "configure" +#line 18480 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -18569,7 +18583,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18572 "configure" +#line 18586 "configure" #include "confdefs.h" #if HAVE_DLFCN_H diff --git a/gcc/configure.ac b/gcc/configure.ac index ca51cdf751b9..5d2a35ed780c 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1829,6 +1829,13 @@ AS_IF([test x"$enable_mingw_wildcard" != xplatform ], $(test x"$enable_mingw_wildcard" = xno; echo $?), [Value to set mingw's _dowildcard to.])]) +AC_ARG_ENABLE(mingw-large-address-aware, +[AS_HELP_STRING([--enable-mingw-large-address-aware], + [Link mingw executables with --large-address-aware])]) +AS_IF([test x"$enable_mingw_large_address_aware" = xyes], + [AC_DEFINE([MINGW_DEFAULT_LARGE_ADDR_AWARE], 1, + [Define if we should link mingw executables with --large-address-aware])]) + AC_ARG_ENABLE(leading-mingw64-underscores, AS_HELP_STRING([--enable-leading-mingw64-underscores], [enable leading underscores on 64 bit mingw targets]), diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index 61ab97ee3707..d03ee31f4810 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -1729,6 +1729,14 @@ Using the GNU Compiler Collection (GCC)}, See ``i386 and x86-64 Options'' in the main manual @end ifhtml +@item --enable-mingw-large-address-aware +The @option{--enable-mingw-large-address-aware} option arranges for +MinGW executables to be linked using the @option{--large-address-aware} +option, that enables the use of more than 2GB of memory. If GCC is +configured with this option, its effects can be reversed by passing the +@option{-Wl,--disable-large-address-aware} option to the so-configured +compiler driver. + @item --enable-win32-registry @itemx --enable-win32-registry=@var{key} @itemx --disable-win32-registry
On 10/09/2018 04:59 AM, Alexandre Oliva wrote: > On Oct 5, 2018, Joseph Myers <joseph@codesourcery.com> wrote: > >> A new configure option needs documenting in install.texi. > > Ah, yes, thanks for the reminder. > > On Oct 6, 2018, JonY <10walls@gmail.com> wrote: > >> They're both OK as far as I can see. I just don't like the configure >> name implying all 32bit pointers are used by userspace. Perhaps just >> --enable-large-address-aware? > > That might suggest the flag affects all targets, including Cygwin, so > I'm following the existing (undocumented) practice in suggesting > --enable-mingw-large-address-aware instead. Please let me know if you'd > rather not have mingw in the option name, and for it to affect (in the > --disable form) the Cygwin target as well. > It is fine to turn it on by default in 32bit MinGW (i686-*-mingw*), but leave the defaults as is for others like Cygwin, I am not too sure of the effects for Cygwin. I don't think mingw should be in the configure name as this is applicable to all Win32 PE targets, it is a PE flag after all.
On Oct 9, 2018, JonY <10walls@gmail.com> wrote: > It is fine to turn it on by default in 32bit MinGW (i686-*-mingw*), but > leave the defaults as is for others like Cygwin, I am not too sure of > the effects for Cygwin. Cygwin already has --large-address-aware enabled, without an option to disable it. That makes sense, considering that Cygwin targets Unix programs, unlikely to have Windows-specific pointer assumptions. That's why I phrased the option, and implemented it, as specific to mingw. Now, if you wish it to affect Cygwin as well, I could implement that, and drop -mingw from the option name. I'd retain the current defaults of each target, unless there's a strong reason to change them.
On 10/10/2018 03:24 AM, Alexandre Oliva wrote: > On Oct 9, 2018, JonY <10walls@gmail.com> wrote: > >> It is fine to turn it on by default in 32bit MinGW (i686-*-mingw*), but >> leave the defaults as is for others like Cygwin, I am not too sure of >> the effects for Cygwin. > > Cygwin already has --large-address-aware enabled, without an option to > disable it. That makes sense, considering that Cygwin targets Unix > programs, unlikely to have Windows-specific pointer assumptions. > > That's why I phrased the option, and implemented it, as specific to > mingw. > > Now, if you wish it to affect Cygwin as well, I could implement that, > and drop -mingw from the option name. I'd retain the current defaults > of each target, unless there's a strong reason to change them. > In that case, no objections then.
On Oct 10, 2018, JonY <10walls@gmail.com> wrote: > On 10/10/2018 03:24 AM, Alexandre Oliva wrote: >> On Oct 9, 2018, JonY <10walls@gmail.com> wrote: >> Now, if you wish it to affect Cygwin as well, I could implement that, >> and drop -mingw from the option name. I'd retain the current defaults >> of each target, unless there's a strong reason to change them. > In that case, no objections then. Thanks. Now, before I proceed, please clarify: did you mean you had no objections to the patch I last proposed, or to the plan in my last paragraph above?
On 10/10/2018 04:58 AM, Alexandre Oliva wrote: > On Oct 10, 2018, JonY <10walls@gmail.com> wrote: > >> On 10/10/2018 03:24 AM, Alexandre Oliva wrote: >>> On Oct 9, 2018, JonY <10walls@gmail.com> wrote: > >>> Now, if you wish it to affect Cygwin as well, I could implement that, >>> and drop -mingw from the option name. I'd retain the current defaults >>> of each target, unless there's a strong reason to change them. > >> In that case, no objections then. > > Thanks. Now, before I proceed, please clarify: did you mean you had no > objections to the patch I last proposed, or to the plan in my last > paragraph above? > Your last proposed plan to use --enable-mingw-large-address-aware to affect only mingw. If there are more targets in the future that need this, we can always drop the mingw part in the configure option.
On Wed, Oct 10, 2018 at 7:37 PM JonY <10walls@gmail.com> wrote: > > On 10/10/2018 04:58 AM, Alexandre Oliva wrote: > > On Oct 10, 2018, JonY <10walls@gmail.com> wrote: > > > >> On 10/10/2018 03:24 AM, Alexandre Oliva wrote: > >>> On Oct 9, 2018, JonY <10walls@gmail.com> wrote: > > > >>> Now, if you wish it to affect Cygwin as well, I could implement that, > >>> and drop -mingw from the option name. I'd retain the current defaults > >>> of each target, unless there's a strong reason to change them. > > > >> In that case, no objections then. > > > > Thanks. Now, before I proceed, please clarify: did you mean you had no > > objections to the patch I last proposed, or to the plan in my last > > paragraph above? > > > > Your last proposed plan to use --enable-mingw-large-address-aware to > affect only mingw. If there are more targets in the future that need > this, we can always drop the mingw part in the configure option. Except that options typically don't get removed, just deprecated. It seems cleaner to me to drop mingw from the name and make it default to enabled for cygwin.
On 10/11/2018 02:57 AM, NightStrike wrote: > > Except that options typically don't get removed, just deprecated. It > seems cleaner to me to drop mingw from the name and make it default to > enabled for cygwin. > It is already enabled for Cygwin, but good point, --enable-large-address-aware it is, but enabled only for mingw for now, as such in the original patch.
On Oct 11, 2018, JonY <10walls@gmail.com> wrote: > On 10/11/2018 02:57 AM, NightStrike wrote: >> >> Except that options typically don't get removed, just deprecated. It >> seems cleaner to me to drop mingw from the name and make it default to >> enabled for cygwin. > It is already enabled for Cygwin, plus, I have no evidence that Cygwin even works without --large-address-aware, and I have no way to test that. > but good point, > --enable-large-address-aware it is, but enabled only for mingw for now, > as such in the original patch. Here's the patch, adjusted as requested and retested. Ok to install? introduce --enable-large-address-aware From: Alexandre Oliva <oliva@adacore.com> Add a configure knob for mingw32 and 64 toolchains to default passing --large-address-aware to the linker, when creating 32-bit binaries. -Wl,--disable-large-address-aware can still reverse its effects. for gcc/ChangeLog * configure.ac: Introduce --enable-large-address-aware to define MINGW_DEFAULT_LARGE_ADDR_AWARE. * doc/install.texi: Document it. * configure, config.in: Rebuilt. * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define, based on MINGW_DEFAULT_LARGE_ADDR_AWARE. (LINK_SPEC): Insert it. * config/i386/mingw-264.h: Likewise. --- gcc/config.in | 6 ++++++ gcc/config/i386/mingw-w64.h | 9 +++++++++ gcc/config/i386/mingw32.h | 8 ++++++++ gcc/configure | 18 ++++++++++++++++-- gcc/configure.ac | 7 +++++++ gcc/doc/install.texi | 8 ++++++++ 6 files changed, 54 insertions(+), 2 deletions(-) diff --git a/gcc/config.in b/gcc/config.in index d7c3fbfd9b21..c7b9e61686e3 100644 --- a/gcc/config.in +++ b/gcc/config.in @@ -1993,6 +1993,12 @@ #endif +/* Define if we should link with --large-address-aware by default */ +#ifndef USED_FOR_TARGET +#undef MINGW_DEFAULT_LARGE_ADDR_AWARE +#endif + + /* Value to set mingw's _dowildcard to. */ #ifndef USED_FOR_TARGET #undef MINGW_DOWILDCARD diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h index 484dc7a9e9f2..00b3f042a36c 100644 --- a/gcc/config/i386/mingw-w64.h +++ b/gcc/config/i386/mingw-w64.h @@ -81,6 +81,14 @@ along with GCC; see the file COPYING3. If not see #define MULTILIB_DEFAULTS { "m32" } #endif +#undef LINK_SPEC_LARGE_ADDR_AWARE +#if MINGW_DEFAULT_LARGE_ADDR_AWARE +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:%{" SPEC_32 ":--large-address-aware}}}" +#else +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#endif + #undef LINK_SPEC #define LINK_SPEC SUB_LINK_SPEC " %{mwindows:--subsystem windows} \ %{mconsole:--subsystem console} \ @@ -88,4 +96,5 @@ along with GCC; see the file COPYING3. If not see %{shared: --shared} %{mdll:--dll} \ %{static:-Bstatic} %{!static:-Bdynamic} \ %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \ + " LINK_SPEC_LARGE_ADDR_AWARE "\ %(shared_libgcc_undefs)" diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h index a66010894208..c9d8a7a31f30 100644 --- a/gcc/config/i386/mingw32.h +++ b/gcc/config/i386/mingw32.h @@ -114,12 +114,20 @@ along with GCC; see the file COPYING3. If not see #define SUBTARGET_EXTRA_SPECS \ { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC } +#if MINGW_DEFAULT_LARGE_ADDR_AWARE +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:--large-address-aware}}" +#else +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#endif + #define LINK_SPEC "%{mwindows:--subsystem windows} \ %{mconsole:--subsystem console} \ %{shared: %{mdll: %eshared and mdll are not compatible}} \ %{shared: --shared} %{mdll:--dll} \ %{static:-Bstatic} %{!static:-Bdynamic} \ %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \ + " LINK_SPEC_LARGE_ADDR_AWARE "\ %(shared_libgcc_undefs)" /* Include in the mingw32 libraries with libgcc */ diff --git a/gcc/configure b/gcc/configure index 3e33a69628bd..563860181a1c 100755 --- a/gcc/configure +++ b/gcc/configure @@ -928,6 +928,7 @@ enable_sjlj_exceptions with_gcc_major_version_only enable_secureplt enable_mingw_wildcard +enable_large_address_aware enable_leading_mingw64_underscores enable_cld enable_frame_pointer @@ -1645,6 +1646,8 @@ Optional Features: --enable-secureplt enable -msecure-plt by default for PowerPC --enable-mingw-wildcard Set whether to expand wildcard on command-line. Default to platform configuration + --enable-large-address-aware + Link mingw executables with --large-address-aware --enable-leading-mingw64-underscores enable leading underscores on 64 bit mingw targets --enable-cld enable -mcld by default for 32bit x86 @@ -12037,6 +12040,17 @@ _ACEOF fi +# Check whether --enable-large-address-aware was given. +if test "${enable_large_address_aware+set}" = set; then : + enableval=$enable_large_address_aware; +fi + +if test x"$enable_large_address_aware" = xyes; then : + +$as_echo "#define MINGW_DEFAULT_LARGE_ADDR_AWARE 1" >>confdefs.h + +fi + # Check whether --enable-leading-mingw64-underscores was given. if test "${enable_leading_mingw64_underscores+set}" = set; then : enableval=$enable_leading_mingw64_underscores; @@ -18495,7 +18509,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18498 "configure" +#line 18512 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -18601,7 +18615,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18604 "configure" +#line 18618 "configure" #include "confdefs.h" #if HAVE_DLFCN_H diff --git a/gcc/configure.ac b/gcc/configure.ac index ff6444a0f9b4..c5c33af374cc 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1852,6 +1852,13 @@ AS_IF([test x"$enable_mingw_wildcard" != xplatform ], $(test x"$enable_mingw_wildcard" = xno; echo $?), [Value to set mingw's _dowildcard to.])]) +AC_ARG_ENABLE(large-address-aware, +[AS_HELP_STRING([--enable-large-address-aware], + [Link mingw executables with --large-address-aware])]) +AS_IF([test x"$enable_large_address_aware" = xyes], + [AC_DEFINE([MINGW_DEFAULT_LARGE_ADDR_AWARE], 1, + [Define if we should link mingw executables with --large-address-aware])]) + AC_ARG_ENABLE(leading-mingw64-underscores, AS_HELP_STRING([--enable-leading-mingw64-underscores], [enable leading underscores on 64 bit mingw targets]), diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi index 93022517b315..6dd21bb915ee 100644 --- a/gcc/doc/install.texi +++ b/gcc/doc/install.texi @@ -1734,6 +1734,14 @@ Using the GNU Compiler Collection (GCC)}, See ``i386 and x86-64 Options'' in the main manual @end ifhtml +@item --enable-large-address-aware +The @option{--enable-large-address-aware} option arranges for MinGW +executables to be linked using the @option{--large-address-aware} +option, that enables the use of more than 2GB of memory. If GCC is +configured with this option, its effects can be reversed by passing the +@option{-Wl,--disable-large-address-aware} option to the so-configured +compiler driver. + @item --enable-win32-registry @itemx --enable-win32-registry=@var{key} @itemx --disable-win32-registry
On 10/12/2018 05:56 AM, Alexandre Oliva wrote: > On Oct 11, 2018, JonY <10walls@gmail.com> wrote: > >> On 10/11/2018 02:57 AM, NightStrike wrote: >>> >>> Except that options typically don't get removed, just deprecated. It >>> seems cleaner to me to drop mingw from the name and make it default to >>> enabled for cygwin. > >> It is already enabled for Cygwin, > > plus, I have no evidence that Cygwin even works without > --large-address-aware, and I have no way to test that. > >> but good point, >> --enable-large-address-aware it is, but enabled only for mingw for now, >> as such in the original patch. > > Here's the patch, adjusted as requested and retested. Ok to install? > > > introduce --enable-large-address-aware > > From: Alexandre Oliva <oliva@adacore.com> > > Add a configure knob for mingw32 and 64 toolchains to default passing > --large-address-aware to the linker, when creating 32-bit binaries. > -Wl,--disable-large-address-aware can still reverse its effects. > > for gcc/ChangeLog > > * configure.ac: Introduce --enable-large-address-aware > to define MINGW_DEFAULT_LARGE_ADDR_AWARE. > * doc/install.texi: Document it. > * configure, config.in: Rebuilt. > * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define, > based on MINGW_DEFAULT_LARGE_ADDR_AWARE. > (LINK_SPEC): Insert it. > * config/i386/mingw-264.h: Likewise. Patch looks OK to be.
On Oct 12, 2018, Alexandre Oliva <oliva@adacore.com> wrote: > * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define, > based on MINGW_DEFAULT_LARGE_ADDR_AWARE. > (LINK_SPEC): Insert it. > * config/i386/mingw-264.h: Likewise. ^ s/2/w/, fixing... Now, it occurred to me that it is possible for biarch64.h to be included, thus enabling 64-bit mode even by default, without including mingw-w64.h. I had assumed in my patch that this was not supposed to happen, but configuring with --target=x86_64-mingw32 shows it does happen, and such a toolchain may (after my patch) pass --large-address-aware to the linker, even when linking -m64 binaries. Is that target configuration really supposed to be different from x86_64-w64-mingw32 (or however else the w64 configuration is supposed to be spelled), or should x86_64-mingw32 also use mingw-w64.h so that they're equivalent? It seems to me that we need a further patch like this: diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h index c9d8a7a31f30..848eb8430b30 100644 --- a/gcc/config/i386/mingw32.h +++ b/gcc/config/i386/mingw32.h @@ -114,11 +114,17 @@ along with GCC; see the file COPYING3. If not see #define SUBTARGET_EXTRA_SPECS \ { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC } -#if MINGW_DEFAULT_LARGE_ADDR_AWARE +#if ! MINGW_DEFAULT_LARGE_ADDR_AWARE +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#elif ! TARGET_BI_ARCH # define LINK_SPEC_LARGE_ADDR_AWARE \ "%{!shared:%{!mdll:--large-address-aware}}" +#elif TARGET_64BIT_DEFAULT +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:%{m32:--large-address-aware}}}" #else -# define LINK_SPEC_LARGE_ADDR_AWARE "" +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:%{!m64:--large-address-aware}}}" #endif #define LINK_SPEC "%{mwindows:--subsystem windows} \ But then, even this wouldn't necessarily do the right thing if e.g. biarchx32.h is in effect. Is that even possible? Or can we just leave mingw32.h as is, considering that (AFAIK) -m64 *is* --large-address-aware, it just has that enabled by default? Thanks in advance for your guidance,
On 10/31/2018 10:39 PM, Alexandre Oliva wrote: > On Oct 12, 2018, Alexandre Oliva <oliva@adacore.com> wrote: > >> * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define, >> based on MINGW_DEFAULT_LARGE_ADDR_AWARE. >> (LINK_SPEC): Insert it. >> * config/i386/mingw-264.h: Likewise. > ^ s/2/w/, fixing... > > Now, it occurred to me that it is possible for biarch64.h to be > included, thus enabling 64-bit mode even by default, without including > mingw-w64.h. I had assumed in my patch that this was not supposed to > happen, but configuring with --target=x86_64-mingw32 shows it does > happen, and such a toolchain may (after my patch) pass > --large-address-aware to the linker, even when linking -m64 binaries. > > Is that target configuration really supposed to be different from > x86_64-w64-mingw32 (or however else the w64 configuration is supposed to > be spelled), or should x86_64-mingw32 also use mingw-w64.h so that > they're equivalent? > > It seems to me that we need a further patch like this: > > diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h > index c9d8a7a31f30..848eb8430b30 100644 > --- a/gcc/config/i386/mingw32.h > +++ b/gcc/config/i386/mingw32.h > @@ -114,11 +114,17 @@ along with GCC; see the file COPYING3. If not see > #define SUBTARGET_EXTRA_SPECS \ > { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC } > > -#if MINGW_DEFAULT_LARGE_ADDR_AWARE > +#if ! MINGW_DEFAULT_LARGE_ADDR_AWARE > +# define LINK_SPEC_LARGE_ADDR_AWARE "" > +#elif ! TARGET_BI_ARCH > # define LINK_SPEC_LARGE_ADDR_AWARE \ > "%{!shared:%{!mdll:--large-address-aware}}" > +#elif TARGET_64BIT_DEFAULT > +# define LINK_SPEC_LARGE_ADDR_AWARE \ > + "%{!shared:%{!mdll:%{m32:--large-address-aware}}}" > #else > -# define LINK_SPEC_LARGE_ADDR_AWARE "" > +# define LINK_SPEC_LARGE_ADDR_AWARE \ > + "%{!shared:%{!mdll:%{!m64:--large-address-aware}}}" > #endif > > #define LINK_SPEC "%{mwindows:--subsystem windows} \ > > But then, even this wouldn't necessarily do the right thing if e.g. > biarchx32.h is in effect. Is that even possible? > > Or can we just leave mingw32.h as is, considering that (AFAIK) -m64 *is* > --large-address-aware, it just has that enabled by default? > Looks like it causes an error on 64bit: /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option '--large-address-aware' So it'll need to be excluded for x86_64.
On Nov 1, 2018, JonY <10walls@gmail.com> wrote: > Looks like it causes an error on 64bit: > /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option > '--large-address-aware' What does? The patch I suggested? The current trunk? What was the command in this case? How was the toolchain configured? I've been looking into this, getting progressively puzzled, though I actually managed to duplicated the problem you mentioned, but only on x86_64-mingw32, NOT on x86_64-w64-mingw32. Here's what I found out in my investigation: configured for i686-mingw32, GNU ld supports only the i386pe emulation, that supports the --large-address-aware flag. Configured for x86_64-*-mingw32, it supports i386pe, but it defaults to i386pep, the 64-bit binary format, that does NOT support --large-address-aware. x86_64-w64-mingw32 passes -mi386pe or -mi386pep to the linker, depending on -m32 or -m64, so the code to pass --large-address-aware to link -m32 binaries in mingw-w64.h looks correct to me. But x86_64-mingw32 does NOT use that: it uses the LINK_SPEC from mingw32.h, so it doesn't specify the emulation, ever. That seems awfully broken to me. If you ask for a 32-bit binary, using the default 64-bit linker format is unlikely to produce the desired results. Is x86_64-mingw32 really supposed to be a usable target name? It might even work as a 64-bit only target, but I don't see how its biarch support could possibly be functional. If it is to be usable, is it really supposed to be different from x86_64-w64-mingw32? Using mingw-w64.h besides mingw32.h would fix the biarch problems, but perhaps that's not desired for other reasons. Fixing that is way beyond my knowledge or interest on Windows-based platforms, but given clarification as to whether x86_64-mingw32 is supposed to support biarch at all, I might be able to fix the implementation of --enable-large-address-aware there. As for the problem you reported on x86_64-w64-mingw32, I'm afraid I'll need some more information to be able to duplicate that and try to fix it. Thanks,
On 11/07/2018 08:34 AM, Alexandre Oliva wrote: > On Nov 1, 2018, JonY wrote: > >> Looks like it causes an error on 64bit: >> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option >> '--large-address-aware' > > What does? The patch I suggested? The current trunk? > > What was the command in this case? How was the toolchain configured? > > > I've been looking into this, getting progressively puzzled, though I > actually managed to duplicated the problem you mentioned, but only on > x86_64-mingw32, NOT on x86_64-w64-mingw32. > > No it's just a quick test to see how x86_64-w64-mingw32 reacts to --large-address-aware, it doesn't play well. > Here's what I found out in my investigation: > > configured for i686-mingw32, GNU ld supports only the i386pe emulation, > that supports the --large-address-aware flag. > > Configured for x86_64-*-mingw32, it supports i386pe, but it defaults to > i386pep, the 64-bit binary format, that does NOT support > --large-address-aware. > > x86_64-w64-mingw32 passes -mi386pe or -mi386pep to the linker, depending > on -m32 or -m64, so the code to pass --large-address-aware to link -m32 > binaries in mingw-w64.h looks correct to me. But x86_64-mingw32 does > NOT use that: it uses the LINK_SPEC from mingw32.h, so it doesn't > specify the emulation, ever. That seems awfully broken to me. If you > ask for a 32-bit binary, using the default 64-bit linker format is > unlikely to produce the desired results. > > Is x86_64-mingw32 really supposed to be a usable target name? It might > even work as a 64-bit only target, but I don't see how its biarch > support could possibly be functional. > > If it is to be usable, is it really supposed to be different from > x86_64-w64-mingw32? Using mingw-w64.h besides mingw32.h would fix the > biarch problems, but perhaps that's not desired for other reasons. > > Fixing that is way beyond my knowledge or interest on Windows-based > platforms, but given clarification as to whether x86_64-mingw32 is > supposed to support biarch at all, I might be able to fix the > implementation of --enable-large-address-aware there. > > As for the problem you reported on x86_64-w64-mingw32, I'm afraid I'll > need some more information to be able to duplicate that and try to fix > it. > > Thanks, > x86_64-mingw32 is not used as far as I know, only with "w64" or "pc". The "w64" carries a special meaning to gcc dating back to the early 64bit port. It basically tells gcc to use mingw-w64 specific features that are not found on the regular mingw.org CRT at the time. This might be affecting the "pc" vendor build, can you check x86_64-pc-mingw32 just to see if it is affected? Thanks.
On Nov 7, 2018, JonY <10walls@gmail.com> wrote: > On 11/07/2018 08:34 AM, Alexandre Oliva wrote: >> On Nov 1, 2018, JonY wrote: >> >>> Looks like it causes an error on 64bit: >>> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option >>> '--large-address-aware' >> >> What does? The patch I suggested? The current trunk? >> >> What was the command in this case? How was the toolchain configured? > No it's just a quick test to see how x86_64-w64-mingw32 reacts to > --large-address-aware, it doesn't play well. I understand, but you're getting a different result from what I am, I'd like to understand why before attempting to "fix" something that AFAICT is correct and behaving just as intended. Maybe there are valid reasons to drop --large-address-aware altogether on x86_64-w64-mingw32, but I'd like to understand why, as in, how the error above came about for you, when it didn't for me. I built gcc and binutils in a single tree, with x86_64-w64-mingw32 as the target, and the resulting linker would accept --large-address-aware in the -mi386-pe emulation, and that emulation was explicitly enabled when building -m32 binaries. Does your w64 toolchain deviate from any of these facts? > x86_64-mingw32 is not used as far as I know, only with "w64" or "pc". x86_64-mingw32's canonical form is x86_64-pc-mingw32, and they're equivalent, so whatever you say or know about the latter should apply to the shorter form as well. Likewise, my questions and doubts about the shorter form apply equally to the canonical one. > The "w64" carries a special meaning to gcc dating back to the early > 64bit port. It basically tells gcc to use mingw-w64 specific features > that are not found on the regular mingw.org CRT at the time. I see. So -pc- and -w64- are not supposed to be equivalent indeed. Thanks. > This might be affecting the "pc" vendor build, can you check > x86_64-pc-mingw32 just to see if it is affected? I did. Its -m32 mode seems broken to me. As I wrote, the linker emulation is never specified, so it would build 64-bit binaries even when given -m32. Because it lacks explicit linker emulation specification, it can't have --large-address-aware specified either. In my link tests, i686-mingw32 and x86_64-w64-mingw32 both worked (in that their respective linkers wouldn't reject the --large-address-aware passed by gcc) with the --large-address-aware patch that is installed in trunk. Ditto with the incremental patch I posted last week, that would have only improved x86_64-pc-mingw32.
On 11/08/2018 09:45 AM, Alexandre Oliva wrote: > On Nov 7, 2018, JonY <10walls@gmail.com> wrote: > >> On 11/07/2018 08:34 AM, Alexandre Oliva wrote: >>> On Nov 1, 2018, JonY wrote: >>> >>>> Looks like it causes an error on 64bit: >>>> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option >>>> '--large-address-aware' >>> >>> What does? The patch I suggested? The current trunk? >>> >>> What was the command in this case? How was the toolchain configured? > >> No it's just a quick test to see how x86_64-w64-mingw32 reacts to >> --large-address-aware, it doesn't play well. > > I understand, but you're getting a different result from what I am, I'd > like to understand why before attempting to "fix" something that AFAICT > is correct and behaving just as intended. Maybe there are valid reasons > to drop --large-address-aware altogether on x86_64-w64-mingw32, but I'd > like to understand why, as in, how the error above came about for you, > when it didn't for me. > > I built gcc and binutils in a single tree, with x86_64-w64-mingw32 as > the target, and the resulting linker would accept --large-address-aware > in the -mi386-pe emulation, and that emulation was explicitly enabled > when building -m32 binaries. Does your w64 toolchain deviate from any > of these facts? > No, no. By quick I just mean using -Wl,--large-address-aware on an existing gcc install, nothing complex. Sorry about not making it clear. > >> x86_64-mingw32 is not used as far as I know, only with "w64" or "pc". > > x86_64-mingw32's canonical form is x86_64-pc-mingw32, and they're > equivalent, so whatever you say or know about the latter should apply to > the shorter form as well. Likewise, my questions and doubts about the > shorter form apply equally to the canonical one. > >> The "w64" carries a special meaning to gcc dating back to the early >> 64bit port. It basically tells gcc to use mingw-w64 specific features >> that are not found on the regular mingw.org CRT at the time. > > I see. So -pc- and -w64- are not supposed to be equivalent indeed. > Thanks. > >> This might be affecting the "pc" vendor build, can you check >> x86_64-pc-mingw32 just to see if it is affected? > > I did. Its -m32 mode seems broken to me. As I wrote, the linker > emulation is never specified, so it would build 64-bit binaries even > when given -m32. Because it lacks explicit linker emulation > specification, it can't have --large-address-aware specified either. > > In my link tests, i686-mingw32 and x86_64-w64-mingw32 both worked (in > that their respective linkers wouldn't reject the --large-address-aware > passed by gcc) with the --large-address-aware patch that is installed in > trunk. Ditto with the incremental patch I posted last week, that would > have only improved x86_64-pc-mingw32. > I now understand the problem, thanks for the clarification about the patch. Patch is OK.
On Nov 8, 2018, JonY <10walls@gmail.com> wrote: > No, no. By quick I just mean using -Wl,--large-address-aware on an > existing gcc install, nothing complex. Sorry about not making it clear. Ah, good! > I now understand the problem, thanks for the clarification about the > patch. Patch is OK. Thanks, here's what I'm installing (with comments indicating which configuration each setting applies to, and why one of them won't work) large-addr-aware for biarch non-w64 mingw32 for gcc/ChangeLog * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Adjust for non-w64 x86_64 biarch. --- gcc/config/i386/mingw32.h | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h index c9d8a7a31f30..5759d8d16aef 100644 --- a/gcc/config/i386/mingw32.h +++ b/gcc/config/i386/mingw32.h @@ -114,11 +114,26 @@ along with GCC; see the file COPYING3. If not see #define SUBTARGET_EXTRA_SPECS \ { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC } -#if MINGW_DEFAULT_LARGE_ADDR_AWARE +#if ! MINGW_DEFAULT_LARGE_ADDR_AWARE +/* This is used without --enable-large-address-aware. */ +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#elif ! TARGET_BI_ARCH +/* This is used on i686-pc-mingw32 with --enable-large-address-aware. */ # define LINK_SPEC_LARGE_ADDR_AWARE \ "%{!shared:%{!mdll:--large-address-aware}}" +#elif TARGET_64BIT_DEFAULT +/* This is used on x86_64-pc-mingw32 with --enable-large-address-aware. + ??? It probably doesn't work, because the linker emulation defaults + to i386pep, the 64-bit mode that does not support + --large-address-aware, and x86_64-pc-mingw32 does not override the + emulation to i386pe for -m32, unlike x86_64-w64-mingw32. */ +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:%{m32:--large-address-aware}}}" #else -# define LINK_SPEC_LARGE_ADDR_AWARE "" +/* This would only be used if someone introduced a biarch + configuration that defaulted to 32-bit. */ +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:%{!m64:--large-address-aware}}}" #endif #define LINK_SPEC "%{mwindows:--subsystem windows} \
On 11/09/2018 10:48 AM, Alexandre Oliva wrote: > On Nov 8, 2018, JonY <10walls@gmail.com> wrote: > >> No, no. By quick I just mean using -Wl,--large-address-aware on an >> existing gcc install, nothing complex. Sorry about not making it clear. > > Ah, good! > >> I now understand the problem, thanks for the clarification about the >> patch. Patch is OK. > > Thanks, here's what I'm installing (with comments indicating which > configuration each setting applies to, and why one of them won't work) > > > large-addr-aware for biarch non-w64 mingw32 > > for gcc/ChangeLog > > * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Adjust > for non-w64 x86_64 biarch. This patch is certainly better with the explanation, OK for trunk.
diff --git a/gcc/config.in b/gcc/config.in index 2856e72d627df..05aa7e94c296d 100644 --- a/gcc/config.in +++ b/gcc/config.in @@ -2040,6 +2040,12 @@ #endif +/* Define if we should link with --large-address-aware by default */ +#ifndef USED_FOR_TARGET +#undef MINGW_DEFAULT_LARGE_ADDR_AWARE +#endif + + /* Value to set mingw's _dowildcard to. */ #ifndef USED_FOR_TARGET #undef MINGW_DOWILDCARD diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h index 484dc7a9e9f27..00b3f042a36ca 100644 --- a/gcc/config/i386/mingw-w64.h +++ b/gcc/config/i386/mingw-w64.h @@ -81,6 +81,14 @@ along with GCC; see the file COPYING3. If not see #define MULTILIB_DEFAULTS { "m32" } #endif +#undef LINK_SPEC_LARGE_ADDR_AWARE +#if MINGW_DEFAULT_LARGE_ADDR_AWARE +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:%{" SPEC_32 ":--large-address-aware}}}" +#else +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#endif + #undef LINK_SPEC #define LINK_SPEC SUB_LINK_SPEC " %{mwindows:--subsystem windows} \ %{mconsole:--subsystem console} \ @@ -88,4 +96,5 @@ along with GCC; see the file COPYING3. If not see %{shared: --shared} %{mdll:--dll} \ %{static:-Bstatic} %{!static:-Bdynamic} \ %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \ + " LINK_SPEC_LARGE_ADDR_AWARE "\ %(shared_libgcc_undefs)" diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h index a66010894208b..c9d8a7a31f30e 100644 --- a/gcc/config/i386/mingw32.h +++ b/gcc/config/i386/mingw32.h @@ -114,12 +114,20 @@ along with GCC; see the file COPYING3. If not see #define SUBTARGET_EXTRA_SPECS \ { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC } +#if MINGW_DEFAULT_LARGE_ADDR_AWARE +# define LINK_SPEC_LARGE_ADDR_AWARE \ + "%{!shared:%{!mdll:--large-address-aware}}" +#else +# define LINK_SPEC_LARGE_ADDR_AWARE "" +#endif + #define LINK_SPEC "%{mwindows:--subsystem windows} \ %{mconsole:--subsystem console} \ %{shared: %{mdll: %eshared and mdll are not compatible}} \ %{shared: --shared} %{mdll:--dll} \ %{static:-Bstatic} %{!static:-Bdynamic} \ %{shared|mdll: " SUB_LINK_ENTRY " --enable-auto-image-base} \ + " LINK_SPEC_LARGE_ADDR_AWARE "\ %(shared_libgcc_undefs)" /* Include in the mingw32 libraries with libgcc */ diff --git a/gcc/configure b/gcc/configure index b7a8e3643778b..21fbda80a3ba7 100755 --- a/gcc/configure +++ b/gcc/configure @@ -927,6 +927,7 @@ enable_sjlj_exceptions with_gcc_major_version_only enable_secureplt enable_mingw_wildcard +enable_mingw_full32 enable_leading_mingw64_underscores enable_cld enable_frame_pointer @@ -1644,6 +1645,8 @@ Optional Features: --enable-secureplt enable -msecure-plt by default for PowerPC --enable-mingw-wildcard Set whether to expand wildcard on command-line. Default to platform configuration + --enable-mingw-full32 Link with --large-address-aware, past 2GiB, by + default --enable-leading-mingw64-underscores enable leading underscores on 64 bit mingw targets --enable-cld enable -mcld by default for 32bit x86 @@ -12002,6 +12005,17 @@ _ACEOF fi +# Check whether --enable-mingw-full32 was given. +if test "${enable_mingw_full32+set}" = set; then : + enableval=$enable_mingw_full32; +fi + +if test x"$enable_mingw_full32" = xyes; then : + +$as_echo "#define MINGW_DEFAULT_LARGE_ADDR_AWARE 1" >>confdefs.h + +fi + # Check whether --enable-leading-mingw64-underscores was given. if test "${enable_leading_mingw64_underscores+set}" = set; then : enableval=$enable_leading_mingw64_underscores; @@ -18460,7 +18474,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18463 "configure" +#line 18477 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -18566,7 +18580,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 18569 "configure" +#line 18583 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -19731,20 +19745,20 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi prelink_cmds_CXX='tpldir=Template.dir~ rm -rf $tpldir~ $CC --prelink_objects --instantiation_dir $tpldir $objs $libobjs $compile_deplibs~ - compile_command="$compile_command `find $tpldir -name \*.o | $NL2SP`"' + compile_command="$compile_command `find $tpldir -name \*.o | sort | $NL2SP`"' old_archive_cmds_CXX='tpldir=Template.dir~ rm -rf $tpldir~ $CC --prelink_objects --instantiation_dir $tpldir $oldobjs$old_deplibs~ - $AR $AR_FLAGS $oldlib$oldobjs$old_deplibs `find $tpldir -name \*.o | $NL2SP`~ + $AR $AR_FLAGS $oldlib$oldobjs$old_deplibs `find $tpldir -name \*.o | sort | $NL2SP`~ $RANLIB $oldlib' archive_cmds_CXX='tpldir=Template.dir~ rm -rf $tpldir~ $CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~ - $CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | $NL2SP` $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o $lib' + $CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | sort | $NL2SP` $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o $lib' archive_expsym_cmds_CXX='tpldir=Template.dir~ rm -rf $tpldir~ $CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~ - $CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | $NL2SP` $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname ${wl}-retain-symbols-file ${wl}$export_symbols -o $lib' + $CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | sort | $NL2SP` $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname ${wl}-retain-symbols-file ${wl}$export_symbols -o $lib' ;; *) # Version 6 and above use weak symbols archive_cmds_CXX='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o $lib' diff --git a/gcc/configure.ac b/gcc/configure.ac index 65f9c92ec8522..6272bcaef1c2f 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1826,6 +1826,13 @@ AS_IF([test x"$enable_mingw_wildcard" != xplatform ], $(test x"$enable_mingw_wildcard" = xno; echo $?), [Value to set mingw's _dowildcard to.])]) +AC_ARG_ENABLE(mingw-full32, +[AS_HELP_STRING([--enable-mingw-full32], + [Link with --large-address-aware, past 2GiB, by default])]) +AS_IF([test x"$enable_mingw_full32" = xyes], + [AC_DEFINE([MINGW_DEFAULT_LARGE_ADDR_AWARE], 1, + [Define if we should link with --large-address-aware by default])]) + AC_ARG_ENABLE(leading-mingw64-underscores, AS_HELP_STRING([--enable-leading-mingw64-underscores], [enable leading underscores on 64 bit mingw targets]), ---- define HAVE_GAS_ALIGNED_COMM HAVE_GAS_ALIGNED_COMM is referenced in an initializer in cygming.opt, but it's not guaranteed to be defined by configure, so define it to zero in a cygming-specific header if it's not defined. Ok to install? for gcc/ChangeLog * cygming.h (HAVE_GAS_ALIGNED_COMM): Fallback-define. --- gcc/config/i386/cygming.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h index cfe563f47af0b..d7c7dd7057bf6 100644 --- a/gcc/config/i386/cygming.h +++ b/gcc/config/i386/cygming.h @@ -488,3 +488,7 @@ do { \ /* Static stack checking is supported by means of probes. */ #define STACK_CHECK_STATIC_BUILTIN 1 + +#ifndef HAVE_GAS_ALIGNED_COMM +# define HAVE_GAS_ALIGNED_COMM 0 +#endif