[PATCH] Link to -lssp when available (fixes mingw build)

[PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564

gdb/ChangeLog:

2019-12-18  Christian Biesinger  <cbiesinger@google.com>

	* configure: Regenerate.
	* gdbsupport/common.m4: Look for -lssp to fix mingw.

gdb/gdbserver/ChangeLog:

2019-12-18  Christian Biesinger  <cbiesinger@google.com>

	* configure: Regenerate.

Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
---
 gdb/configure            | 57 ++++++++++++++++++++++++++++++++++++++++
 gdb/gdbserver/configure  | 57 ++++++++++++++++++++++++++++++++++++++++
 gdb/gdbsupport/common.m4 |  4 +++
 3 files changed, 118 insertions(+)

diff --git a/gdb/configure b/gdb/configure
index 324eb50944..04ead07bc9 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -13642,6 +13642,63 @@ cat >>confdefs.h <<_ACEOF
 _ACEOF
 
 
+      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing __memcpy_chk" >&5
+$as_echo_n "checking for library containing __memcpy_chk... " >&6; }
+if ${ac_cv_search___memcpy_chk+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_func_search_save_LIBS=$LIBS
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char __memcpy_chk ();
+int
+main ()
+{
+return __memcpy_chk ();
+  ;
+  return 0;
+}
+_ACEOF
+for ac_lib in '' ssp; do
+  if test -z "$ac_lib"; then
+    ac_res="none required"
+  else
+    ac_res=-l$ac_lib
+    LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
+  fi
+  if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_search___memcpy_chk=$ac_res
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext
+  if ${ac_cv_search___memcpy_chk+:} false; then :
+  break
+fi
+done
+if ${ac_cv_search___memcpy_chk+:} false; then :
+
+else
+  ac_cv_search___memcpy_chk=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search___memcpy_chk" >&5
+$as_echo "$ac_cv_search___memcpy_chk" >&6; }
+ac_res=$ac_cv_search___memcpy_chk
+if test "$ac_res" != no; then :
+  test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
+
+fi
+
+
   # Check for std::thread.  This does not work on some platforms, like
   # mingw and DJGPP.
   ac_ext=cpp
diff --git a/gdb/gdbserver/configure b/gdb/gdbserver/configure
index ccffde80ed..9f1cc70fda 100755
--- a/gdb/gdbserver/configure
+++ b/gdb/gdbserver/configure
@@ -7034,6 +7034,63 @@ cat >>confdefs.h <<_ACEOF
 _ACEOF
 
 
+      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing __memcpy_chk" >&5
+$as_echo_n "checking for library containing __memcpy_chk... " >&6; }
+if ${ac_cv_search___memcpy_chk+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_func_search_save_LIBS=$LIBS
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char __memcpy_chk ();
+int
+main ()
+{
+return __memcpy_chk ();
+  ;
+  return 0;
+}
+_ACEOF
+for ac_lib in '' ssp; do
+  if test -z "$ac_lib"; then
+    ac_res="none required"
+  else
+    ac_res=-l$ac_lib
+    LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
+  fi
+  if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_search___memcpy_chk=$ac_res
+fi
+rm -f core conftest.err conftest.$ac_objext \
+    conftest$ac_exeext
+  if ${ac_cv_search___memcpy_chk+:} false; then :
+  break
+fi
+done
+if ${ac_cv_search___memcpy_chk+:} false; then :
+
+else
+  ac_cv_search___memcpy_chk=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search___memcpy_chk" >&5
+$as_echo "$ac_cv_search___memcpy_chk" >&6; }
+ac_res=$ac_cv_search___memcpy_chk
+if test "$ac_res" != no; then :
+  test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
+
+fi
+
+
   # Check for std::thread.  This does not work on some platforms, like
   # mingw and DJGPP.
   ac_ext=cpp
