This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 0/1] Build GDB as a C++ program by default
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: simon dot marchi at ericsson dot com, gdb-patches at sourceware dot org
- Date: Tue, 19 Apr 2016 16:40:30 +0100
- Subject: Re: [PATCH 0/1] Build GDB as a C++ program by default
- Authentication-results: sourceware.org; auth=none
- References: <1461000466-31668-1-git-send-email-palves at redhat dot com> <571633C8 dot 4060803 at ericsson dot com> <57163E3B dot 50101 at redhat dot com> <83d1pl8xje dot fsf at gnu dot org> <571648CD dot 7070705 at redhat dot com> <838u098vxk dot fsf at gnu dot org>
On 04/19/2016 04:23 PM, Eli Zaretskii wrote:
>> Cc: email@example.com, firstname.lastname@example.org
>> From: Pedro Alves <email@example.com>
>> Date: Tue, 19 Apr 2016 16:03:41 +0100
>> On 04/19/2016 03:48 PM, Eli Zaretskii wrote:
>>>> From: Pedro Alves <firstname.lastname@example.org>
>>>> 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.
> 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
> 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
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
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).