When there is more than one path in PKG_CONFIG_PATH. It is almost always
preferred to find things in the order specified by PKG_CONFIG_PATH
instead of assuming pkg-config returns flags in a meaningful order.
For example:
/usr/local/lib/libgtk-3.so.0
/usr/local/lib/pkgconfig/gtk+-3.0.pc
/usr/local/lib/libcanberra-gtk3.so
/usr/local/lib/pkgconfig/libcanberra-gtk3.pc
/home/mesonuser/.local/lib/libgtk-3.so.0
/home/mesonuser/.local/lib/pkgconfig/gtk+-3.0.pc
PKG_CONFIG_PATH="/home/mesonuser/.local/lib/pkgconfig:/usr/local/lib/pkgconfig"
libcanberra-gtk3 is a library which depends on gtk+-3.0. The dependency
is mentioned in the .pc file with 'Requires', so flags from gtk+-3.0 are
used in both dynamic and static linking.
Assume the user wants to compile an application which needs both
libcanberra-gtk3 and gtk+-3.0. The application depends on features added
in the latest version of gtk+-3.0, which can be found in the home
directory of the user but not in /usr/local. When meson asks pkg-config
for linker flags of libcanberra-gtk3, pkg-config picks
/usr/local/lib/pkgconfig/libcanberra-gtk3.pc and
/home/mesonuser/.local/lib/pkgconfig/gtk+-3.0.pc. Since these two
libraries come from different prefixes, there will be two -L arguments
in the output of pkg-config. If -L/usr/local/lib is put before
-L/home/mesonuser/.local/lib, meson will find both libraries in
/usr/local/lib instead of picking libgtk-3.so.0 from the home directory.
This can result in linking failure such as undefined references error
when meson decides to put linker arguments of libcanberra-gtk3 before
linker arguments of gtk+-3.0. When both /usr/local/lib/libgtk-3.so.0 and
/home/mesonuser/.local/lib/libgtk-3.so.0 are present on the command
line, the linker chooses the first one and ignores the second one. If
the application needs new symbols that are only available in the second
one, the linker will throw an error because of missing symbols.
To resolve the issue, we should reorder -L flags according to
PKG_CONFIG_PATH ourselves before using it to find the full path of
library files. This makes sure that we always follow the preferences of
users, without depending on the unreliable part of pkg-config output.
Fixes https://github.com/mesonbuild/meson/issues/4271.
There are two awful things about CompilerArgs, one is that it directly
inherits from list, and there are a lot of subtle gotcahs with
inheriting from builtin types. The second is that the class allows
arguments to be passed in whatever order. That's bad. This also fully
annotates the CompilerArgs class, so mypy can type check it for us.
This dumps xild on mac and linux. After a lot of reading and banging my
head I've discovered we (meson) don't care about xild, xild is only
useful if your invoke ld directly (not through icc/icpc) and you want to
do ipo/lto/wpo. Instead just make icc report what it's actually doing,
invoking ld or ld64 (for linux and mac respectively) directly. This
allows us to get -fuse-ld working on linux.
Previously if a user tried to pass a command line build
option that contained a '%' character the command line
parser assumed that there was string interpolation to be
done. As there is no sense in such a scenario no code
provides any input for the interpolation. This then leads to
a failure.
In this commit we specifically override the defaults in
ConfigParser and set interpolation to None, which disables
command line build option interpolation.
Fixes#6157
A build with a cross file should always be identified as a cross build, even if
the host and build machine are identical. This was the case in 0.50, regressed
in 0.51, and is fixed again in 0.52, so add a test case to ensure it doesn't
regress again.
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
test3-static was actually always using the shared library because that
warning was not fatal:
WARNING: Static library 'func6' not found for dependency 'func6', may
not be statically linked
The reason why the libfunc6.a wasn't found is because the prefix in the
generated pc file was not set to install dir.
In qemu, minikconf generates a depfile that meson could use to
automatically reconfigure on dependency change.
Note: someone clever can perhaps find a way to express this with a
ninja rule & depfile=. I didn't manage, so I wrote a simple depfile
parser.
According to http://testanything.org/tap-specification.html
"Any output line that is not a version, a plan, a test line, a
diagnostic or a bail out is considered an “unknown” line. A TAP parser
is required to not consider an unknown line as an error but may
optionally choose to capture said line and hand it to the test
harness, which may have custom behavior attached [...] TAP::Harness
reports TAP syntax errors at the end of a test run".
(glib gtest can generate empty lines)
The main library must come before extra libraries, because they are
likely to be dependencies of the main library that get promoted from
private to public. This was causing static link issues with glib-2.0.pc.
On illumos (and presumably Solaris, though I can't test) cc normally
points to Sun CC, which we don't support. So ensure that gcc is used
explicitly in that case.
Stéphane Cerveau
Nirbheek Chauhan
Xavier Claessens
Eli Schwartz
Jussi Pakkanen
Ting-Wei Lan
Dylan Baker
Paolo Bonzini
Daniel Mensinger
Michael Hirsch, Ph.D
Paulo Neves
Marvin Scholz
Wolfgang Stöggl
Aleksey Gurtovoy
Orlando Wingbrant
Ross Burton
Jakub Adam
Jan Beich
Marc-André Lureau