diff --git a/gdb/gdbsupport/common.m4 b/gdb/gdbsupport/common.m4
index c61753fb8e..eb66ec3731 100644
--- a/gdb/gdbsupport/common.m4
+++ b/gdb/gdbsupport/common.m4
@@ -37,6 +37,10 @@ AC_DEFUN([GDB_AC_COMMON], [
 
   AC_CHECK_DECLS([strstr])
 
+  dnl Recent mingw requires -lssp when using _FORTIFY_SOURCE, which we do
+  dnl (see gdbsupport/common-defs.h)
+  AC_SEARCH_LIBS(__memcpy_chk, ssp)
+
   # Check for std::thread.  This does not work on some platforms, like
   # mingw and DJGPP.
   AC_LANG_PUSH([C++])
-- 
2.24.1.735.g03f4e72817-goog

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

On Wed, Dec 18, 2019 at 12:14 PM Christian Biesinger
<cbiesinger@google.com> wrote:
>
> Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
> gdb does (in common-defs.h)
> https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564

I should have clarified: this is mingw64 (from msys2.org).

Also, I'd like to push this to the gdb 9 branch too, if that's ok.

Christian

> gdb/ChangeLog:
>
> 2019-12-18  Christian Biesinger  <cbiesinger@google.com>
>
>         * configure: Regenerate.
>         * gdbsupport/common.m4: Look for -lssp to fix mingw.
>
> gdb/gdbserver/ChangeLog:
>
> 2019-12-18  Christian Biesinger  <cbiesinger@google.com>
>
>         * configure: Regenerate.
>
> Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
> ---
>  gdb/configure            | 57 ++++++++++++++++++++++++++++++++++++++++
>  gdb/gdbserver/configure  | 57 ++++++++++++++++++++++++++++++++++++++++
>  gdb/gdbsupport/common.m4 |  4 +++
>  3 files changed, 118 insertions(+)
>
> diff --git a/gdb/configure b/gdb/configure
> index 324eb50944..04ead07bc9 100755
> --- a/gdb/configure
> +++ b/gdb/configure
> @@ -13642,6 +13642,63 @@ cat >>confdefs.h <<_ACEOF
>  _ACEOF
>
>
> +      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing __memcpy_chk" >&5
> +$as_echo_n "checking for library containing __memcpy_chk... " >&6; }
> +if ${ac_cv_search___memcpy_chk+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  ac_func_search_save_LIBS=$LIBS
> +cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +
> +/* Override any GCC internal prototype to avoid an error.
> +   Use char because int might match the return type of a GCC
> +   builtin and then its argument prototype would still apply.  */
> +#ifdef __cplusplus
> +extern "C"
> +#endif
> +char __memcpy_chk ();
> +int
> +main ()
> +{
> +return __memcpy_chk ();
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +for ac_lib in '' ssp; do
> +  if test -z "$ac_lib"; then
> +    ac_res="none required"
> +  else
> +    ac_res=-l$ac_lib
> +    LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
> +  fi
> +  if ac_fn_c_try_link "$LINENO"; then :
> +  ac_cv_search___memcpy_chk=$ac_res
> +fi
> +rm -f core conftest.err conftest.$ac_objext \
> +    conftest$ac_exeext
> +  if ${ac_cv_search___memcpy_chk+:} false; then :
> +  break
> +fi
> +done
> +if ${ac_cv_search___memcpy_chk+:} false; then :
> +
> +else
> +  ac_cv_search___memcpy_chk=no
> +fi
> +rm conftest.$ac_ext
> +LIBS=$ac_func_search_save_LIBS
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search___memcpy_chk" >&5
> +$as_echo "$ac_cv_search___memcpy_chk" >&6; }
> +ac_res=$ac_cv_search___memcpy_chk
> +if test "$ac_res" != no; then :
> +  test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
> +
> +fi
> +
> +
>    # Check for std::thread.  This does not work on some platforms, like
>    # mingw and DJGPP.
>    ac_ext=cpp
> diff --git a/gdb/gdbserver/configure b/gdb/gdbserver/configure
> index ccffde80ed..9f1cc70fda 100755
> --- a/gdb/gdbserver/configure
> +++ b/gdb/gdbserver/configure
> @@ -7034,6 +7034,63 @@ cat >>confdefs.h <<_ACEOF
>  _ACEOF
>
>
> +      { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing __memcpy_chk" >&5
> +$as_echo_n "checking for library containing __memcpy_chk... " >&6; }
> +if ${ac_cv_search___memcpy_chk+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  ac_func_search_save_LIBS=$LIBS
> +cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +
> +/* Override any GCC internal prototype to avoid an error.
> +   Use char because int might match the return type of a GCC
> +   builtin and then its argument prototype would still apply.  */
> +#ifdef __cplusplus
> +extern "C"
> +#endif
> +char __memcpy_chk ();
> +int
> +main ()
> +{
> +return __memcpy_chk ();
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +for ac_lib in '' ssp; do
> +  if test -z "$ac_lib"; then
> +    ac_res="none required"
> +  else
> +    ac_res=-l$ac_lib
> +    LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
> +  fi
> +  if ac_fn_c_try_link "$LINENO"; then :
> +  ac_cv_search___memcpy_chk=$ac_res
> +fi
> +rm -f core conftest.err conftest.$ac_objext \
> +    conftest$ac_exeext
> +  if ${ac_cv_search___memcpy_chk+:} false; then :
> +  break
> +fi
> +done
> +if ${ac_cv_search___memcpy_chk+:} false; then :
> +
> +else
> +  ac_cv_search___memcpy_chk=no
> +fi
> +rm conftest.$ac_ext
> +LIBS=$ac_func_search_save_LIBS
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search___memcpy_chk" >&5
> +$as_echo "$ac_cv_search___memcpy_chk" >&6; }
> +ac_res=$ac_cv_search___memcpy_chk
> +if test "$ac_res" != no; then :
> +  test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
> +
> +fi
> +
> +
>    # Check for std::thread.  This does not work on some platforms, like
>    # mingw and DJGPP.
>    ac_ext=cpp
> diff --git a/gdb/gdbsupport/common.m4 b/gdb/gdbsupport/common.m4
> index c61753fb8e..eb66ec3731 100644
> --- a/gdb/gdbsupport/common.m4
> +++ b/gdb/gdbsupport/common.m4
> @@ -37,6 +37,10 @@ AC_DEFUN([GDB_AC_COMMON], [
>
>    AC_CHECK_DECLS([strstr])
>
> +  dnl Recent mingw requires -lssp when using _FORTIFY_SOURCE, which we do
> +  dnl (see gdbsupport/common-defs.h)
> +  AC_SEARCH_LIBS(__memcpy_chk, ssp)
> +
>    # Check for std::thread.  This does not work on some platforms, like
>    # mingw and DJGPP.
>    AC_LANG_PUSH([C++])
> --
> 2.24.1.735.g03f4e72817-goog
>

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> Date: Wed, 18 Dec 2019 12:14:13 -0600
> From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
> Cc: Christian Biesinger <cbiesinger@google.com>
> 
> Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
> gdb does (in common-defs.h)
> https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
> 
> gdb/ChangeLog:
> 
> 2019-12-18  Christian Biesinger  <cbiesinger@google.com>
> 
> 	* configure: Regenerate.
> 	* gdbsupport/common.m4: Look for -lssp to fix mingw.

This will produce a GDB binary that requires libssp-0.dll to be
present to run, won't it?  And since libssp-0.dll is part of GCC,
this will have 2 annoying effects:

  . we could be in "DLL hell" if there's an incompatibility between
    libssp against which GDB was linkes and the one actually installed
    on the system where we run GDB;

  . if someone wants to distribute MinGW binaries of GDB, they will
    have to distribute the GCC sources as well, since DLLs cannot
    enjoy the libgcc-type exception

Is there a way to link against libssp.a statically?  If so, it would
be better to do that.  Failing that, I'd recommend not to define
_FORTIFY_SOURCE in MinGW builds, because the above annoyances IMO
outweigh its utility.

Thanks.

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

On Wed, Dec 18, 2019 at 12:44 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Wed, 18 Dec 2019 12:14:13 -0600
> > From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
> > Cc: Christian Biesinger <cbiesinger@google.com>
> >
> > Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
> > gdb does (in common-defs.h)
> > https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
> >
> > gdb/ChangeLog:
> >
> > 2019-12-18  Christian Biesinger  <cbiesinger@google.com>
> >
> >       * configure: Regenerate.
> >       * gdbsupport/common.m4: Look for -lssp to fix mingw.
>
> This will produce a GDB binary that requires libssp-0.dll to be
> present to run, won't it?  And since libssp-0.dll is part of GCC,
> this will have 2 annoying effects:
>
>   . we could be in "DLL hell" if there's an incompatibility between
>     libssp against which GDB was linkes and the one actually installed
>     on the system where we run GDB;
>
>   . if someone wants to distribute MinGW binaries of GDB, they will
>     have to distribute the GCC sources as well, since DLLs cannot
>     enjoy the libgcc-type exception

That's a good point, I did not think of that.

> Is there a way to link against libssp.a statically?  If so, it would
> be better to do that.  Failing that, I'd recommend not to define
> _FORTIFY_SOURCE in MinGW builds, because the above annoyances IMO
> outweigh its utility.

Looks like the way to do that would be  -Wl,-Bstatic -lssp -Wl,-Bdynamic

However, I'm not sure that all the required autoconf changes are worth
it at this point, and maybe we should just not define _FORTIFY_SOURCE
on mingw? I'll send a patch for that shortly.

Christian

[PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Christian Biesinger via gdb-patches]

Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564

To avoid all the complications with checking for -lssp and making sure it's
linked statically, just don't define it.

gdb/ChangeLog:

2019-12-18  Christian Biesinger  <cbiesinger@google.com>

	* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on mingw.

Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
---
 gdb/gdbsupport/common-defs.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gdb/gdbsupport/common-defs.h b/gdb/gdbsupport/common-defs.h
index 203bd8972d..53ce3c96ea 100644
--- a/gdb/gdbsupport/common-defs.h
+++ b/gdb/gdbsupport/common-defs.h
@@ -66,9 +66,13 @@
    plus this seems like a reasonable safety measure.  The check for
    optimization is required because _FORTIFY_SOURCE only works when
    optimization is enabled.  If _FORTIFY_SOURCE is already defined,
-   then we don't do anything.  */
+   then we don't do anything.  Also, on mingw, fortify requires
+   linking to -lssp, and to avoid the hassle of checking for
+   that and linking to it statically, we just don't define
+   _FORTIFY_SOURCE there.  */
 
-#if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
+#if (!defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0 \
+     && !defined(__MINGW32__))
 #define _FORTIFY_SOURCE 2
 #endif
 
-- 
2.24.1.735.g03f4e72817-goog

Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Joel Brobecker]

Hi everyone,

On Wed, Dec 18, 2019 at 01:07:05PM -0600, Christian Biesinger via gdb-patches wrote:
> Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
> gdb does (in common-defs.h)
> https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
> 
> To avoid all the complications with checking for -lssp and making sure it's
> linked statically, just don't define it.
> 
> gdb/ChangeLog:
> 
> 2019-12-18  Christian Biesinger  <cbiesinger@google.com>
> 
> 	* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on mingw.

Thanks for the patch!

I hestitated a lot on this patch. On the one hand, it wasn't clear
to me that libssp was any different from the other library dependencies
that one can build against... Until it was mentioned that static linking
requires libssp_nonshared! Gaaah... Also, while some people consider it
a necessity to link statically, others would can be in a situation where
it is definitely better for them to link dynamically.

At the end of the day, I think this might be the most sensible approach
after all. I imagine that someone wanting to build with FORTIFY can do
so by adding -D_FORTIFY_SOURCE=2 to the compilation flags, and then
the necessary linking options to add the libraries. For static linking,
one can pass the full path to the archive instead of using -lxxx.
In other words, this patch isn't closing the door for activating
_FORTIFY_SOURCE.

I was also thinking of adding a NEWS entry. However, IIUC, this option
had no effect with previous versions of MinGW? Thus, in the end,
this patch makes the situation stay the same regardless of MinGW
version, meaning no NEWS updated needed.

If my understanding is correct, then I am OK with this patch, and
you can push it to both master and gdb-9-branch. Even if people
object to the approach, this patch doesn't make it any more difficult
to enhance the build to have fortify on by default.

One small comment below...

> 
> Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
> ---
>  gdb/gdbsupport/common-defs.h | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/gdbsupport/common-defs.h b/gdb/gdbsupport/common-defs.h
> index 203bd8972d..53ce3c96ea 100644
> --- a/gdb/gdbsupport/common-defs.h
> +++ b/gdb/gdbsupport/common-defs.h
> @@ -66,9 +66,13 @@
>     plus this seems like a reasonable safety measure.  The check for
>     optimization is required because _FORTIFY_SOURCE only works when
>     optimization is enabled.  If _FORTIFY_SOURCE is already defined,
> -   then we don't do anything.  */
> +   then we don't do anything.  Also, on mingw, fortify requires

mingw -> MinGW ;-)

> +   linking to -lssp, and to avoid the hassle of checking for
> +   that and linking to it statically, we just don't define
> +   _FORTIFY_SOURCE there.  */
>  
> -#if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
> +#if (!defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0 \
> +     && !defined(__MINGW32__))
>  #define _FORTIFY_SOURCE 2
>  #endif
>  
> -- 
> 2.24.1.735.g03f4e72817-goog

-- 
Joel

Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Christian Biesinger via gdb-patches]

