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>
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
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
* 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
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
as what was done with clang-format, test the presence of the tool before
generating a dedicated target. Pass silently if scan-build is not found.
Signed-off-by: Gabriel Ganne <gabriel.ganne@mindmaze.ch>
The regex was incorrect, so it was matching 'ARM64' with 'ARM'.
Make the regex more specific so that it matches:
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27031.1 for x64
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27031.1 for x86
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27031.1 for ARM64
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
etc.