We already do conditional build with "#if WITH_CONCHECK".
Get rid of the conditional in the makefile and instead do
conditional compilating inside the source file "nm-connectivity.c".
The advantage is, now if you want to know which parts are build,
you only need to grep for the WITH_CONCHECK preprocessor define
instead of also caring about the conditional in Makefile.am and
meson.build.
It doesn't change the fact of conditional compilation. But it
consistently uses one mechanism to achieve it.
From libnl3, we only used the helper function to parse/generate netlink
messages and the socket functions to send/receive messages. We don't
need an external dependency to do that, it is simple enough.
Drop the libnl3 dependency, and replace all missing code by directly
copying it from libnl3 sources. At this point, I mostly tried to
import the required bits to make it working with few modifications.
Note that this increases the binary size of NetworkManager by 4736 bytes
for contrib/rpm build on x86_64. In the future, we can simplify the code
further.
A few modifications from libnl3 are:
- netlink errors NLE_* are now in the domain or regular errno.
The distinction of having to bother with two kinds of error
number domains was annoying.
- parts of the callback handling is copied partially and unused parts
are dropped. Especially, the verbose/debug handlers are not used.
In following commits, the callback handling will be significantly
simplified.
- the complex handling of seleting ports was simplified. We now always
let kernel choose the right port automatically.
clang 5.0.1 complains:
src/systemd/src/libsystemd-network/dhcp6-option.c:40:28: error:
field 'option' with variable sized type 'struct DHCP6Option' not at
the end of a struct or class is a GNU extension
[-Werror,-Wgnu-variable-sized-type-not-at-end]
struct DHCP6Option option;
^
systemd disables this warning too.
Make it possible to add compiler options to a different variable than
CFLAGS. This is useful to conditionally disable a compiler warning for a
subpart of a tree.
The address sanitizer is not compatible [1] with libraries dynamically
opened using RTLD_DEEPBIND: disable the flag when building with asan.
[1] https://github.com/google/sanitizers/issues/611
Shared libraries built with sanitizers are a bit inconvenient to use
because they require that any application linking to them is run with
libasan preloaded using LD_PRELOAD. This limitation makes the
sanitizer support less useful because applications will refuse to
start unless there is a special environment variable set.
Let's turn the --enable-address-sanitizer configure flag into
--with-address-sanitizer=yes|no|exec so that is possible to enable
asan only for executables.
autotools' AC_LANG_PROGRAM() generates a main() function which triggers
a compiler warning (for which we fail with -WError).
conftest.c:92:1: error: function declaration isn't a prototype [-Werror=strict-prototypes]
main ()
^~~~
cc1: all warnings being treated as errors
Fixes: 557d83bf2d
XXX was used to either raise attention (NOTE) or to indicate
that this is ugly code that should be fixed (FIXME). The usage
was inconsistent.
Let's avoid XXX and use either NOTE or FIXME.
The check doesn't seem useful, because it does not result in a fallback
or a different build.
Just assume <linux/wireless.h> is valid. In case it is not, we will get a
build failure later. That is just as good.
The check doesn't seem useful, because it does not result in a fallback
or a different build.
Just assume <linux/nl80211.h> is valid. In case it is not, we will get a
build failure later. That is just as good.
netlink's API is stable, and strictly defined by the integer values that make
up commands and attributes. There is little reason do disable a netlink feature
based on compile time detection of the kernel headers.
Either kernel supports it, or it will fail with an appropriate response.
Also, support for NL80211_CMD_CRIT_PROTOCOL_START was merge to kernel
in 2013. Maybe, we should now just always assume support (in the kernel
headers is there). Anyway, don't do that yet, but instead avoid the
defines and use the numeric values directly.
Many of the configured directories default to being defined using existing
directory configuration. As a result you usually don't see the actual
directories that will be used. With the added directories you can at least
assemble the information and thus see which directories will be used.
We don't have a complete list of distributions that use ifcfg for network
configuration but we can easily check for `/etc/sysconfig/network-scripts`
and then distributions can explicitly disable the plugin of that is what
they want.
[thaller@redhat.com: cherry-picked and adjusted for rebase from
https://github.com/NetworkManager/NetworkManager/pull/49]
In future we should probably either switch to `/etc/os-release` or just
check for `/etc/sysconfig` or something like that.
[thaller@redhat.com: cherry-picked and adjusted for rebase from
https://github.com/NetworkManager/NetworkManager/pull/49]
Even Gentoo disables this plugin since before 0.9.8 release
of NetworkManager. Time to say goodbye.
If somebody happens to show up to maintain it, we may resurrect it
later.
If "$distro_plugins=ifnet" was set, configure.ac would use that
to autodetect --with-hostname-persist=gentoo. Replace that autodetect
part by checking for /etc/gentoo-release file.
The option is deprecated together with the ifcfg-suse settings plugin.
Selecting the plugin has no effect at runtime, beside logging a warning.
Drop the configure option.
Note, that if $distro_plugins was set to "ifcfg-suse", it was also used to
autodetect --with-hostname-persist=suse. Now, autodetect the hostname
persist mode based on presence of /etc/SuSE-release file.
This is very similar to NMDeviceWifi but simplified to remove the things
currently unsupported and with calls to nm_platform_wifi_* and
nm_supplicant_* replaced with IWD DBus API calls. Only unsecured
infrastructure-mode networks are supported here.
[bgalvani@redhat.com: fix compilation error after rebase for
NMActRequestGetSecretsCallId]
[thaller@redhat.com: don't use _() macro strings server side.
Translating strings only makes sense for clients that set environment
variables accordingly.]
Also, don't add the CFLAGS for libjansson to dflt_cppflags_libnm_core.
dflt_cppflags_libnm_core is used also by core and libnm. But those
components do not (directly) link against libjansson. The cannot use
these flags.
I don't think we should do this.
- renamining/dropping configure options is still an annoyance,
because it requires to different ./configure options depending
on the version. The rename from --enable-teamctl to --enable-team
might be theoretically nice, but more annoying then helpful.
- There is no strict dependency between --enable-team and
--enable-json-validation. At most, one could argue that
when enabling the team plugin (--enable-teamctl), then
libnm must also be build with --enable-json-validation.
But in fact, the team plugin will happily work with a
libnm that doesn't link against libjansson.
That is --enable-teamctl --disable-json-validation will work
in practice just fine.
On the other hand, libnm is a client library to create connection
profiles, fully supporting team profiles also makes sense if the
actual plugin is not installed (or build). Thus, --disable-teamctl
--enable-json-validation certainly makes sense.
At this point, one might ask whether libnm is even still complete without
libjansson. Maybe libnm should *require* --enable-json-validation.
But that is not what the patch was doing, and it would also need
some careful consideration before doing so.
This reverts commit 9d5cd7eae8.
Rename the team functionality enablement from 'teamdctl' to 'team'.
Force jansson lib requirement for team functionality: NetworkManager
requires the teamd daemon to manage team. As teamd depends upon jansson
lib, adding jansson requirement for teaming support in NetworkManager
seems reasonable.
Remove the jansson_validation flag, as the only generic json function in
nmcli (not related to team) was the one to check if a string was in json
format. Anyway, that function is used for team checks only. So, move
also json validation functions under the WITH_TEAM flag.
Currently there are multiple features that require Jansson support,
but WITH_JANSSON=1 is set only when configuring with
--enable-json-validation. Therefore a build with
"--disable-json-validation --enable-ovs" fails.
The availability of Jansson (WITH_JANSSON) should only be used:
- to check if dependent features can be enabled
- to determine compiler and linker flags in the Makefile
- in nm-jansson.h to define compatibility functions if needed
Everything else must be controlled by a configure switch.
https://bugzilla.gnome.org/show_bug.cgi?id=790233
After 1.10.0 is released, merge it back into master so that
1.10.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.10.0 and 1.10-rc*.
Also bump the micro version to 1.11.1-dev to indicate that this is
after 1.10.0 is out.
There is still a fallback detection in "shared/nm-utils/nm-macros-internal.h",
so that VPN-plugins and applet don't need to bother about adding these
configure checks.
Register empty "NMClient" and "NetworkManager" GIR modules as soon as libnm is
loaded witch gnome-introspection. This prevents the real modules from being
loaded because they would in turn load libnm-glib and abort() and crash.
In particular this prevents the GNOME shell from crashing with
libnm-glib abort and allows gracefully disabling the extensions which
use the obsolete library.
Test:
$ cat test.js
const NM = imports.gi.NM;
print (NM.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
const NMClient = imports.gi.NMClient;
print (NMClient.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
Before:
$ gjs test.js
1
(gjs:16253): libnm-util-ERROR **: libnm symbols detected; Mixing libnm with libnm-util/libnm-glib is not supported
Trace/breakpoint trap (core dumped)
$
After:
$ gjs test.js
1
Gjs-Message: JS WARNING: [test.js 5]: reference to undefined property "SecretAgentGetSecretsFlags"
(gjs:16228): Gjs-WARNING **: JS ERROR: TypeError: NMClient.SecretAgentGetSecretsFlags is undefined
@test.js:5:1
JS_EvaluateScript() failed
When building with -flto, we need to use linker plugins.
In case of binutils' nm, it means to prefer gcc-nm if
available.
Like for ranlib and ar, prefer gcc-nm.
- replace AC_PATH_TOOL() by AC_CHECK_TOOLS(). That is consistent
with what we do for ar,ranlib and suggested on bgo#783311.
- instead of using the variable $BINUTILS_NM, replace it by
$NM, which is more common according to bgo#783311.
- Keep recognizing $BINUTILS_NM environment, which was introduced
by commit 8bc88bcc7c. This is purely to keep previous build
scripts working. Originally I named it "$BINUTILS_NM" because
using $NM in NetworkManager seemed confusing. But well...
https://bugs.gentoo.org/show_bug.cgi?id=620052https://bugzilla.gnome.org/show_bug.cgi?id=782525https://bugzilla.gnome.org/show_bug.cgi?id=783311
After 1.8.0 is released, merge it back into master so that
1.8.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.8.0 and 1.8-rc*.
Also bump the micro version to 1.9.1-dev to indicate that this is
after 1.8.0 is out.
connectivity check functionality should be explicitly set as disabled if
not wanted: this prevents building NM without connectivity check support
without any evident warning on systems where libcurl is not installed.
(cherry picked from commit 4e6967e33d)
Recently we removed libsoup dependency in favor of libcurl.
Connectivity checking functionality was enabled by defaut when libsoup
was detected: do the same now when detecting libcurl.
(cherry picked from commit ad35fbf3a3)
connectivity check functionality should be explicitly set as disabled if
not wanted: this prevents building NM without connectivity check support
without any evident warning on systems where libcurl is not installed.
