From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9165 invoked by alias); 7 Jan 2017 10:22:18 -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 9155 invoked by uid 89); 7 Jan 2017 10:22:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: einhorn.in-berlin.de Received: from einhorn.in-berlin.de (HELO einhorn.in-berlin.de) (192.109.42.8) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 07 Jan 2017 10:22:14 +0000 X-Envelope-From: doko@ubuntu.com X-Envelope-To: Received: from [192.168.178.26] (ip5f5af460.dynamic.kabel-deutschland.de [95.90.244.96]) (authenticated bits=0) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v07AMBpt027584 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 7 Jan 2017 11:22:12 +0100 Subject: Re: .../lib/gcc//7.1.1/ vs. .../lib/gcc//7/ To: gcc@gcc.gnu.org References: <20170106124826.GJ21933@tucnak> <586F968B.2010301@arm.com> <20170106131151.GM21933@tucnak> <586FA5F1.1080400@arm.com> From: Matthias Klose Message-ID: <1d5c12b2-c0e8-6ed7-461b-04f21e6dd143@ubuntu.com> Date: Sat, 07 Jan 2017 10:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <586FA5F1.1080400@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00048.txt.bz2 On 06.01.2017 15:13, 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. > > that would be nice to fix, so build scripts don't > have to manually delete the bogus la files. > >> (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. You also end up with dependencies of the form /usr/lib/gcc///../../.././include which then break when you update to a new branch version.