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>
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.
The size of WINEPATH is limited (1024 [until recently]), we
can very easily reach that limit, and even the new one (2048) so
try to keep path as small as possible by using the shortPath
version of paths.
Also assert that we do not reach the new hard limit.
And avoid having duplicates in the list of path.
[until recently]: https://bugs.winehq.org/show_bug.cgi?id=45810
* intel-cl tests: more rigorous detection of intent to use Intel Windows compilers
* fortran coarray test: make skipping more robust in that underlying MPI stack is .run()
This is useful for any Fortran coarray work, and especially for intel-cl where multiple Intel compiler
versions are often installed, and the wrong underlying MPI library may be dynamically linked,
and so a runtime check is needed to exercise the MPI stack underlying Fortran coarray.
This is done by
fc.run('sync all; end', dependencies: coarray)
* pep8
* backends/vs: Only set platform_toolset if it isn't already set
* interpreter: set backend up after the compiler
Otherwise we won't be able to check which VS toolchain to use.
* docs/using-visual-studio: wrap lines
* docs: recommend the py launcher instead of python3 for windows
* set backend.environment when building a dummy version
* backends/vs: Add support for clang-cl with vs2017 and vs2019 backends
* backends/vs: Add support for ICL (19.x) with vs2015 and vs2017 backends