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.
* Add a new compiler object method: has_members
Identical to 'cc.has_member', except that this takes multiple members
and all of them must exist else it returns false.
This is useful when you want to verify that a structure has all of
a given set of fields. Individually checking each member is horrifying.
* Fix typo in exceptions for has_member(s)
D allows programmers to define their tests alongside the actual code in
a unittest scope[1].
When compiled with a special flag, the compiler will build a binary
containing the tests instead of the actual application.
This is a strightforward and easy way to run tests and works well with
Mesons test() command.
Since using just one flag name to enable unittest mode would be too
boring, compiler developers invented multiple ones.
Adding this helper method makes it easy for people writing Meson build
descriptions for D projects to enable unittestmode.
[1]: https://dlang.org/spec/unittest.html
This commit contains several changes to the naming and versioning of
shared and static libraries. The details are documented at:
https://github.com/mesonbuild/meson/pull/417
Here's a brief summary:
* The results of binary and compiler detection via environment functions
are now cached so that they can be called repeatedly without
performance penalty. This is necessary because every
build.SharedLibrary object has to know whether the compiler is MSVC or
not (output filenames depend on that), and so the compiler detection
has to be called for each object instantiation.
* Linux shared libraries don't always have a library version. Sometimes
only soversions are specified (and vice-versa), so support both.
* Don't use versioned filenames when generating DLLs, DLLs are never
versioned using the suffix in the way that .so libraries are. Hence,
they don't use "aliases". Only Linux shared libraries use those.
* OS X dylibs do not use filename aliases at all. They only use the
soversion in the dylib name (libfoo.X.dylib), and that's it. If
there's no soversion specified, the dylib is called libfoo.dylib.
Further versioning in dylibs is supposed to be done with the
-current_version argument to clang, but this is TBD.
https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW23
* Install DLLs into bindir and import libraries into libdir
* Static libraries are now always called libfoo.a, even with MSVC
* .lib import libraries are always generated when building with MSVC
* .dll.a import libraries are always generated when building with
MinGW/GCC or MinGW/clang
* TODO: Use dlltool if available to generate .dll.a when .lib is
generated and vice-versa.
* Library and executable suffix/prefixes are now always correctly
overriden by the values of the 'name_prefix' and 'name_suffix' keyword
arguments.
This causes intermittent build failures in the MSVC CI because of a race
with the default anti-virus that ships with Windows while writing the
.pdb file: https://ci.appveyor.com/project/jpakkane/meson/build/1.0.58
There's a separate fix for that in the works that will fix this in the
general case, but for compiler tests we don't need to generate the pdb
file at all. So, just fetch the CRT flag (/MDd) if needed instead.
This has the side-effect of making compiler tests that use self.links
and self.run faster.
Nirbheek Chauhan
Jussi Pakkanen
Elliott Sales de Andrade
Matthew Waters
Nirbheek Chauhan
Matthias Klumpp
Zhe Wang