It is a bit odd to do this, because usually libnm-glib-aux is not
about network related stuff. But that is not true entirely, because
it also contains NMIPAddr and other related helper funcitons.
NMLinkType is only a plain enum, there is no logic beyond it.
As such, I think it's acceptable to move it here.
There reason to do this, is that I want to move NMUtilsIPv6IfaceId and
nm_utils_get_ipv6_interface_identifier() out of src/core/, and since
that API is also trival helpers without complex state, it fits to
libnm-glib-aux. As such, we will need also NMLinkType there.
NMSettingWirelessWakeOnWLan is public API of libnm/libnm-core
in "src/libnm-core-public/"
We want that libnm-platform is independet of libnm-core to keep
the dependencies smaller and code better separated. Hence we
cannot use that enum there.
Duplicate NMSettingWirelessWakeOnWLan as _NMSettingWirelessWakeOnWLan
in libnm-base.
With systemd-resolved, NetworkManager considers `/etc/resolv.conf`
unmanaged. This breaks hostname lookups in a subtle way: when a new
connection comes online, NM will initiate the hostname lookup *before*
propagating DNS updates to systemd-resolved, which of course will cause
the request to fail. And because NM doesn't update `/etc/resolv.conf`,
it doesn't emit a `CONFIG_CHANGED` signal which would've restarted the
lookup.
Fix this by emitting a signal also when using a caching DNS plugin.
https://bugzilla.redhat.com/show_bug.cgi?id=1933863https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/770
We no longer define G_LOG_DOMAIN differently for the libraries and
applications. Instead, the use now all "nm".
However, that also changes the syslog identifier for NetworkManager
core. That is undesirable. Change it back to "NetworkManager".
Fixes: 341b6e0704 ('all: change G_LOG_DOMAIN to "nm"')
Per convention, we shall no link our static libraries with other static
libraries of our own. The purpose is that we only link static libraries
at the end of each build product (that is, in executables, shared
libraries and shared modules).
Avoid dependencies but explicitly link the static library where it is
used.
This also fixes that we linked libnm-log-core into
libnm-settings-plugin-ifcfg-rh.so, which duplicated the symbols
while it should used them from NetworkManager.
Symbols in header files should almost always have an "nm" prefix.
That is not purely cosmetic, because core modules (like libnm-device-plugin*.so
and libnm-settings-plugin*so) should re-use the symbols of the NetworkManager
binary. For NetworkManager we generate a linker version script to only expose
the symbols that are needed. It thereby excludes symbols that don't have an "nm"
prefix.
Hence, the plugins otherwise cannot reuse the global symbol.
The only reason that we currently don't have a linker error is because
we also link the logging static library into the plugin modules. That is
wrong, because we should not duplicate these symbols.
We have a number of static helper libraries. When a user is using such a
library, they need to set the include search paths (-I) and link with
the static library at the right place.
The first part, the include search path, is now trivial. We no longer
add the individual search paths but everybody uses "-I. -Isrc/".
The second part means that when we build a shared library or an
executable that uses symbols from the static library, we need to link
it. But only then, and not earlier so that not multiple intermediate
build products (static libraries too) contain the same code. Note that
for libnm-device-plugin-*.so and other core plugins it's even that
those shared modules should not themselves link with the static
helpers. Instead, the need to use the symbols from NetworkManager.
Easy enough. Previously, we would sometimes define dependencies in
meson. But as it's really simple, I think that those dependencies
obfuscate more than help. Instead drop them, and only explicitly link
where we need it. The exception is libNetworkManagerTest_dep, which
is still a dependency. Maybe that dependency is fine, as it is much
later in the process. Or maybe that will also be replaced in the future.
