aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild/compilers
AgeCommit message (Collapse)AuthorFilesLines
2024-04-05Merge pull request #12144 from amyspark/fix-msvc-clangcl-linker-flag-detectionJussi Pakkanen2-1/+26
linkers: Fix detection of link arguments to Clang(-cl) + MSVC
2024-04-03Fix regression in TI CGT supportWill Toohey1-6/+5
When C6000 support was added in #12246, TI compilers were given the correct version argument. This broke the previous check which relied on an error being thrown by the compiler.
2024-04-01nasm: Add support for .nasm file extension (#13027)Junior Rantila1-1/+1
2024-03-28compilers: cpp: reduce macro pollution for stdlib macrosSam James1-15/+20
Now that we have access to Environment in get_assert_args, we can check what the actual C++ stdlib provider is and only set relevant macros rather than all possibly-relevant ones based on the compiler. Also, while we're here, now that's sorted, wire up the GCC experimental libc++ support in the macro emission given it doesn't uglify anything for libstdc++ users now. Bug: https://github.com/mesonbuild/meson/issues/12962 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-03-28compilers: cpp: factor out C++ stdlib detectionSam James1-5/+8
We're going to use it in some more places in a minute (for controlling assertions). Bug: https://github.com/mesonbuild/meson/issues/12962 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-03-28Pass Environment down from BackendSam James6-12/+12
We'll need it in a moment for get_base_compile_args -> get_assert_args. Bug: https://github.com/mesonbuild/meson/issues/12962 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-03-28compilers: cpp: don't set stdlib assertion macros if already setSam James1-0/+11
Followup to 90098473d51e6f059e775f1833b0a2ea91c8f8f9. If the compiler already has one of these assertion macros [0] set, then don't interfere. e.g. a Linux distribution might be setting a stricter default than usual. This is a pitfall many fell into with _FORTIFY_SOURCE and it's why AX_ADD_FORTIFY_SOURCE [1] was contributed to autoconf-archive. [0] _GLIBCXX_ASSERTIONS, _LIBCPP_HARDENING_MODE, or _LIBCPP_ENABLE_ASSERTIONS. [1] https://www.gnu.org/software/autoconf-archive/ax_add_fortify_source.html Bug: https://github.com/mesonbuild/meson/issues/12962 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-03-28compilers: cpp: relax assertion level for libc++Sam James1-1/+1
Followup to 90098473d51e6f059e775f1833b0a2ea91c8f8f9. I changed my mind on this a few times. libcxx's documentation describes [0] the hardening modes as: """ 1) Unchecked mode/none, which disables all hardening checks. 2) Fast mode, which contains a set of security-critical checks that can be done with relatively little overhead in constant time and are intended to be used in production. We recommend most projects adopt this. 3) Extensive mode, which contains all the checks from fast mode and some additional checks for undefined behavior that incur relatively little overhead but aren’t security-critical. Production builds requiring a broader set of checks than fast mode should consider enabling extensive mode. The additional rigour impacts performance more than fast mode: we recommend benchmarking to determine if that is acceptable for your program. 4) Debug mode, which enables all the available checks in the library, including internal assertions, some of which might be very expensive. This mode is intended to be used for testing, not in production. """ We chose 3) before because it felt like a better fit for what we're trying to do and the most equivalent option to libstdc++'s _GLIBCXX_ASSERTIONS, but on reflection, maybe we're better off picking a default with less overhead and more importantly guarantees constant time checks. [0] https://libcxx.llvm.org/Hardening.html#using-hardening-modes Bug: https://github.com/mesonbuild/meson/issues/12962 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-03-15Improve error messages for invalid option valuesCharles Brunet10-194/+234
By adding the option name to UserOption object, it is now possible to display the name of the affected option when the given option value is not valid. Fixes #12635
2024-03-15rust: Get native-static-libs even when it cannot run host binariesXavier Claessens1-9/+14
When rustc cannot run host binaries it does an early return which skipped getting native-static-libs. Move that code earlier to always run it. While at it, failing to determine those libs is a fatal error. We would crash later when trying to access rustc.native_static_libs attribute otherwise.
2024-03-15compilers: No need to pass exe_wrapper everywhereXavier Claessens11-209/+157
Places where compiler needs it already have access to Environment object and can use it directly. This fixes mypy complaining that not all compilers have self.exe_wrapper in run() method that got moved to base class.
2024-03-15compilers: Allow setting env and workdir for run checksXavier Claessens2-4/+8
This is not exposed in API, but will be used internally.
2024-03-15compilers: Do not dump File content in log for compiler checks.Xavier Claessens1-7/+3
When doing a compiler check with a File object, there is no need to dump the file into logs, we can just print the path. The file could potentially be big.
2024-03-15compilers: Every compiler can run codeXavier Claessens3-52/+25
Compiling and linking code is part of the Compiler base class, there is no reason it cannot also run executables.
2024-03-13compilers: cpp: improve libc++ vs libstdc++ detection (again)Sam James1-11/+8
The previous approach wasn't great because you couldn't control what the detected C++ stdlib impl was. We just had a preference list we tweaked the searched order for per OS. That doesn't work great for e.g. Gentoo with libc++ or Gentoo Prefix on macOS where we might be using libstdc++ even though the host is libc++. Jonathan Wakely, the libstdc++ maintainer, gave a helpful answer on how to best detect libc++ vs libstdc++ via macros on SO [0]. Implement it. TL;DR: Use <version> from C++20 if we can, use <ciso646> otherwise. Check for _LIBCPP_VERSION as libstdc++ doesn't always define a macro. [0] https://stackoverflow.com/a/31658120 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-03-12Added support for Texas Instruments C6000 compiler.Petr Machacek4-14/+34
2024-03-11Only link to generated pch object when using msvc. (#12957)Elliot2-0/+7
backend: Only link to generated pch object when using msvc
2024-03-10fix reconfigure subproject base optionsCharles Brunet1-2/+2
2024-03-06cuda: respect host compiler `-Werror`David Seifert1-1/+3
The cuda compiler also executes the host compiler and generally needs to know the host compiler flags. We did this for regular args but not for error args. We use `-Xcompiler=` since that's how nvcc tells the difference between args it uses itself for device code and args it passes to the host compiler. Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> [eli: fix quoting style]
2024-03-03compilers: only wrap multiple input libraries with start/end groupEli Schwartz1-1/+2
When only a single input file shows up in an arglist, it makes no sense to inject `-W,--start-group -lone -Wl,--end-group`, since there is nothing being grouped together. It's just longer command lines for nothing.
2024-03-03compilers: avoid catching -Wl,-soname and wrapping with start/end groupEli Schwartz1-1/+1
This is just a bad regex match, because it matches *.so as a prospective filename input even though it is actually not an input but a linker flag. --start-group is only relevant to input files...
2024-03-01Fix base and compiler options not reconfigurable.Charles Brunet1-1/+1
Fixes #12920.
2024-02-28nvcc: avoid adding `-Wpedantic` to compile linesDavid Seifert1-1/+7
* `-Wpedantic` creates useless churn due to its use of gcc-line directives: ../foo.cu:1:3: warning: style of line directive is a GCC extension 1 | namespace Foo { | ^~ https://stackoverflow.com/a/31001220
2024-02-26Fix lint warning.Jussi Pakkanen1-8/+4
2024-02-25clang: Fix tests that use /DEF for MSVC LINK.exeL. E. Segovia1-0/+7
2024-02-25compilers: Forward Meson's preference of lld-link to clang-clL. E. Segovia1-0/+12
The latter prefers LINK.exe by default, which rejects GNU-like linker flags.
2024-02-25linkers: Fix detection of link arguments to Clang(-cl) + MSVCL. E. Segovia1-1/+7
Currently, not only Meson lacks a way to induce a "--fatal-warnings" on LINK.exe, it is also unable to pass flags appropriately when using clang-cl or Microsoft's stock clang. This commit fixes it by implementing `fatal_warnings()` in the MSVCDynamicLinker and ClangCLDynamicLinker classes, and by implementing the requisite conversion steps in linker_to_compiler_args for ClangCompiler.
2024-02-24compilers/detect: Implemented logic for checking suffixed LLVM tools before nondragonmux1-1/+5
2024-02-23compilers: 'H' is a C++ headerDylan Baker1-1/+1
We list other C++ header types in this list, so H should be included
2024-02-12compilers: fix inconsistent None-breaking return value for compile()Eli Schwartz1-3/+3
Since commit abc7e6af01714206100a752898c325282436501f it is not possible for this set of methods to return None, which was an odd thing to return to begin with. Cease to annotate it as such.
2024-02-05Turn on strict mode, as it is no longer the default since Python 3.6U2FsdGVkX11-3/+6
2024-02-04Fix ninja cannot find the library when libraries contain symlinks.U2FsdGVkX11-7/+4
2024-02-02fix UnboundLocalError if guess_win_linker fails in detect_fortran_compilerH. Vetinari1-0/+1
2024-01-26Differentiate message between dynamic linker and archiverDylan Baker1-1/+1
Currently both print `Detecting linker via`, which can be confusing. Clarifying this by printing "archiver" instead of "linker" for the static linker/archiver
2024-01-18Compilers: pass -Werror to the linker with b_ltoSam James1-0/+3
With LTO, the linker will re-execute the compiler and various warnings may be emitted. We must therefore pass -Werror to the linker as well when -Werror is enabled to capture these. This is only required / useful with LTO. Closes: https://github.com/mesonbuild/meson/issues/7360 Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-01-17rust: fix linking static executablesAlyssa Ross1-0/+7
For the same reason as for static libraries, we have to use -l when generating static executables. Fixes: https://github.com/mesonbuild/meson/issues/12585
2024-01-15compilers: add c23 and gnu23 c_stdsSimon Ser1-1/+7
Closes: https://github.com/mesonbuild/meson/issues/12702
2024-01-09compilers: cpp: wire up debugstl for ClangSam James1-0/+13
For Clang, we now pass -D_GLIBCXX_DEBUG=1 if debugstl is enabled, and we also pass -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG. Per https://discourse.llvm.org/t/building-a-program-with-d-libcpp-debug-1-against-a-libc-that-is-not-itself-built-with-that-define/59176/3, we can't use _LIBCPP_DEBUG for older Clang versions as it's unreliable unless libc++ was built with it. We choose MODE_DEBUG for stldebug while building with assertions will do MODE_EXTENSIVE. Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2024-01-09compilers: cpp: wire up stdlib assertionsSam James1-0/+22
None of the options set here affect ABI and are intended for detecting constraint violations. For GCC, we simply need to set -D_GLIBCXX_ASSERTIONS. For Clang, the situation is far more complicated: * LLVM 18 uses a 'hardened mode' (https://libcxx.llvm.org/Hardening.html). There are several levels of severity available here. I've chosen _LIBCPP_HARDENING_MODE_EXTENSIVE as the strongest-but-one. The strongest one (_DEBUG) doesn't affect ABI still but is reserved for stldebug. * LLVM 15 uses a similar approach to libstdc++ called '_LIBCPP_ENABLE_ASSERTIONS' Note that LLVM 17 while in development had fully deprecated _LIBCPP_ENABLE_ASSERTIONS in favour of hardened, but changed its mind last-minute: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925/4. Signed-off-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
2023-12-26nvcc compiler: support find dependency header fileswrvsrx1-0/+9
This commit supersedes PR #11229 and #10993. It also adds version check according to [comments](https://github.com/mesonbuild/meson/pull/11229#issuecomment-1370287546)
2023-12-26Revert "clike: Deduplicate rpath linker flags"Eli Schwartz1-1/+1
This reverts commit 53ea59ad8455277797117d225f326851fe7d369c. This breaks at least: - frameworks/17 mpi - frameworks/30 scalapack The problem is that openmpi's pkg-config emitted link arguments includes: ``` -Wl,-rpath -Wl,/path/to/libdir ``` The deduplication logic in meson doesn't contain sufficient information to tell when the compiler is passing an argument that requires values, and definitely cannot tell when that argument is split across argv. But for arguments that *can* do this, it is not possible to deduplicate a single argument as standalone, because it is not standalone. The argument for deduplicating rpath here was that if you have multiple dependencies that all add the same rpath, the Apple ld64 emits a non-fatal warning "duplicate -rpath ignored". Since this is non-fatal, it's not a major issue. A major issue is when builds fatally error out with: ``` FAILED: scalapack_c cc -o scalapack_c scalapack_c.p/main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group /usr/lib64/libscalapack.so /usr/lib64/liblapack.so /usr/lib64/libblas.so -Wl,-rpath -Wl,/usr/lib64 -Wl,/usr/lib64 -Wl,--enable-new-dtags /usr/lib64/libmpi.so -Wl,--end-group /usr/libexec/gcc/x86_64-pc-linux-gnu/ld: error: /usr/lib64: read: Is a directory ```
2023-12-23Remove `get_buildtype_args` functionCharles Brunet22-312/+75
This is a first step to make `buildtype` a true alias of `debug` and `optimization` options. See #10808. Relates to: - #11645 - #12096 - #5920 - #5814 - #8220 - #8493 - #9540 - #10487 - #12265 - #8308 - #8214 - #7194 - #11732
2023-12-23compilers/elbrus: wrap get_default_include_dirs with lru_cacheDenis Drakhnia1-0/+2
2023-12-20compilers: Add partial docstrings for a couple of Compiler methodsDylan Baker1-0/+19
2023-12-13Use SPDX-License-Identifier consistentlyDylan Baker30-340/+39
This replaces all of the Apache blurbs at the start of each file with an `# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing uses to be consistent in capitalization, and to be placed above any copyright notices. This removes nearly 3000 lines of boilerplate from the project (only python files), which no developer cares to look at. SPDX is in common use, particularly in the Linux kernel, and is the recommended format for Meson's own `project(license: )` field
2023-12-11detect windows linkers for flang in detect_fortran_compilerH. Vetinari1-2/+14
2023-12-05compilers: drop dead codeEli Schwartz7-24/+0
no_warn_args is unused. Its only purpose was to implement automatic hiding of UB in transpiled code, and it was not used at all in languages other than C/C++ -- specifically when the C/C++ source files were created by transpiling from vala or cython.
2023-12-01More robust linker detection for armar (TI vs non-TI)Will Toohey1-3/+1
2023-11-26fix broken type annotation imports being ignoredEli Schwartz1-1/+1
If an annotation could not be resolved, it's classified as a "missing import" and our configuration ignored it: ``` Skipping analyzing "mesonbuild.backends": module is installed, but missing library stubs or py.typed marker ``` As far as mypy is concerned, this library may or may not exist, but it doesn't have any typing information at all (may need to be installed first). We ignored this because of our docs/ and tools/ thirdparty dependencies, but we really should not. It is trivial to install them, and then enforce that this "just works". By enforcing it, we also make sure typos get caught.
2023-11-22clike: Deduplicate rpath linker flagsFini Jastrow1-2/+2
[why] On Apple clang 15.0.0 linker (i.e. ld64 1015.7) giving the same rpath multiple times raises a warning: ld: warning: duplicate -rpath '/local/lib' ignored This can frequently happen when linking several dependencies that all have that rpath in e.g. pkgconfig. [how] Deduplicate all rpath arguments. [note] I'm not sure how the code handles --start/end-group, but for rpath that should not make any difference as that is not bound to a group. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
generated by cgit v1.1 at 2025-09-20 22:38:08 +0000