We currently pass cross-compiler options to the native compiler too and
when cross-compiling from Windows to Linux, `options` will contain
Linux-specific options which doesn't include `c_winlibs`.
The proper fix is to allow cross-info files to specify compiler options
and to maintain both cross and native compiler options in coredata, but
that will have to be done after the 0.36.0 release.
Also fixes a typo in MinGW cpp_winlibs option setting.
Closes#1029
Move CCompiler.compile to Compiler.compile so that ValaCompiler can use
it. Also rewrite ValaCompiler.sanity_check to use it since it does
a simple compile check.
At the same time, it enhances ExternalLibrary to support arguments for
languages other than C-like.
Includes a test for this that links against zlib through Vala.
Closes#983
With MSVC 2013 and newer, using pre-compiled headers with .pdb debugging
fails with the following error message:
fatal error C1041: cannot open program database '[...]\prog.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
So we use /FS when PCH is enabled. When PCH is enabled and debugging is
disabled, this will have no effect since .pdb files will not be written.
Without this, we error out with an exception if `javac` is found but
`java` isn't:
[...]
File "mesonbuild/interpreter.py", line 1759, in detect_compilers
comp.sanity_check(self.environment.get_scratch_dir(), self.environment)
File "mesonbuild/compilers.py", line 1279, in sanity_check
pe = subprocess.Popen(cmdlist, cwd=work_dir)
File "/usr/lib64/python3.5/subprocess.py", line 947, in __init__
restore_signals, start_new_session)
File "/usr/lib64/python3.5/subprocess.py", line 1551, in _execute_child
raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'java'
Clang++ doesn't allow that, but void* will always be allowed because
lots of projects depend on that.
error: cast from pointer to smaller type 'int' loses information
Need to pass -fpermissive to force C++ compilers to only warn about our
non-conformant code that tests for a symbol being defined.
Also do a simple #ifdef check first in has_header_symbol to allow
arbitrary macros to be detected which would not have been detected
earlier. This follows what AC_CHECK_DECL does.
Closes#958
Every other build system does this, and at least OS X, iOS, and Android
depend on this to select the OS versions that your application is
targetting.
At the same time, just use a wrapper for self.run and self.links to
share the common (identical) code.
Simply placing a reference to it isn't enough for the linker to try and
think it's being used and do a symbol availability check with
-Wl,-no_weak_imports on OS X ld.
This is needed to ensure that symbol availability checks actually fail
at link time (instead of at runtime) which is necessary for has_function
to work correctly.
The Autoconf-style check we were doing gives false positives when the
linker uses the prototype defined in the SDK header to decide whether
a function is available or not.
For example, with macOS 10.12, clock_gettime is now implemented
(alongwith other functions). These functions are always defined in the
XCode 8 SDK as weak imports and you're supposed to do a runtime check to
see if the symbols are available and use fallback code if they aren't.
The linker will always successfully link if you use one of those symbols
(without a runtime fallback) even if you target an older OS X version
with -mmacosx-version-min. This is the intended behaviour by Apple.
But this makes has_function useless because to test if the symbol is
available, we must know at link-time whether it is available.
To force the linker to do the check at link-time you must use
'-Wl,-no_weak_imports` *and* use the prototype in time.h which has an
availability macro which tells the linker whether the symbol is
available or not based on the -mmacosx-version-min flag.
An autoconf-style check would override this prototype and use its own
which would result in the linker thinking that the function is always
available (a false positive). Worse, this would manifest at runtime and
might not be picked up immediately.
We now use the function prototype in the user-provided includes if the
'prefix' kwarg contains a `#include` and use the old Autoconf-style
check if not. I've tested that the configure checks done by GStreamer
and GLib are completely unaffected by this; at least on Linux.
The next commit will also add `-Wl,-no_weak_imports` to extra_args by
default so that Meson avoids this mess completely. We always want this
because the user would not do a has_function check if they have
a runtime fallback for the function in their code.
This is done by adding a new compiler method called 'no_warn_args' which
returns the argument(s) required for the compiler to emit no warnings
for that compilation.
This take care of not disabling warnings for C code compiled into the
BuildTarget. Also includes tests for ensuring all this.
https://github.com/mesonbuild/meson/issues/864
It is extremely common to need to know within a given dependency if
a given header, symbol, member, function, etc exists that cannot be
determined from the version number alone.
Without passing dependency objects to the various compiler/linker
checks and with many libraries headers/libraries being located in
their own subdirs of the standard prefix, the check for the library
would not find the header/function/symbol/etc.
This commit allows passing dependency objects to the compiler checks so
that the test program can be compiled/linked/run with the necessary
compilation and/or linking flags for that library.
Instead of spreading it across the entire file and re-implementing
can_compile for each compiler, consolidate it in one dictionary which
the base compiler class can refer to based on self.language set by the
child class.
This has fixed a number of hidden and unreported bugs due to bitrotten
can_compiler implementations.
/FS forces .pdb file writing to be serialized through MSPDBSRV.EXE,
which is supposed to solve concurrency issues (esp. with anti-viruses),
but it doesn't actually always work. It also isn't needed anymore since
we don't use a shared vcXXX.pdb temporary file for pdb writing and use
/Fd to explicitly set a per-target pdb filename instead.
Not serializing the PDB writing will make a large difference on fast
disks when linking multiple libraries and executables simultaneously.
Nirbheek Chauhan