From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65338 invoked by alias); 6 Jan 2017 14:21:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 63232 invoked by uid 89); 6 Jan 2017 14:21:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:586FA5F, H*f:sk:586FA5F, H*MI:sk:586FA5F 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, 06 Jan 2017 14:21:54 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 423AF4E4F2; Fri, 6 Jan 2017 14:21:54 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-54.ams2.redhat.com [10.36.116.54]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v06ELqMA004225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Jan 2017 09:21:53 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v06ELm4h001638; Fri, 6 Jan 2017 15:21:48 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v06ELkR5001637; Fri, 6 Jan 2017 15:21:46 +0100 Date: Fri, 06 Jan 2017 14:21:00 -0000 From: Jakub Jelinek To: Szabolcs Nagy Cc: nd@arm.com, gcc@gcc.gnu.org, Richard Biener Subject: Re: .../lib/gcc//7.1.1/ vs. .../lib/gcc//7/ Message-ID: <20170106142146.GN21933@tucnak> Reply-To: Jakub Jelinek References: <20170106124826.GJ21933@tucnak> <586F968B.2010301@arm.com> <20170106131151.GM21933@tucnak> <586FA5F1.1080400@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <586FA5F1.1080400@arm.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00038.txt.bz2 On Fri, Jan 06, 2017 at 02:13:05PM +0000, Szabolcs Nagy wrote: > On 06/01/17 13:11, Jakub Jelinek wrote: > > On Fri, Jan 06, 2017 at 01:07:23PM +0000, Szabolcs Nagy wrote: > >> On 06/01/17 12:48, Jakub Jelinek wrote: > >>> SUSE and some other distros use a hack that omits the minor and patchlevel > >>> versions from the directory layout, just uses the major number, it is very > >> > >> what is the benefit? > > > > Various packages use the paths to gcc libraries/includes etc. in various > > places (e.g. libtool, *.la files, etc.). So any time you upgrade gcc > > it is a bug that gcc installs libtool la files, > because a normal cross toolchain is relocatable > but the la files have abs path in them. I'm not talking about *.la files installed by gcc. I'm talking about any *.la files created by libtool or libtool scripts themselves. There are libtool hacks floating around that avoid the gcc internal paths, but I think it is not in upstream libtool. > > (say from 6.1.0 to 6.2.0 or 6.2.0 to 6.2.1), everything that has those paths > > needs to be rebuilt. By having only the major number in the paths (which is > > pretty much all that matters), you only have to rebuild when the major > > version of gcc changes (at which time one usually want to mass rebuild > > everything anyway). > > i thought only the gcc driver needs to know > these paths because there are no shared libs > there that are linked into binaries so no binary > references those paths so nothing have to be > rebuilt. That is not the case, various programs just store the gcc -print-file-name= paths in various locations. Some query it at runtime (not sure what e.g. clang++ does when it wants to use libstdc++ headers), others store it. Jakub