Hi Joel,

On Thu, Jan 2, 2020 at 5:31 AM Joel Brobecker <brobecker@adacore.com> wrote:
>
> Hi everyone,
>
> On Wed, Dec 18, 2019 at 01:07:05PM -0600, Christian Biesinger via gdb-patches wrote:
> > Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
> > gdb does (in common-defs.h)
> > https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
> >
> > To avoid all the complications with checking for -lssp and making sure it's
> > linked statically, just don't define it.
> >
> > gdb/ChangeLog:
> >
> > 2019-12-18  Christian Biesinger  <cbiesinger@google.com>
> >
> >       * gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on mingw.
>
> Thanks for the patch!
>
> I hestitated a lot on this patch. On the one hand, it wasn't clear
> to me that libssp was any different from the other library dependencies
> that one can build against... Until it was mentioned that static linking
> requires libssp_nonshared! Gaaah... Also, while some people consider it
> a necessity to link statically, others would can be in a situation where
> it is definitely better for them to link dynamically.

Sorry, to clarify the issue there -- libssp_nonshared is not needed,
what is needed are the right linker flags:
 -Wl,-Bstatic -lssp -Wl,-Bdynamic
(since, per Eli, we want to link this statically)

However, that means I can't just use AC_SEARCH_LIBS. So I'd have to
either use AC_LINK_IFELSE, which is more complicated, or hardcode
those flags if target matches mingw (doesn't sound too great).

> At the end of the day, I think this might be the most sensible approach
> after all. I imagine that someone wanting to build with FORTIFY can do
> so by adding -D_FORTIFY_SOURCE=2 to the compilation flags, and then
> the necessary linking options to add the libraries. For static linking,
> one can pass the full path to the archive instead of using -lxxx.
> In other words, this patch isn't closing the door for activating
> _FORTIFY_SOURCE.

Yes, that is true.

> I was also thinking of adding a NEWS entry. However, IIUC, this option
> had no effect with previous versions of MinGW? Thus, in the end,
> this patch makes the situation stay the same regardless of MinGW
> version, meaning no NEWS updated needed.

My understanding is that this did use to work (maybe it automatically
linked against -lssp?). But I'm not sure a NEWS entry is needed? This
does not seem user-visible.

> If my understanding is correct, then I am OK with this patch, and
> you can push it to both master and gdb-9-branch. Even if people
> object to the approach, this patch doesn't make it any more difficult
> to enhance the build to have fortify on by default.

Let me know your thoughts on the above, especially the NEWS question.

> One small comment below...
>
> >
> > Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
> > ---
> >  gdb/gdbsupport/common-defs.h | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/gdb/gdbsupport/common-defs.h b/gdb/gdbsupport/common-defs.h
> > index 203bd8972d..53ce3c96ea 100644
> > --- a/gdb/gdbsupport/common-defs.h
> > +++ b/gdb/gdbsupport/common-defs.h
> > @@ -66,9 +66,13 @@
> >     plus this seems like a reasonable safety measure.  The check for
> >     optimization is required because _FORTIFY_SOURCE only works when
> >     optimization is enabled.  If _FORTIFY_SOURCE is already defined,
> > -   then we don't do anything.  */
> > +   then we don't do anything.  Also, on mingw, fortify requires
>
> mingw -> MinGW ;-)

