Looks like it's related to a switch from '802-3-ethernet' to just 'ethernet'. But the problem in the tests can be totally unrelated to your actual problem. It would have been better to start two bug reports for those two separate problems and to provide detailed information for both of them.

Please note that the error log from normal use of NM shows many more errors, including these:

2014-01-04T17:04:41.030757+01:00 svist NetworkManager[646963]: Invalid setting name 'connection'
2014-01-04T17:04:41.030804+01:00 svist NetworkManager[646963]: Invalid setting name '802-11-wireless'
2014-01-04T17:04:41.030859+01:00 svist NetworkManager[646963]: Invalid setting name 'ipv6'
2014-01-04T17:04:41.030903+01:00 svist NetworkManager[646963]: Invalid setting name 'ipv4'
2014-01-04T17:04:41.030963+01:00 svist NetworkManager[646963]: Connection failed to verify: (unknown)
2014-01-04T17:04:41.031015+01:00 svist NetworkManager[646963]:    keyfile:     error in connection /etc/NetworkManager/system-connections/FOSDEM: invalid or missing connection p
roperty '(null)/connection setting not found'

Therefore I assume that there's some low-level problem in the way the config files are parsed. This hypothesis is supported by an observation that the only test which passes is the one that checks list of exported symbols to guard binary compatibility; the very first test case which tries to read any setting fails. I have not tried running the other tests manually, though (I don't know how to persuade make to run some another test after it stops on the first failure; some of the tests apparently require some specialized environment apart from Xvfb).

As for more data, please tell me what you need to know; I would love to help here. In the meanwhile, building and using networkmanager-0.9.6.4 works well.

I don't know what's wrong. I am not familiar with gentoo, but it looks like something was messed up in your build environment.

You said, you already ensured that you got a clean build. Maybe you can look into that once more? Also, does NetworkManager link against the expected libnm-util.so file? (ldd `which NetworkManager`)

You could start NetworkManager in the terminal: after stopping the system deamon (e.g. systemctl stop), start it in the terminal calling:

NetworkManager --debug

-- and in that terminal, also check the used libraries with ldd.

If the libnm-util tests don't pass for you then this is definitely a problem which is local to your machine, and it seems like it involves bits of an older build getting mixed in with your current build somehow.

There is no trace of networkmanager present on the system at the time I perform the build, and no leftovers matching libnm*. Do you have any pointers on what other libraries to check?

No. It seems unlikely to be related to anything but NetworkManager itself.

i suppose doing

  cd libnm-util/tests
  ../../libtool --mode=execute ldd test-secrets

should show you what copies of the libraries the test program is getting run against

(assuming LIBTOOL is set to $(top_builddir)/libtool and $(top_builddir) is "../..")

Tried these steps once again, but no joy:

# emerge -C networkmanager networkmanager-vpnc
(all of the .so libraries provided by either of these packages are gone now as nothing else needs them)
# FEATURES=test emerge -av =networkmanager-0.9.8.8
[... tests fail]
portage@svist ~/net-misc/networkmanager-0.9.8.8/work/NetworkManager-0.9.8.8/libnm-util/tests $ ../../libtool --mode=execute ldd ./test-secrets
        linux-vdso.so.1 (0x00007fff7519b000)
        libnm-util.so.2 => /var/tmp/portage/net-misc/networkmanager-0.9.8.8/work/NetworkManager-0.9.8.8/libnm-util/.libs/libnm-util.so.2 (0x00007f380a93e000)
        libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f380a6e3000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f380a3a3000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f380a186000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3809dde000)
        libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f3809a4e000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f380984a000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f3809641000)
        libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x00007f3809414000)
        libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f38091cb000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f3808fc6000)
        libssl3.so => /usr/lib64/libssl3.so (0x00007f3808d76000)
        libsmime3.so => /usr/lib64/libsmime3.so (0x00007f3808b43000)
        libnss3.so => /usr/lib64/libnss3.so (0x00007f38087e9000)
        libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f38085b9000)
        libplds4.so => /usr/lib64/libplds4.so (0x00007f38083b4000)
        libplc4.so => /usr/lib64/libplc4.so (0x00007f38081ae000)
        libnspr4.so => /usr/lib64/libnspr4.so (0x00007f3807f67000)
        libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f3807d5e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f380abad000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f3807b47000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f3807930000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f380772c000)
portage@svist ~/net-misc/networkmanager-0.9.8.8/work/NetworkManager-0.9.8.8/libnm-util/tests $ ../../libtool --mode=execute ./test-secrets

** (process:444790): WARNING **: Unknown setting '802-3-ethernet'
FAIL: (need-tls-secrets-path-key) failed to verify connection: base setting GType not found

These builds are done from scratch, i.e. no contents from the previous build is used (the build dir is removed prior to tarball extraction). I'm used to debuggers, but I have no experience with GObject and their construction (C++ developer here). What can I do to take a look at e.g. the configuration parser to see how it ends up rejecting valid configuration tokens? (Assuming that the warning shown above is a real one.)

Many thanks to danw on IRC. When I add -fno-partial-inlining to my CFLAGS, the tests pass. The -fpartial-inlining is enabled by default in -O2. I'm using Hardened Gentoo's GCC 4.6.3.

Specifically, the problem seems to be that _ensure_registered() in nm-connection.c is __attribute__((constructor)), but also called explicitly in some places. Apparently this version of gcc was inlining it into each of the explicit call sites and then deciding it could remove the original definition, not noticing that it was also a constructor, thus causing the settings types to not get registered. This is apparently fixed with more recent gcc.