When an older version of the library being built is installed in the
same prefix as external dependencies, we have to be careful to construct
the linker or compiler command line. If a -L flag from external
dependencoes comes before a -L flag pointing to builddir, it is possible
for the linker to load older libraries from the installation prefix
instead of the newly built ones, which is likely to cause undefined
reference error.
Since the order of dependencies is not significant, we cannot expect
internal dependencies to appear before external dependencies when
recursively iterating the list of dependencies. To make it harder to
make mistakes, linker flags come from internal and external
dependencies are now stored in different order sets. Code using
_get_dependencies_flags are expected to follow the order when
constructing linker command line:
1. Internal linker flags
2. LDFLAGS set by users
3. External linker flags
It is similar to what automake and libtool do for autotools projects.
If the external program is a string that is meant to be searched in
PATH, we can't add a dependency on it at configure time because we don't
know where it will be at compile time.
A number of cases have to be taken care of while doing this, so
refactor it into a helper on ExternalProgram and use it everywhere.
1. Command is a list of len > 1, use it as-is
2. Command is a list of len == 1 (or a string), use as a string
3. If command is an absolute path, use it as-is
4. If command is not an absolute path, search for it
This is accepted by all other binaries in the cross file. With this
change, we also don't check whether the specified command exists at
configure time, but that's probably a feature anyway.
Fixes https://github.com/mesonbuild/meson/issues/3737
* Add a test case for bad de-dup of -framework args
https://github.com/mesonbuild/meson/issues/3800
* pkgconfig: Don't naively de-dup all arguments
Honestly don't know what I was smoking. Of course the `Libs:` field in
a pkg-config file can have arguments other than -l and -L
Closes https://github.com/mesonbuild/meson/issues/3800
* pkgconfig module: Fix needlessly aggressive de-dup
When find_library is used to find dependencies, meson checks all paths for
libraries with all prefixes that could match. This means that when we are
compiling with -m32 on a 64-bit system, meson will find 64-bit libraries and
assumes that they will work. Naturally that is not the case.
The obvious fix is to do a test link against those libraries, but the extra
wrinkle here is that we need to do a "whole link" so as to test the static
libs. A check with gcc+ld on linux shows that unless there are unresolved
symbols from the main.c file, the static library is never checked so we avoid
the error from an incompatible library.
Currently the former will be parsed as [''], while the latter is parsed
as [] in python. This makes for some obnoxious special handling
depending on what the user passes. This is even more obnoxious since for
string type arguments this doesn't require special handling.
The name splitting was wrong and would not incorrectly handle folders
with two dots, like Foo.framework.dSYM and treat this as 'Foo' instead
of 'Foo.framework', which would lead to meson detecting dSYM bundles
as frameworks and try to use those like a framework, which is wrong.
Fix#3793
We mention this is equivalent to setting both build_by_default and
build_always_stale in the release note, and in the warning emitted when it's
used, but not in the reference manual.
ninja chokes when building FFmpeg's static libraries, as the
command line can be larger than 32000.
This was disabled on purpose in #1649, but the rsp syntax was
different: this commit makes it so the options and output file
are still passed on the command line, gcc-ar didn't work
otherwise.
* environment: validate cpu_family in cross file
* run_unittests: add unittest to ensure CPU family list in docs and environment matches
* run_unittests: skip compiler options test if not in a git repository
* environment: validate the detected cpu_family
* docs: add 32-bit PowerPC and 32/64-bit MIPS to CPU Families table
Names gathered by booting Linux in Qemu and running:
$ python3
import platform; platform.machine()
Partial fix for #3751
D is not a 'c-like' language, but it can link to C libraries. The same
might be true of Rust in the future and Go when we add support for it.
This contains no functionality changes.
All dependencies were using find_library, has_header, get_define, etc on
self.compiler assuming that it's a compiler that outputs and consumes
C-like libraries. This is not true for D (and in the future, for Rust)
since although they can consume C libraries, they do not use the
C ecosystem.
For such purposes, we now have self.clib_compiler. Nothing uses
self.compiler anymore as a result, and it has been removed.
It used to be non-fatal warnings but recent command line refactor made
it fatal. It looks like GNOME continuous would break with this change.
To avoid delaying upcoming 0.47.0 release adoption, let's downgrade this
back to warning for now and reconsider after the release.
In GLib when running "ninja gio-doc" without doing a full build first,
it won't build libraries and the generated gio-scan.c gets linked
against system libgio instead.
This fix 2 bugs: gtkdoc() was not passing 'depends' variable down to
_get_dependencies_flags(), and many places had 'if depends' which is
False when 'depends' is an empty list and not only when it's None. There
is no reason for that argument to be optional, we always want to collect
dependencies.
Ting-Wei Lan