Thanks, will fix locally.

Christian

Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Eli Zaretskii]

> From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
> Date: Tue, 7 Jan 2020 17:42:55 -0600
> Cc: Christian Biesinger via gdb-patches <gdb-patches@sourceware.org>
> 
> > I was also thinking of adding a NEWS entry. However, IIUC, this option
> > had no effect with previous versions of MinGW? Thus, in the end,
> > this patch makes the situation stay the same regardless of MinGW
> > version, meaning no NEWS updated needed.
> 
> My understanding is that this did use to work (maybe it automatically
> linked against -lssp?). But I'm not sure a NEWS entry is needed? This
> does not seem user-visible.

I think it used to work because the MinGW GCC wasn't reacting to
_FORTIFY_SOURCE, so it was largely a no-op for MinGW.  This changed in
a recent version of MinGW GCC.

I'm also not sure this should be in NEWS.  It depends on how MinGW
users who build GDB are sensitive to _FORTIFY_SOURCE.

Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Tom Tromey]

>>>>> "Christian" == Christian Biesinger via gdb-patches <gdb-patches@sourceware.org> writes:

>> If my understanding is correct, then I am OK with this patch, and
>> you can push it to both master and gdb-9-branch. Even if people
>> object to the approach, this patch doesn't make it any more difficult
>> to enhance the build to have fortify on by default.

