This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/

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/<target>/<version>/../../.././include which then break when you
update to a new branch version.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]