This is the mail archive of the
mailing list for the GCC project.
Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/
- From: Matthias Klose <doko at ubuntu dot com>
- To: gcc at gcc dot gnu dot org
- Date: Sat, 7 Jan 2017 11:22:11 +0100
- Subject: Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/
- Authentication-results: sourceware.org; auth=none
- References: <20170106124826.GJ21933@tucnak> <586F968B.firstname.lastname@example.org> <20170106131151.GM21933@tucnak> <586FA5F1.email@example.com>
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
You also end up with dependencies of the form
/usr/lib/gcc/<target>/<version>/../../.././include which then break when you
update to a new branch version.