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
