On 2018-09-05 20:59, Martin Buchholz wrote:
So ... Magnus, are you happy with the current state of the proposed patch?
I'm sorry Martin, but I can't figure out what the current state is. I
tried backtracking the discussion but failed. :( Can you please repost
the currently proposed patch?
On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com <mailto:magnus.ihse.bur...@oracle.com>>
wrote:
For the gcc toolchain this can not be the case:
# Minimum supported linker versions, empty means unspecified
TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"
We make sure we have an ld that supports the basic flags we assume.
feature tests are better than version tests.
I've heard that argument many times, and I've never agreed with it. In
some cases, feature tests work. They typically work if someone has
designed a clear API and included a feature test in it. A lot of
additional POSIX functionality works that way. This means that you can
rest assure that if the feature is present, then you know what you are
going to get.
In most of the rest of the world, functionality does not raise to that
golden standard. Gcc adds a flag in one version, but it's buggy. A later
version fixes the bugs. A later version still changes the behavior of
the flag. Functionality that we depend on works or does not works
depending on the intersection of things like our code, compiler version,
operating system, and so on.
In my experience, it's a rare thing for a feature test to actually work.
Version tests, on the other hand, tests against a specific setup, that
can be tested and proven to work. The downside of version tests is that
they are often open-ended; we say that "anything above this version is
supposed to work", even though we have not tested with gcc 8 or 9. The
alternative is to say that "we've tested this between gcc 4.7 and 7.3
and will only support it for this version span", but that is in most
cases more likely to break when gcc 8 comes along.
Because there are various linkers in play (old GNU ld, gold, lld,
macosx ld, BSD ld) and we'd like our compilers to work the same way on
various platforms, I'm vaguely unhappy with
TOOLCHAIN_MINIMUM_LD_VERSION_gcc. It looks
like TOOLCHAIN_EXTRACT_LD_VERSION is another place where we conflate
toolchains and operating systems.
The linker is often in a situation where it's conflated between
toolchain and operating system. :-) I think it's more due to how the
linker is positioned/perceived, than due to a fault of ours. On Windows,
for instance, the linker is clearly a part of the toolchain. On solaris,
there's a system linker and the solstudio does not distribute any linker
on their own. On linux, the gcc toolchain actually allows you to select
linker (gold, etc), but arguably they belong to the gcc toolchain rather
than the OS.
We can add a similar check for the clang toolchain, if you want.
Mixing and matching compilers and linkers willy-nilly is not a
supported build option
As always, I am for portability and for toolchain competition. I'd
like to be able to build with Intel's icc toolchain.
That might be a noble goal, but it's not realistic. There's a huge cost
involved with supporting different combinations; the combinatorial
matrix blows up quickly, and if these different combinations are not
regularly tested, they *will* break.
That being said, I'm too in general in favor of supporting more rather
than less. But only as long as there's no high price to pay for the
common/reasonable combinations.
/Magnus
