From: Matthias Klose <doko@ubuntu.com>
To: gcc@gcc.gnu.org
Subject: Re: .../lib/gcc/<triplet>/7.1.1/ vs. .../lib/gcc/<triplet>/7/
Date: Sat, 07 Jan 2017 10:22:00 -0000 [thread overview]
Message-ID: <1d5c12b2-c0e8-6ed7-461b-04f21e6dd143@ubuntu.com> (raw)
In-Reply-To: <586FA5F1.1080400@arm.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
> 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.
next prev parent reply other threads:[~2017-01-07 10:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 12:48 Jakub Jelinek
2017-01-06 13:07 ` Szabolcs Nagy
2017-01-06 13:12 ` Jakub Jelinek
2017-01-06 14:13 ` Szabolcs Nagy
2017-01-06 14:21 ` Jakub Jelinek
2017-01-07 10:22 ` Matthias Klose [this message]
2017-01-06 17:51 ` Richard Biener
2017-01-07 10:35 ` Matthias Klose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d5c12b2-c0e8-6ed7-461b-04f21e6dd143@ubuntu.com \
--to=doko@ubuntu.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).