Re: [PATCH 0/1] Build GDB as a C++ program by default

[Eli Zaretskii <eliz at gnu dot org>]

> From: Pedro Alves <palves@redhat.com>
> Cc: simon.marchi@ericsson.com, gdb-patches@sourceware.org
> Date: Tue, 19 Apr 2016 16:40:30 +0100
> 
> >> GDB links with libgcc even when built as a C program.
> > 
> > Not here, it doesn't.  It is linked statically against libgcc. 
> 
> I don't see how linking statically removes the requirement to
> provide access to sources.

It does, because there's a special clause for that in the L?GPL, whch
only holds for static linking.

> I get, on a C++ gdb build:
> 
> $ objdump -x gdb.exe | fgrep "DLL Name:"
>         DLL Name: KERNEL32.dll
>         DLL Name: msvcrt.dll
>         DLL Name: libwinpthread-1.dll
>         DLL Name: USER32.dll
>         DLL Name: WS2_32.dll

Then there's no problem, and I apologize for the noise.  I thought
your previous message meant that there was a dynamic dependency on
libstdc++ DLL, sorry for my misunderstanding.

> >> How's C++ any different?
> > 
> > With C, you can get away by using "CC='gcc -static-libgcc'" at
> > configure time, but can you do the same with -static-libstdc++?  
> 
> You shouldn't even need that.  We already link with
> -static-libstdc++ -static-libgcc:

IME, programs that use libtool cannot easily do that, because libtool
removes any switches it doesn't know about from the GCC command line.

> x86_64-w64-mingw32-g++ -g -O2 -static-libstdc++ -static-libgcc -Wl,--stack,12582912 \
> -o gdb.exe gdb.o armbsd-tdep.o arm.o arm-linux.o arm-linux-tdep.o arm-get-next-pcs.o arm-symbian-tdep.o armnbsd-tdep.o
> ...
> 
> And we also link that way when building as a C program.
> 
> We haven't done anything specific to have that on the gdb side, it
> comes from the top level somewhere, I think originally for GCC, long
> ago.

Good, then the problem I feared doesn't really exist.  Thanks for
clearing that up.

> Since GCC is already building this way for a long time, it should not
> be a problem for GDB either.  Or at least if it is a problem, it's
> one you would already have with GCC.

I see too many precompiled binaries out there that depend on libgcc
DLL.  Most people think it is not a problem, so we don't hear any
complaints.  So the fact that GCC builds this way is in itself not an
evidence the problem doesn't exist.  For someone like myself, who
tries to be 100% GPL compatible with the binaries I make available,
having a GCC dependency is a huge downside, so I go an extra mile to
avoid that.

Once again, I'm happy to know there' no such problem with GDB.