meson: spurious dependencies on convenience libraries in .pc files
I tried building GLib 2.58.1 Debian packages (with a backport of @xclaesse's fixes for #1527 (closed)) with both Autotools and Meson (version 0.47.2-1), and running diffoscope on the results (if you do this, you'll want to use --exclude-command objdump --exclude-command readelf
to avoid spending a long time analyzing some uninteresting differences).
The generated .pc
files contain some extra Libs.private
which I think correspond to Autotools "convenience libraries" (sorry, I don't know whether there is different jargon for these in Meson) — bits of code internal to GLib that are collected into .a
files and linked into the GLib libraries themselves.
This affects GIO (the problems here are -lxdgmime
, -linotify
:
│ │ │ │ +Libs.private: -pthread -L${libdir} -lxdgmime -linotify -ldl -pthread -lresolv
and GLib (the problematic one is -lcharset
):
│ │ │ │ +Libs.private: -L${libdir} -lcharset -pthread
If you link GLib statically into an executable, this will result in running something like
gcc -static -ohello hello.o -lglib-2.0 -lcharset -pthread
which will presumably fail because there is no libcharset.so
or libcharset.a
in the compiler's search path.
What I would expect here is that libxdgmime.a
and libinotify.a
get included in their entirety into libgio-2.0.a
(so that libgio-2.0.a
is a superset of each of those libraries), libcharset.a
similarly gets included into libglib-2.0.a
, and the .pc
files do not mention them. That's what happens in Autotools-land.