1.14.2: Compile errors when using --with-systemd-journal=yes

[Torsten Hilbrich]

On 18.09.20 10:16, Aleksander Morgado wrote:
> Hey,
> 
>>
>> I just did some first testing with the new stable version 1.14.2 (Updating from 1.12.12) and noticed some regressions regarding the support of systemd-journal.
>>
> 
> Why is this a regression between 1.14.2 and 1.12.12? IIRC no change
> was done in the journal support in MM. What would be the change that
> broke it?

I was able to find out the list of requirements for the issue to be shown:

- the headers from systemd needs to be included from some other
directory than the system includes so the special warning handling for
system includes does not apply (see -isystem and -Wsystem-headers)

- the update from 1.12.12 to 1.14.2 included the commit

1c078531 build: use AX_IS_RELEASE() and AX_COMPILER_FLAGS()

which caused the "-Wundef" compiler flag to appear in aclocal.m4. When
removing the AX_COMPILER_FLAGS and AX_COMPILER_FLAGS_CFLAGS from
configure.ac the problem is no longer reproducible

This combination of not having the systemd headers in the /usr/include
directory and the combination of -Werror and -Wundef causes the issue.

Here is a minimal example to reproduce it on a regular system:

~/tmp$ cat foo.c
#define SD_JOURNAL_SUPPRESS_LOCATION
#include <systemd/sd-journal.h>
~/tmp$ gcc -c --std=gnu89 -Wundef -Werror -Wsystem-headers foo.c
In file included from /usr/include/systemd/sd-id128.h:23,
                 from /usr/include/systemd/sd-journal.h:26,
                 from foo.c:2:
/usr/include/systemd/_sd-common.h:88:7: error: "__STDC_VERSION__" is not
defined, evaluates to 0 [-Werror=undef]
   88 | #  if __STDC_VERSION__ >= 199901L
      |       ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

> Truth be told, I don't know whether we should patch this, or how we
> should do it. I would first like to understand why no one else has
> this issue and is only seen in your build setup. Don't take me wrong,
> I'm not saying we're not going to fix this because it happened only to
> you, I just want to have the whole picture first to see how it should
> be best fixed.

I also don't know what is the best way to handle it. It will most likely
be an issue for people not building against the system headers but
against some component-based directory layout where each dependency is
stored in some sub-directory (such as
/build/client/3.5.x/systemd/_/include) in our case.

	Torsten