Recent versions of systemd (starting with v238) started to check for the
existence of the statx structure using the cc.sizeof() operation. The cc
compiler implementation fails to detect this structure because it's size
limit is 128, meaning it will fail for any type larger than 128 bytes in
the following way during cross-compilation checks:
meson.build:10:2: ERROR: Cross-compile check overflowed
Increase the size limit for data types to 1024 bytes, which should give
plenty of room for even large data structures. This is obviously not
guaranteed to be an upper bound, but given the binary search algorithm
implemented in the cross-compile check, raising the limit too high may
significantly increase the time required for this check on smaller data
types.
Signed-off-by: Thierry Reding <treding@nvidia.com>
- Fixing flake8 error in compilers.py - [E124] closing bracket does not match visual indentation
- Updating ARMCCompiler constructor in c.py to raise error as per comments
$ flake8 | grep -E '(E123|E127|E128)'
./run_unittests.py:1358:37: E127 continuation line over-indented for visual indent
./run_unittests.py:1360:37: E127 continuation line over-indented for visual indent
./mesonbuild/minit.py:311:66: E128 continuation line under-indented for visual indent
./mesonbuild/minit.py:312:66: E128 continuation line under-indented for visual indent
./mesonbuild/minit.py:313:66: E128 continuation line under-indented for visual indent
./mesonbuild/compilers/cpp.py:115:63: E127 continuation line over-indented for visual indent
./msi/createmsi.py:156:13: E123 closing bracket does not match indentation of opening bracket's line
./msi/createmsi.py:188:13: E123 closing bracket does not match indentation of opening bracket's line
Change the code to store D properties as plain data. Only convert them
to compiler flags in the backend. This also means we can fully parse D
arguments without needing to know the compiler being used.
Older versions of GDC had broken support for the -MQ flag (resulting in
a compiler error). New versions of GDC have this issue fixed (some older
versions received a backport). Starting with GCC 7.1 we can assume
dependency generation to always work reliably.
A hard error makes this feature useless in most cases since a static
library usually won't be found for every library, particularly system
libraries like -lm. Instead, warn so the user can provide the static
library if they wish.
This feature will be expanded and made more extensible and more usable
in the future.
Closes https://github.com/mesonbuild/meson/issues/2785
After PR #2662, running test case common/125 shared module/ on Cygwin gets
me:
$ ninja -C _build
ninja: Entering directory `_build'
[7/7] Linking target prog.exe.
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: warning: --export-dynamic is not supported for PE+ targets, did you mean --export-all-symbols?
Also, fix doc for correct version of first apperance.
Future work: Notwithstanding the hint that ld gives, these options are not
equivalent, and it's not clear we should be using it here:
--export-all-symbols is the default behaviour, and if the exports are
restricted by explicit annotations or a .def file, this option might be
overriding that...
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
has_argument and other similar methods of compiler objects only support
checking compiler flags. If they are used to check linker flags, the
results are very likely to be wrong and developers should be warned.
Otherwise we will try to use the objc compiler when linking projects
with both objc and C++.
Technically we should use the objc++ linker when doing this, but on
most (all?) systems the objc++ linker is `c++`, which is the same
as the C++ linker.
Closes https://github.com/mesonbuild/meson/issues/2468
See issue #2762
Adds full_version to class Compiler. If set full_version will be printed
additionally.
Added support for CCompiler and CPPCompiler
Added support for gcc/g++, clang/clang++, icc.
We can't know if the .lib is a static or import library, but that's
a problem in general too. The only way to figure out if a specific
file is an import or a static library is to dump its symbols and check
if it starts with __imp or not.
Even then, some libs are hybrid import and static, i.e., they contain
references to DLLs for some symbols and also provide implementations
for other symbols so this is a difficult problem.
Closes https://github.com/mesonbuild/meson/issues/2659
As the Vala compiler does not define thread_flags() and
thread_link_flags(), depending on threads in any capacity will cause Meson to
fail.
Fixes#2720.
Thierry Reding
Aleksey Filippov
Alexis Jeandet
makise-homura
David Seifert
Bedarkar, Malhar
Somasekhar Penugonda
Jon Turney
Jussi Pakkanen
Thibault Saunier
Matthias Klumpp
Nirbheek Chauhan
Leon Krause
Adam C. Foltzer
Ting-Wei Lan
Nikita Churaev
Dylan Baker
Alexey Stukalov
Benjamin Redelings
Christoph Behle
Hemmo Nieminen
Ismael González
Ernestas Kulik
Solomon Choina
Josh Soref