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

[Pedro Alves <palves@redhat.com>]

On 04/19/2016 04:23 PM, Eli Zaretskii wrote:
>> Cc: simon.marchi@ericsson.com, gdb-patches@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 19 Apr 2016 16:03:41 +0100
>>
>> On 04/19/2016 03:48 PM, Eli Zaretskii wrote:
>>>> From: Pedro Alves <palves@redhat.com>
>>>> Date: Tue, 19 Apr 2016 15:18:35 +0100
>>>>
>>>> MinGW (w64) builds and runs cleanly for me too.
>>>
>>> Did you look at what libraries it depends on?  Doesn't it pull in
>>> libgcc DLL and libstdc++ DLL?  If it does, that'll put a huge damper
>>> on those who make precompiled binaries of GDB available for Windows
>>> users, because you need to accompany that with the full GCC source
>>> tarball, which weighs in at more than 80MB.
>>
>> 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.

> (I
> don't use MinGW64, but I don't think it matters.)  Here's what
> 'objdump -x | fgrep "DLL Name:"' says about the latest GDB 7.11 I
> built:
> 

...

> This is a build that (as you see) supports TUI, Python, and Guile, so
> it's as full as it gets.

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


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

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.

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 had
> bad experience with that in the past (the binary still depended on
> libstdc++ DLL), but maybe that was when building shared libraries, not
> .exe programs.  Thus my question (sorry, didn't yet have time to build
> a recent development snapshot of GDB).

Thanks,
Pedro Alves