(In reply to comment #0)
> - bus/activation-helper.h should include dbus-errors.h

Strictly speaking, yes (or <dbus/dbus.h> would be even better). However, this doesn't seem to be a practical problem at the moment, because everything that includes it includes either utils.h or test.h first?

> - ld failed, because sd_is_socket, isn't defined

Already fixed in git, will be in 1.4.4, 1.5.0.

(In reply to comment #1)
> However, this
> doesn't seem to be a practical problem at the moment, because everything that
> includes it includes either utils.h or test.h first?

Confirmed to be not a practical problem, at least on Linux. However, the build fails for an unrelated reason. Patch on the way.

Created attachment 46089 [details] [review]
cmake: always enable GNU and recent-POSIX extensions, like  autoconf does

Not doing this broke the cmake build on Linux, where SO_PEERCRED is
defined unconditionally, but struct ucred is considered to be a GNU
extension.

(In reply to comment #3)
> Created an attachment (id=46089) [details]
> cmake: always enable GNU and recent-POSIX extensions, like  autoconf does
> 
> Not doing this broke the cmake build on Linux, where SO_PEERCRED is
> defined unconditionally, but struct ucred is considered to be a GNU
> extension.

In configure.ac the following defines are only added when activating ansi as shown: 
  if test "x$enable_ansi" = "xyes"; then
    TP_ADD_COMPILER_FLAG([WARNING_CFLAGS],
      [-ansi -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -pedantic])
  fi

would it not make sense to use the same context ? 

Additional autotools uses _BSD_SOURCE instead of _GNU_SOURCE.

The flags other than -ansi -pedantic are probably redundant now, because AC_USE_SYSTEM_EXTENSIONS (further up configure.ac) defines __EXTENSIONS__, _ALL_SOURCE, _GNU_SOURCE, _POSIX_PTHREAD_SEMANTICS, _TANDEM_SOURCE (some of which are only necessary on certain platforms).

See commit 18b08180 - the changes to .c files in that commit are what broke the cmake build on Unix.

Review of attachment 46089 [details] [review]:

Won't this also define them when using MSVC? (I don't really speak CMake.)

(In reply to comment #6)
> Won't this also define them when using MSVC? (I don't really speak CMake.)

Yes, but so does configure (via AC_USE_SYSTEM_EXTENSIONS), so...

As far as I understand it, the purpose of _GNU_SOURCE etc. is that when they're not defined, glibc hides functionality that is in a namespace reserved by the C or POSIX standard, but not specified by that standard; for instance, strfry(3) is only declared if you define _GNU_SOURCE, because strictly speaking, anything starting with str is meant to be reserved by ISO C.

Only libc headers should be testing those macros; they're not like "#define __linux__" or similar. They're an opt-in to extra GNU features, not a feature test.

Created attachment 49618 [details] [review]
replacement patch for current dbus-1.4

Updated version of the patch, with a hopefully-clearer description:

    cmake: always enable GNU and recent-POSIX extensions, like autoconf does
    
    If the C library is (e)glibc, this allows use of POSIX, BSD, SVID, GNU,
    etc., extensions to ISO C, regardless of using -ansi or not.
    
    Not doing this broke the cmake build on Linux since commit 18b08180,
    which added AC_USE_SYSTEM_EXTENSIONS to configure.ac (and removed
    _GNU_SOURCE from files that use it) without also updating the cmake
    build system. SO_PEERCRED is defined unconditionally, but struct ucred
    is considered to be a GNU extension, so can't be used under _GNU_SOURCE.

Created attachment 49619 [details] [review]
alternative patch: revert Lennart's change to how this works

If people would prefer it, this is the other way this could be fixed:

    Define _GNU_SOURCE in files that need it (again)
    
    This reverts commit 18b08180aa5a4417fa1d6d268a1aad894e8a4549.

Review of attachment 49618 [details] [review]:

I think this is fine, ship it.

(In reply to comment #10)
> Review of attachment 49618 [details] [review]:
> 
> I think this is fine, ship it.

Shipped it. 1.4.16, 1.5.8.