From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86163 invoked by alias); 8 Feb 2018 23:00:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 85398 invoked by uid 89); 8 Feb 2018 23:00:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.9 required=5.0 tests=BAYES_00,TIME_LIMIT_EXCEEDED,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 spammy=soul, of=c2, for=c2, such?= 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; Thu, 08 Feb 2018 23:00:18 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8813B931AE; Thu, 8 Feb 2018 23:00:16 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-4.rdu2.redhat.com [10.10.112.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2DDA95C462; Thu, 8 Feb 2018 23:00:06 +0000 (UTC) Subject: Re: [PR bootstrap/56750] implement --disable-stage1-static-libs To: Aldy Hernandez , gcc-patches Cc: ebotcazou@libertysurf.fr References: <4d4e66a4-73c2-50bb-48d0-9319effb6830@redhat.com> From: Jeff Law Message-ID: Date: Thu, 08 Feb 2018 23:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <4d4e66a4-73c2-50bb-48d0-9319effb6830@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00471.txt.bz2 On 02/08/2018 04:42 AM, Aldy Hernandez wrote: > In this PR, the reporter is complaining that forcing -static-libstdc++ > and -static-libgcc during stage1 will also force it down to all > subdirectories (gdb for instance). > > There is some back and forth in the PR whether this is good or not.  I'm > indifferent, but an alternative is to provide a flag > --disable-stage1-static-libs to disable this behavior. > > Tested on an x86-64 Linux system with static libraries and verifying > that with --disable-stage1-static-libs we get an xgcc linked against > shared libraries of libstdc++ and libgcc: > > $ ldd xgcc >         linux-vdso.so.1 (0x00007ffe92084000) >         libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fec11a06000) >         libm.so.6 => /lib64/libm.so.6 (0x00007fec116fd000) >         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fec114e6000) >         libc.so.6 => /lib64/libc.so.6 (0x00007fec11120000) >         /lib64/ld-linux-x86-64.so.2 (0x0000557117206000) > > I also verified that without the flag or with > --enable-stage1-static-libs we get no such shared libraries. > > Again, I'm agnostic here.  We can just as easily close the PR and tell > users to specify --with-stage1-libs to override the static linking, as > I've mentioned in the PR. > > OK for trunk? > > curr.patch > > > > PR bootstrap/56750 > * configure.ac (stage1-static-libs): New option. > * configure: Regenerate. > > gcc/ > > PR bootstrap/56750 > * doc/install.texi (--enable-stage1-static-libs): New. You are a brave soul. Every time I look at 56750 I shake my head and say it's not worth the pain to untangle (sorry Mike). There's no single solution here that will satisfy everyone that I'm aware of. Given that there is a workaround that I think will work for the problems Mike is trying to address, I think this is a WONTFIX. Another configury option just adds more complexity here that we're not likely to test and is likely to bitrot over time. Go ahead with WONTFIX and if Mike complains, point him at me :-) jeff