Christian> Let me know your thoughts on the above, especially the NEWS question.

I think it is fine as-is, without a NEWS entry.
Please check it in.

thanks,
Tom

Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Christian Biesinger via gdb-patches]

On Thu, Jan 9, 2020 at 4:23 PM Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "Christian" == Christian Biesinger via gdb-patches <gdb-patches@sourceware.org> writes:
>
> >> If my understanding is correct, then I am OK with this patch, and
> >> you can push it to both master and gdb-9-branch. Even if people
> >> object to the approach, this patch doesn't make it any more difficult
> >> to enhance the build to have fortify on by default.
>
> Christian> Let me know your thoughts on the above, especially the NEWS question.
>
> I think it is fine as-is, without a NEWS entry.
> Please check it in.

Thanks, pushed to master. OK for the gdb 9 branch too?

To ssh://sourceware.org/git/binutils-gdb.git
   3061113bf3..5f23a08201  HEAD -> master

Christian

Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Tom Tromey]

Christian> Thanks, pushed to master. OK for the gdb 9 branch too?

Yes, please.

thanks,
Tom

Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw

[Christian Biesinger via gdb-patches]

On Thu, Jan 9, 2020 at 6:28 PM Tom Tromey <tom@tromey.com> wrote:
>
> Christian> Thanks, pushed to master. OK for the gdb 9 branch too?
>
> Yes, please.

Thanks, done.
To ssh://sourceware.org/git/binutils-gdb.git
   ad5e26527f..975292a976  HEAD -> gdb-9-branch

Christian

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 18 Dec 2019 12:56:26 -0600
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> > Is there a way to link against libssp.a statically?  If so, it would
> > be better to do that.  Failing that, I'd recommend not to define
> > _FORTIFY_SOURCE in MinGW builds, because the above annoyances IMO
> > outweigh its utility.
> 
> Looks like the way to do that would be  -Wl,-Bstatic -lssp -Wl,-Bdynamic
> 
> However, I'm not sure that all the required autoconf changes are worth
> it at this point, and maybe we should just not define _FORTIFY_SOURCE
> on mingw? I'll send a patch for that shortly.

