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: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: simon dot marchi at ericsson dot com, gdb-patches at sourceware dot org
- Date: Tue, 19 Apr 2016 18:23:03 +0300
- 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>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Cc: firstname.lastname@example.org, email@example.com
> From: Pedro Alves <firstname.lastname@example.org>
> Date: Tue, 19 Apr 2016 16:03:41 +0100
> On 04/19/2016 03:48 PM, Eli Zaretskii wrote:
> >> From: Pedro Alves <email@example.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 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
(standard input):73: DLL Name: libguile-2.0-22.dll
(standard input):204: DLL Name: KERNEL32.dll
(standard input):298: DLL Name: msvcrt.dll
(standard input):323: DLL Name: msvcrt.dll
(standard input):450: DLL Name: libncurses5.dll
(standard input):501: DLL Name: USER32.dll
(standard input):510: DLL Name: WS2_32.dll
(standard input):531: DLL Name: zlib1.dll
(standard input):542: DLL Name: python26.dll
This is a build that (as you see) supports TUI, Python, and Guile, so
it's as full as it gets.
> 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++? 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).