From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91464 invoked by alias); 4 Nov 2016 14:46:09 -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 91431 invoked by uid 89); 4 Nov 2016 14:46:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=distros, Hx-languages-length:2297, subdirs, quality X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Nov 2016 14:46:07 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E40DA81255; Fri, 4 Nov 2016 14:46:05 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA4Ek4gI023157; Fri, 4 Nov 2016 10:46:04 -0400 Subject: Re: [PATCH 0/2] gdb: Require a C++11 compiler To: "Maciej W. Rozycki" References: <1477596094-3244-1-git-send-email-palves@redhat.com> <2f6931ce-8286-9b97-3a67-8228becfa424@arm.com> <7437e071-2020-2e0d-0f8b-8269767d157b@redhat.com> Cc: "Richard Earnshaw (lists)" , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <03f1e01a-dff7-0b67-dd94-e177e520f64f@redhat.com> Date: Fri, 04 Nov 2016 14:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00096.txt.bz2 On 11/04/2016 01:31 PM, Maciej W. Rozycki wrote: > On Tue, 1 Nov 2016, Pedro Alves wrote: > >>> to mess with either forcing static linking or worse, forcing uses to >>> mess with non-standard LD_LIBRARY paths at run time. >> >> Note that just like gcc, gdb builds with -static-libstdc++ -static-libgcc. > > Are you sure? All my recent cross-built `gdbserver' executables failed > to run without a pain of getting `libstdc++.so' in the right place on the > target. Or do you mean GDB proper only? I didn't even realise there was > intention to use static `libstdc++' and/or `libgcc' libraries. Hmm. I do see it on my builds. $ rm gdbserver && make gdbserver 2>&1 | grep static ... -Wformat-nonliteral -Werror -DGDBSERVER -static-libstdc++ -static-libgcc ... I guess the the difference is that I'm looking at a native build, which means that gdb/gdbserver/configure is run as a subdir of the gdb configure which in turn is a subdir of the top level configure. It's the top level configure that adds the -static-*: ... # Check whether -static-libstdc++ -static-libgcc is supported. ... But if you cross-build gdbserver, you'll be running gdbserver's configure directly, bypassing the top level, and thus miss that. Maybe we should move that bit of configure code to an .m4 file under src/config/, and then the different subdirs could include use of it as they saw fit. Maybe even make it optional under a configure --whatever option. Maybe distros would prefer disabling that. (Or make gdbserver be the toplevel subdir, but even though desirable, that's obviously a much larger change...) > Also I've not been particularly happy with the project moving over to C++ > let alone C++11, however I have just decided I couldn't afford the effort > to go through all the discussion, which always takes time pinched from > other commitments. Being a CPU target maintainer only and with my rusty > 1995-vintage C++ programming skills -- making it difficult to me to assess > what the advantages of modern C++ dialects might be -- I didn't want to > stand in the way of core developers if they think a move to C++ will make > their job easier, improving code quality and reducing maintenance burden. > Thanks for understanding. Thanks, Pedro Alves