Thanks, I think it's a good solution for one more reason: searching
the Internet for related issues suggests that Cygwin doesn't package a
static libssp library, so a static link against that might be
impossible for a Cygwin build of GDB.  (Please take that with a grain
of salt, as I don't use Cygwin and know very little about it; what
I've read on the Internet might be outdated.)

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

On Wed, Dec 18, 2019 at 1:08 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Wed, 18 Dec 2019 12:56:26 -0600
> > Cc: gdb-patches <gdb-patches@sourceware.org>
> >
> > > Is there a way to link against libssp.a statically?  If so, it would
> > > be better to do that.  Failing that, I'd recommend not to define
> > > _FORTIFY_SOURCE in MinGW builds, because the above annoyances IMO
> > > outweigh its utility.
> >
> > Looks like the way to do that would be  -Wl,-Bstatic -lssp -Wl,-Bdynamic
> >
> > However, I'm not sure that all the required autoconf changes are worth
> > it at this point, and maybe we should just not define _FORTIFY_SOURCE
> > on mingw? I'll send a patch for that shortly.
>
> Thanks, I think it's a good solution for one more reason: searching
> the Internet for related issues suggests that Cygwin doesn't package a
> static libssp library, so a static link against that might be
> impossible for a Cygwin build of GDB.  (Please take that with a grain
> of salt, as I don't use Cygwin and know very little about it; what
> I've read on the Internet might be outdated.)

My cygwin installation does have a static ssp:
/usr/lib/gcc/i586-pc-msdosdjgpp/5.4.0/libssp.a
/usr/lib/gcc/i586-pc-msdosdjgpp/5.4.0/libssp_nonshared.a
/usr/lib/gcc/i686-w64-mingw32/7.4.0/libssp.a
/usr/lib/gcc/i686-w64-mingw32/7.4.0/libssp.dll.a
/usr/lib/gcc/i686-w64-mingw32/7.4.0/libssp_nonshared.a
/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/libssp.a
/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/libssp.dll.a
/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/libssp_nonshared.a
/usr/lib/libssp.a

But I'm not sure that for cygwin this matters as much anyway.

(If libssp_nonshared.a existed on my "native" mingw that would be
great, but sadly it doesn't...)

Christian

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 18 Dec 2019 13:12:10 -0600
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> > Thanks, I think it's a good solution for one more reason: searching
> > the Internet for related issues suggests that Cygwin doesn't package a
> > static libssp library, so a static link against that might be
> > impossible for a Cygwin build of GDB.  (Please take that with a grain
> > of salt, as I don't use Cygwin and know very little about it; what
> > I've read on the Internet might be outdated.)
> 
> My cygwin installation does have a static ssp:
> /usr/lib/gcc/i586-pc-msdosdjgpp/5.4.0/libssp.a
> /usr/lib/gcc/i586-pc-msdosdjgpp/5.4.0/libssp_nonshared.a
> /usr/lib/gcc/i686-w64-mingw32/7.4.0/libssp.a
> /usr/lib/gcc/i686-w64-mingw32/7.4.0/libssp.dll.a
> /usr/lib/gcc/i686-w64-mingw32/7.4.0/libssp_nonshared.a
> /usr/lib/gcc/x86_64-w64-mingw32/7.4.0/libssp.a
> /usr/lib/gcc/x86_64-w64-mingw32/7.4.0/libssp.dll.a
> /usr/lib/gcc/x86_64-w64-mingw32/7.4.0/libssp_nonshared.a
> /usr/lib/libssp.a

OK, so what I've read _was_ indeed outdated.

> But I'm not sure that for cygwin this matters as much anyway.

Neither am I.

> (If libssp_nonshared.a existed on my "native" mingw that would be
> great, but sadly it doesn't...)

Not sure I follow.  I do have libssp_nonshared.a in my MinGW
installation, although it's mingw.org's MinGW, not MinGW64.  But the
above list indicates you also have the nonshared version, no?

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

On Wed, Dec 18, 2019 at 1:40 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Wed, 18 Dec 2019 13:12:10 -0600
> > Cc: gdb-patches <gdb-patches@sourceware.org>
> > (If libssp_nonshared.a existed on my "native" mingw that would be
> > great, but sadly it doesn't...)
>
> Not sure I follow.  I do have libssp_nonshared.a in my MinGW
> installation, although it's mingw.org's MinGW, not MinGW64.  But the
> above list indicates you also have the nonshared version, no?

Hmm, yeah, you are right. But it doesn't work!
$ g++ test.cc  -O2 -lssp_nonshared
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\tmp\ccmAuUCu.o:test.cc:(.text.startup+0x1f): undefined
reference to `__strcpy_chk'
collect2.exe: error: ld returned 1 exit status

$ nm /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/libssp_nonshared.a

libssp_nonshared_la-ssp-local.o:
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 r .pdata
0000000000000000 r .rdata$zzz
0000000000000000 t .text
0000000000000000 r .xdata
                 U __stack_chk_fail
0000000000000000 T __stack_chk_fail_local

So I guess that's actually for something else? I think
https://sourceware.org/ml/gdb-patches/2019-12/msg00787.html is the
best option.

Christian

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 18 Dec 2019 13:50:00 -0600
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> Hmm, yeah, you are right. But it doesn't work!
> $ g++ test.cc  -O2 -lssp_nonshared
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> C:\msys64\tmp\ccmAuUCu.o:test.cc:(.text.startup+0x1f): undefined
> reference to `__strcpy_chk'
> collect2.exe: error: ld returned 1 exit status

AFAIK, you need to link with -lssp_nonshared -lssp.  My GCC's specs
have this:

  *link_ssp:
  %{fstack-protector|fstack-protector-all|fstack-protector-strong|fstack-protector-explicit:-lssp_nonshared -lssp}

> So I guess that's actually for something else? I think
> https://sourceware.org/ml/gdb-patches/2019-12/msg00787.html is the
> best option.

I agree, FWIW.

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

On Wed, Dec 18, 2019 at 1:57 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Wed, 18 Dec 2019 13:50:00 -0600
> > Cc: gdb-patches <gdb-patches@sourceware.org>
> >
> > Hmm, yeah, you are right. But it doesn't work!
> > $ g++ test.cc  -O2 -lssp_nonshared
> > C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > C:\msys64\tmp\ccmAuUCu.o:test.cc:(.text.startup+0x1f): undefined
> > reference to `__strcpy_chk'
> > collect2.exe: error: ld returned 1 exit status
>
> AFAIK, you need to link with -lssp_nonshared -lssp.  My GCC's specs
> have this:
>
>   *link_ssp:
>   %{fstack-protector|fstack-protector-all|fstack-protector-strong|fstack-protector-explicit:-lssp_nonshared -lssp}

Ah ok, so that doesn't help us.

> > So I guess that's actually for something else? I think
> > https://sourceware.org/ml/gdb-patches/2019-12/msg00787.html is the
> > best option.
>
> I agree, FWIW.

OK, sounds good.

BTW -- you mentioned a licensing issue with depending on DLLs. Doesn't
libstdc++ and perhaps others have the same issue? Or does mingw.org
link it statically?

My msys2/mingw64 gcc depends on these DLLs outside of SYSTEM32:
        libpython3.8.dll => /mingw64/bin/libpython3.8.dll (0x70840000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
        libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)

Christian

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
> Date: Wed, 18 Dec 2019 14:40:42 -0600
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> BTW -- you mentioned a licensing issue with depending on DLLs. Doesn't
> libstdc++ and perhaps others have the same issue? Or does mingw.org
> link it statically?

libstdc++ and libgcc DLLs indeed have the same problem.  Which is why
I mentioned the fact that the binary of GDB 9.0.90 produced by the
MinGW build had dependencies on these two.  I solved that locally by
linking with "CXX='g++ -static-libstdc++ -static-libgcc'", but I
thought Pedro once said these dependencies shouldn't happen, and I
still hope we could understand why they suddenly appeared.

> My msys2/mingw64 gcc depends on these DLLs outside of SYSTEM32:
>         libpython3.8.dll => /mingw64/bin/libpython3.8.dll (0x70840000)
>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
>         libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
>         libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)

In general, any binary that depends on some DLLs and comes with those
DLLs needs to be accompanied by the sources of all the DLLs, to be
compatible with GPL.  In the above list, all the DLLs except Python
are part of GCC, so as long as the GCC sources are available, the
MinGW64 folks are okay.  I don't know how they deal with the problem
of providing the Python sources, though.

For the binaries I produce, I always try to link statically against
DLLs that come from GCC, because I don't want to distribute the
humongous GCC sources, and I don't want to provide a binary
distribution that is not self-contained (i.e. without those
problematic DLLs).

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

On Wed, Dec 18, 2019 at 5:12 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
> > Date: Wed, 18 Dec 2019 14:40:42 -0600
> > Cc: gdb-patches <gdb-patches@sourceware.org>a lot of
> >
> > BTW -- you mentioned a licensing issue with depending on DLLs. Doesn't
> > libstdc++ and perhaps others have the same issue? Or does mingw.org
> > link it statically?
>
> libstdc++ and libgcc DLLs indeed have the same problem.  Which is why
> I mentioned the fact that the binary of GDB 9.0.90 produced by the
> MinGW build had dependencies on these two.  I solved that locally by
> linking with "CXX='g++ -static-libstdc++ -static-libgcc'", but I
> thought Pedro once said these dependencies shouldn't happen, and I
> still hope we could understand why they suddenly appeared.

Hm, I wonder why Pedro said that. GDB uses good amounts of the C++
standard library, so I would totally expect libstdc++ to appear. I
don't really know what libgcc is used for.

> > My msys2/mingw64 gcc depends on these DLLs outside of SYSTEM32:
> >         libpython3.8.dll => /mingw64/bin/libpython3.8.dll (0x70840000)
> >         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
> >         libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
> >         libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)
>
> In general, any binary that depends on some DLLs and comes with those
> DLLs needs to be accompanied by the sources of all the DLLs, to be
> compatible with GPL.  In the above list, all the DLLs except Python
> are part of GCC, so as long as the GCC sources are available, the
> MinGW64 folks are okay.  I don't know how they deal with the problem
> of providing the Python sources, though.
>
> For the binaries I produce, I always try to link statically against
> DLLs that come from GCC, because I don't want to distribute the
> humongous GCC sources, and I don't want to provide a binary
> distribution that is not self-contained (i.e. without those
> problematic DLLs).

Is libwinpthread-1 part of GCC? I would have thought that's part of
mingw's runtime (how do you deal with that yourself?)

Thanks for the explanation!

Christian

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Pedro Alves]

On 12/18/19 11:23 PM, Christian Biesinger via gdb-patches wrote:
> On Wed, Dec 18, 2019 at 5:12 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
>>> Date: Wed, 18 Dec 2019 14:40:42 -0600
>>> Cc: gdb-patches <gdb-patches@sourceware.org>a lot of
>>>
>>> BTW -- you mentioned a licensing issue with depending on DLLs. Doesn't
>>> libstdc++ and perhaps others have the same issue? Or does mingw.org
>>> link it statically?
>>
>> libstdc++ and libgcc DLLs indeed have the same problem.  Which is why
>> I mentioned the fact that the binary of GDB 9.0.90 produced by the
>> MinGW build had dependencies on these two.  I solved that locally by
>> linking with "CXX='g++ -static-libstdc++ -static-libgcc'", but I
>> thought Pedro once said these dependencies shouldn't happen, and I
>> still hope we could understand why they suddenly appeared.
> 
> Hm, I wonder why Pedro said that. GDB uses good amounts of the C++
> standard library, so I would totally expect libstdc++ to appear. 

There's some confusion going on here.  We must certainly link with
libstdc++ somehow.  The only question is whether we link to the
dynamic or static version.  What I've said in the past is that GDB
inherited the -static-libstdc++ and -static-libgcc from GCC, due to
the shared top level configure:

  https://sourceware.org/ml/gdb-patches/2019-07/msg00040.html

Linking with static versions of the runtime is problematic if we also link
with some other library that is itself linked with a different libstdc++.
Multiple versions of libstc++/libgcc in a program is a recipe for disaster,
such as for example C++ exceptions not working properly.  Discussions about
this started a few years ago when we switched to C++.  E.g.:

  https://sourceware.org/ml/gdb-patches/2017-02/msg00705.html

That is why the top level configure was recently changed to avoid the
-static-libstc++/-static-libgcc:

  https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00287.html

Note that the patch added a new --with-static-standard-libraries
configure switch which you can use to get back the previous behavior
of linking with the static versions of the standard libraries.

I think a NEWS entry for that switch would be helpful, though.

> I don't really know what libgcc is used for.

libgcc is GCC's low-level runtime library.  It's an essential part
of any program compiled by GCC:
https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

Thanks,
Pedro Alves

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> Cc: gdb-patches <gdb-patches@sourceware.org>
> From: Pedro Alves <palves@redhat.com>
> Date: Thu, 19 Dec 2019 14:19:45 +0000
> 
> >> libstdc++ and libgcc DLLs indeed have the same problem.  Which is why
> >> I mentioned the fact that the binary of GDB 9.0.90 produced by the
> >> MinGW build had dependencies on these two.  I solved that locally by
> >> linking with "CXX='g++ -static-libstdc++ -static-libgcc'", but I
> >> thought Pedro once said these dependencies shouldn't happen, and I
> >> still hope we could understand why they suddenly appeared.
> > 
> > Hm, I wonder why Pedro said that. GDB uses good amounts of the C++
> > standard library, so I would totally expect libstdc++ to appear. 
> 
> There's some confusion going on here.  We must certainly link with
> libstdc++ somehow.  The only question is whether we link to the
> dynamic or static version.

Right.  Sorry if I inadvertently caused this confusion.

> Linking with static versions of the runtime is problematic if we also link
> with some other library that is itself linked with a different libstdc++.
> Multiple versions of libstc++/libgcc in a program is a recipe for disaster,
> such as for example C++ exceptions not working properly.  Discussions about
> this started a few years ago when we switched to C++.  E.g.:
> 
>   https://sourceware.org/ml/gdb-patches/2017-02/msg00705.html
> 
> That is why the top level configure was recently changed to avoid the
> -static-libstc++/-static-libgcc:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00287.html
> 
> Note that the patch added a new --with-static-standard-libraries
> configure switch which you can use to get back the previous behavior
> of linking with the static versions of the standard libraries.

Ah, okay, so I need to use that configure option.  (The original
problem with exceptions thrown across shared libraries doesn't exist
in my build, because no C++-compiled shared library is used, they all
are linked statically.)

> I think a NEWS entry for that switch would be helpful, though.

Right, that would be helpful.

> > I don't really know what libgcc is used for.
> 
> libgcc is GCC's low-level runtime library.  It's an essential part
> of any program compiled by GCC:
> https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

Not every GCC complied program needs it, IME, but whenever libstdc++
is linked in, so is libgcc.

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> Date: Thu, 19 Dec 2019 17:49:27 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: cbiesinger@google.com, gdb-patches@sourceware.org
> 
> > That is why the top level configure was recently changed to avoid the
> > -static-libstc++/-static-libgcc:
> > 
> >   https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00287.html
> > 
> > Note that the patch added a new --with-static-standard-libraries
> > configure switch which you can use to get back the previous behavior
> > of linking with the static versions of the standard libraries.
> 
> Ah, okay, so I need to use that configure option.

I've now used --with-static-standard-libraries while building GDB 9.1,
and found out that it causes a problem: it doesn't allow linking
against libsource-highlight:

     checking for the source-highlight library... configure: error: source highlight is incompatible with -static-libstdc++; either use --disable-source-highlight or --without-static-standard-libraries
     Makefile:9238: recipe for target `configure-gdb' failed
     make[1]: *** [configure-gdb] Error 1

This is because the configure script unconditionally rejects
"--with-static-standard-libraries", although AFAIU linking statically
against libsource-highlight.a doesn't contradict static libstdc++ and
libgcc.  So this sounds like a gratuitous limitation.  Is it possible
to remove it, and simply force linking statically against
libsource-highlight when --with-static-standard-libraries is used?

TIA

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Christian Biesinger via gdb-patches]

On Thu, Dec 19, 2019 at 8:19 AM Pedro Alves <palves@redhat.com> wrote:
>
> On 12/18/19 11:23 PM, Christian Biesinger via gdb-patches wrote:
> > On Wed, Dec 18, 2019 at 5:12 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >>> From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
> >>> Date: Wed, 18 Dec 2019 14:40:42 -0600
> >>> Cc: gdb-patches <gdb-patches@sourceware.org>a lot of
> >>>
> >>> BTW -- you mentioned a licensing issue with depending on DLLs. Doesn't
> >>> libstdc++ and perhaps others have the same issue? Or does mingw.org
> >>> link it statically?
> >>
> >> libstdc++ and libgcc DLLs indeed have the same problem.  Which is why
> >> I mentioned the fact that the binary of GDB 9.0.90 produced by the
> >> MinGW build had dependencies on these two.  I solved that locally by
> >> linking with "CXX='g++ -static-libstdc++ -static-libgcc'", but I
> >> thought Pedro once said these dependencies shouldn't happen, and I
> >> still hope we could understand why they suddenly appeared.
> >
> > Hm, I wonder why Pedro said that. GDB uses good amounts of the C++
> > standard library, so I would totally expect libstdc++ to appear.
>
> There's some confusion going on here.  We must certainly link with
> libstdc++ somehow.  The only question is whether we link to the
> dynamic or static version.  What I've said in the past is that GDB
> inherited the -static-libstdc++ and -static-libgcc from GCC, due to
> the shared top level configure:
>
>   https://sourceware.org/ml/gdb-patches/2019-07/msg00040.html
>
> Linking with static versions of the runtime is problematic if we also link
> with some other library that is itself linked with a different libstdc++.
> Multiple versions of libstc++/libgcc in a program is a recipe for disaster,
> such as for example C++ exceptions not working properly.  Discussions about
> this started a few years ago when we switched to C++.  E.g.:
>
>   https://sourceware.org/ml/gdb-patches/2017-02/msg00705.html
>
> That is why the top level configure was recently changed to avoid the
> -static-libstc++/-static-libgcc:
>
>   https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00287.html
>
> Note that the patch added a new --with-static-standard-libraries
> configure switch which you can use to get back the previous behavior
> of linking with the static versions of the standard libraries.
>
> I think a NEWS entry for that switch would be helpful, though.
>
> > I don't really know what libgcc is used for.
>
> libgcc is GCC's low-level runtime library.  It's an essential part
> of any program compiled by GCC:
> https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html

Thanks for the detailed explanation!

Christian

Re: [PATCH] Link to -lssp when available (fixes mingw build)

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 18 Dec 2019 17:23:24 -0600
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> Is libwinpthread-1 part of GCC? I would have thought that's part of
> mingw's runtime

I think it comes with the MinGW distro of GCC, yes.

> (how do you deal with that yourself?)

mingw.org's MinGW doesn't by default make the programs it builds
depend on pthreads, and I renamed/removed the pthreads header and
import library so that configure scripts don't decide I have pthreads
installed.