Link to -lssp when available (fixes mingw build)

  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(+)
  

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
>
  

> 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.
  

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
  

> 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.)
  

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
  

> 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?
  

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
  

> 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.
  

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
  

> 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).
  

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
  

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
  

> 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.
  

> 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.
  

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
  

> 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