From patchwork Wed Jul 17 19:10:36 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 33728 Received: (qmail 124448 invoked by alias); 17 Jul 2019 19:10:45 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 124435 invoked by uid 89); 17 Jul 2019 19:10:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jul 2019 19:10:40 +0000 Received: by mail-wr1-f65.google.com with SMTP id f9so25965645wre.12 for ; Wed, 17 Jul 2019 12:10:39 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id l17sm11428540wrr.94.2019.07.17.12.10.37 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2019 12:10:37 -0700 (PDT) Subject: Re: [PATCH] Add Rust support to source highlighting To: Tom Tromey References: <20190624220539.16360-1-tom@tromey.com> <87ef3d2402.fsf@tromey.com> <8736jprcf0.fsf@tromey.com> <3b327ad7-36fe-018d-93aa-3d7ea541a80e@simark.ca> <5a328e97-4cc1-16de-36ac-8dd1a3860e87@redhat.com> <878st1zzp6.fsf@tromey.com> <87ims0zh1h.fsf@tromey.com> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Wed, 17 Jul 2019 20:10:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87ims0zh1h.fsf@tromey.com> On 7/17/19 6:50 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > >>> It seems like a bit of a pain to fix at top-level. These flags are put >>> into the default LDFLAGS for stage1, or when not bootstrapping. > > Pedro> Can you expand on why is it a pain? I was imagining that the top-level > Pedro> script would take in consideration whether a gcc/ subdir exists, in > Pedro> addition to checking some --{enable,disable}-static-runtime or some such, > Pedro> where it adds the flags to LDFLAGS. > > The main problem is that the flags are passed down from the top-level > Makefile, so it would need extra top-level Makefile.* hacking. I'm not sure we're talking about the same thing. See below for what I had in mind. > > Pedro> I assume it is put in LDFLAGS for the whole tree in order to > Pedro> use -static-libcc consistently for both gcc and the libraries it > Pedro> depends on (like libiberty). (It'd be interesting to find the > Pedro> rationale in the original mailing list post/patch that added it to > Pedro> be sure.) > > Pedro> With what you're suggesting it sounds like we'd build libiberty/, libbfd/, > Pedro> etc. with -static-libgcc and gdb/ without? That sounds like something > Pedro> we shouldn't be doing either. > > Are those even useful for libiberty or bfd? I thought those only > affected the link. I'm not sure they only affect the link, but I do think so. > > Or do people build a shared libiberty and/or bfd? That seems bad. > We have things like this in the top level configure: # Sometimes we have special requirements for the host libiberty. extra_host_libiberty_configure_flags= extra_host_zlib_configure_flags= case " $configdirs " in *" lto-plugin "* | *" libcc1 "*) # When these are to be built as shared libraries, the same applies to # libiberty. extra_host_libiberty_configure_flags=--enable-shared ;; *" bfd "*) # When bfd is to be built as a shared library, the same applies to # zlib. if test "$enable_shared" = "yes"; then extra_host_zlib_configure_flags=--enable-host-shared fi ;; esac AC_SUBST(extra_host_libiberty_configure_flags) AC_SUBST(extra_host_zlib_configure_flags) And: $ ./src/configure --help | grep host-shared --enable-host-shared build host code as shared libraries So it does looks like it people do that. From a2d01e2138a28be2a32978f38298e6b7dd99e7d4 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Wed, 17 Jul 2019 16:07:20 +0100 Subject: [PATCH] gcc --- configure | 2 +- configure.ac | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 4d111486926..f1cc1cf9e56 100755 --- a/configure +++ b/configure @@ -5838,7 +5838,7 @@ else # In stage 1, default to linking libstdc++ and libgcc statically with GCC # if supported. But if the user explicitly specified the libraries to use, # trust that they are doing what they want. - if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then + if test -d ${srcdir}/gcc -a test "$stage1_libs" = "" -a "$have_static_libs" = yes; then stage1_ldflags="-static-libstdc++ -static-libgcc" fi fi diff --git a/configure.ac b/configure.ac index 854f71a34e5..2c85b8d7374 100644 --- a/configure.ac +++ b/configure.ac @@ -1614,7 +1614,7 @@ AC_ARG_WITH(stage1-ldflags, # In stage 1, default to linking libstdc++ and libgcc statically with GCC # if supported. But if the user explicitly specified the libraries to use, # trust that they are doing what they want. - if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then + if test -d ${srcdir}/gcc -a test "$stage1_libs" = "" -a "$have_static_libs" = yes; then stage1_ldflags="-static-libstdc++ -static-libgcc" fi]) AC_SUBST(stage1_ldflags)