Causes spammy warnings from the linker:
ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)
has_function() tries to link an example program using the function
to see if it is available, but with clang on 64bit Windows this
example always already failed at the compile step:
error: cast from pointer to smaller type 'long' loses information
long b = (long) a;
This is due to long!=pointer with LLP64
Change from "long" to "long long" which is min 64bit and should always
fit a pointer. While "long long" is strictly a C99 feature every
non super ancient compiler should still support it.
The builtin check had a special case that if a header was provided and
the function wasn't defined, it would ignore the builtin to avoid
non-functional builtins (for example __builtin_posix_memalign in MSYS2).
GCC 10 gained support for __has_builtin() which now skipps this check
and because __has_builtin(__builtin_posix_memalign) returns true the
non functional builtin is now reported as available.
To get the old behaviour back move the special case in front of the actual
availability check.
Fixes#7113
If no exe_wrapper is set in the meson cross file the exe_wrapper
object will be an instance of EmptyExternalProgram.
So, found is True and prorgram is an empty list.
This will cause meson to tun the compiler sanity check because
it checks only for self.is_cross and self.exe_wrapper being
not None.
I ran into that situation while cross compiling for ia32 on a
x64_64 host. The host had no ia32 userspace installed, so the
self test failed.
As workaround I currently set exe_wrapper to 'true'.
Signed-off-by: Richard Weinberger <richard@nod.at>
Clang supports the GCC -Og flag, but --optimization=g is not setting that. This is because Clang is referencing the clike_optimization_args, which does not define a flag for 'g'.
To address this, we'll mimic the GNU options instead of the C-like ones.
Fixes#6619
This should have worked before, but the inheritance order was backwards,
so we got the DCompiler before the GnuCompiler, and the base Compiler
methods overrode the Gnu methods.
Some compilers that act as linker drivers (dmd and ldc) need to split
arguments that GCC combines with , (ie, -Wl,-foo,bar -> -L=-foo -L=bar).
As such we need to detect that the previous argument contained -soname,
and not wrap that in a --start-group/--end-group
This modifies the shared library test to demonstrate the problem, with a
test case.
Fixes#6359
This is the argument to name the implib when using the Visual Studio
Linker. This is needed by LDC and DMD when using link.exe or
lld-link.exe on windows, and is really a linker argument not a compiler
argument.
DMD and LDC are a real pain to use as linkers. On Unices they invoke the C
compiler as the linker, just like meson does. This means we have to figure out
what C compiler they're using and try to pass valid arguments to that compiler
if the D compiler doesn't understand the linker arguments we want to pass. In
this case that means gcc or clang. We can use-the -Xcc to pass arguments
directly to the C compiler without dmd/ldc getting involved, so we'll use that.
This was never really true of the D compilers, it made them more
complicated than necessary and was incorrect in many cases. Removing it
causes no regressions on Linux, at least in our rather limited test
cases).
listify shouldn't be unholdering, it's a function to turn scalar values
into lists, or flatten lists. Having a separate function is clearer,
easier to understand, and can be run recursively if necessary.
the check for which files can be compiled are called again and again on
the same files over and over again. Caching this here shaves off 11s of
the build time of efl (which has grown in the last 3 versions to over 40
sec. again)
in order to deduplicate arguments as much as possible, we need to check
if a argument is already part of the list. Which is quite slow because
we are checking 3 lists for that.
In smaller projects this might be not of interested. However, in efl
things are quite "heavy", alone generating the ninja file took 40 sec..
16 sec. are spent in __iadd__ of CompilerArgs.
What this patch does to speed this all up is:
1. We only check if a element is in post when we know that it must be in
post same for pre.
2. the checks for if we already do contain a specific value are now done
via a dict, and not via the list.
This overall brings the time from 16 sec. spent in __iadd__ to 9 sec. in
__iadd__.
Another possible solution for all this is to have a internal structure
of CompileArgs of trees, so you have the "basic" layer of arguments
where the position does not matter. Additionally, you have two stacks of
lists, the pre stack and the post stack, duplicates can then be checked
when itereting, which would safe another ~4s in terms of efl. However, i
do not have time for this undertaking right now.
Emscripten does have a stand alone linker, wasm-ld. This patch adds the
linker, adds detection for the linker, and removes the IsLinkerMixin for
emscripten. This is a little more correct, and makes the code a lot
cleaner and more robust.
Emscripten has pthread support (as well as C++ threads), but we don't
currently implement them. This fixes that by adding the necessary code.
The one thing I'm not sure about is setting the pool size. The docs
suggest that you really want to do this to ensure that your code works
correctly, but the number should really be configurable, not sure how to
set that.
Fixes#6684
This is more correct, and forces the target(s) to be rebuilt if the
PDB files are missing. Increases the minimum required Ninja to 1.7,
which is available in Ubuntu 16.04 under backports.
We can't do the same for import libraries, because it is impossible
for us to know at configure time whether or not an import library will
be generated for a given DLL.
This gives consistent reporting of this error for all platforms.
Also, reporting this error when constructing the BuildTarget, rather
than discovering the problem during backend generation means that the
error is reported against with a location.
Instead of checking the compiler id inside the VisualStudioLikeCompiler
class, this creates two subclasses that each represent the divergent
behavior of the two compilers
Nirbheek Chauhan
Pino Toscano
Mike Gilbert
Eric Lemanissier
Ole André Vadla Ravnås
Christoph Reiter
Andrei Alexeyev
Jussi Pakkanen
Dylan Baker
John Ericson
John Ericson
Szabi Tolnai
alanNz
Richard Weinberger
Phillip Johnston
Martin Storsjö
Marcel Hollerbach
Jon Turney
makise-homura