Versioning of executables is not related to the operating system kernel.
It is possible for a Linux distribution to support multiple versions of
LLVM in a way similar to FreeBSD. For example, on Debian, you can use
'apt install clang-tools-7' to install the versioned 'scan-build-7'
executable without bringing the unversioned 'scan-build' into the
environment. Therefore, we should not skip the version list on Linux.
It also makes it consistent with the behavior of llvm dependency, which
does not change the search list depending on the operating system.
This commit also fixes the version suffix for Debian. Debian stops using
the minor version number on the executable after version 7, so it should
be 'scan-build-7', not 'scan-build-7.0'.
This is a follow-up of https://github.com/mesonbuild/meson/pull/5918.
According to http://testanything.org/tap-specification.html
"Any output line that is not a version, a plan, a test line, a
diagnostic or a bail out is considered an “unknown” line. A TAP parser
is required to not consider an unknown line as an error but may
optionally choose to capture said line and hand it to the test
harness, which may have custom behavior attached [...] TAP::Harness
reports TAP syntax errors at the end of a test run".
(glib gtest can generate empty lines)
The main library must come before extra libraries, because they are
likely to be dependencies of the main library that get promoted from
private to public. This was causing static link issues with glib-2.0.pc.
Detect scan-build the same way when trying to launch it and when
generating the target.
The detection method is:
1. look within SCANBUILD env variable
2. shutil.which('scan-build')
3. *on non-linux platforms only*: go through all the possible
name candidates and test them individually.
The third step is added following this comment
https://github.com/mesonbuild/meson/pull/5857#issuecomment-528305788
However, going through a list of all the possible candidates is neither
easily maintainable nor performant, and is therefore skipped on
platforms that should not require such a step (currently, only Linux
platforms).
This is a follow-up to the issue raised by @lantw44 during PR:
https://github.com/mesonbuild/meson/pull/5857
Solaris puts 32-bit libraries in the main /lib & /usr/lib directories
and 64-bit libraries in platform specific subdirectories.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Solaris doesn't ship static libraries, so the test can't rely on libz.a
existing on Solaris.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If the Python binary that we find doesn't return valid JSON when asked to run a
small script, show the command being ran and stdout/stderr in meson-log.txt.
Fixes: #5914
Without this change, the test fails with:
[11/12] Linking target square-gen-test.
warning: Text relocation remains referenced
against symbol offset in file
square_unsigned 0x15 square-gen-test@exe/main.c.o
[12/12] Linking target square-ct-test.
warning: Text relocation remains referenced
against symbol offset in file
square_unsigned 0x15 square-ct-test@exe/main.c.o
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Solaris 11.3 & earlier sent the --version output to stderr, but
Solaris 11.4 moved it to stdout in an attempt to be more compatible
with the GNU tools, so look for it in both streams of output.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
llvm-mingw uses a wrapper script to inject (among other things) a
-target argument into the clang command, which breaks -Wl,--version.
This confuses Meson into thinking the linker is some unknown version of
Apple ld, which breaks builds.
This patch makes it detect and recover from the issue.
Fixes#5910
I originally liked "solaris", but I've changed my mind. Both illumos
(the open-source fork of OpenSolaris) and Oracle's closed-source
Solaris are identified by the same token, and there are differences
between them; so using "sunos" as a sort "supertype" for both makes
sense to me.
On illumos (and presumably Solaris, though I can't test) cc normally
points to Sun CC, which we don't support. So ensure that gcc is used
explicitly in that case.
* Do not strip static archives
Stripping static archives without more fine-grained options (e.g. `-g`)
leads to failures such as
ld: libfoo.a: error adding symbols: archive has no index; run ranlib to add one
because GNU strip removes *every* symbol in a static archive by default.
Given that static archives are not final build artifacts (unlike
executables and shared libraries), stripping them gains little and only
causes more edge case failures.
* Gentoo's portage only strips debug information:
86f211e3a5/bin/estrip (L322)
* Fedora also only strips debug information:
e9c13c6565/scripts/brp-strip-static-archive (L18)
* Debian also only does some very light stripping:
72ed1d3261/dh_strip (L374)Fixes#4138
* Add test case for static archive stripping
In msetup the two positional arguments build-dir and source-dir
are added to the argument parser in this order.
This also affects the help message.
This order is different from the order given in the man page.
Therefore it is switched around in the man page to make it consistent
with the help message.
As the code automatically decides which directory contains what, this
change is only cosmetic. Both argument orders should be valid.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
Andrei Alexeyev
Aleksey Gurtovoy
Daniel Mensinger
Nathan Rossi
David Cantrell
Jussi Pakkanen
Ting-Wei Lan
Xavier Claessens
Zbigniew Jędrzejewski-Szmek
Patrick Griffis
Marc-André Lureau
Khairul Azhar Kasmiran
Jehan
jimbo1qaz
Gabriel Ganne
Alan Coopersmith
Ross Burton
Dylan Baker
David Seifert
David Seifert
Nguyen, Giang (G. Yakiro)
dundir
Fabian Bläse
Michael Hirsch, Ph.D