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: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: <nd at arm dot com>, <gcc at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Fri, 6 Jan 2017 14:13:05 +0000
- Subject: Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <20170106124826.GJ21933@tucnak> <586F968B.email@example.com> <20170106131151.GM21933@tucnak>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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