From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32520 invoked by alias); 19 Apr 2016 15:59:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32311 invoked by uid 89); 19 Apr 2016 15:59:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=evidence, mile, Hx-languages-length:2476, HX-Received-From:4830 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 19 Apr 2016 15:59:44 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asY3r-0000tE-Kt for gdb-patches@sourceware.org; Tue, 19 Apr 2016 11:59:41 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asY3r-0000tA-H2; Tue, 19 Apr 2016 11:59:35 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2520 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1asY3q-0006rS-Pi; Tue, 19 Apr 2016 11:59:35 -0400 Date: Tue, 19 Apr 2016 15:59:00 -0000 Message-Id: <834max8u8z.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: simon.marchi@ericsson.com, gdb-patches@sourceware.org In-reply-to: <5716516E.4020607@redhat.com> (message from Pedro Alves on Tue, 19 Apr 2016 16:40:30 +0100) Subject: Re: [PATCH 0/1] Build GDB as a C++ program by default Reply-to: Eli Zaretskii References: <1461000466-31668-1-git-send-email-palves@redhat.com> <571633C8.4060803@ericsson.com> <57163E3B.50101@redhat.com> <83d1pl8xje.fsf@gnu.org> <571648CD.7070705@redhat.com> <838u098vxk.fsf@gnu.org> <5716516E.4020607@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00459.txt.bz2 > From: Pedro Alves > 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.