This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm 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 15:21:46 +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.2010301@arm.com> <20170106131151.GM21933@tucnak> <586FA5F1.1080400@arm.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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=<something> 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