Attempting to configure r4762 is now "libsystemd not found".
However, we have confirmed that libsystemd related packages are
installed as follows.
checking for libexpat... found in /usr
checking for expat.h... yes
checking whether XML_StopParser is declared... yes
checking for libhiredis... checking for SYSTEMD... no
checking for SYSTEMD_DAEMON... no
configure: error: systemd enabled but libsystemd not found
$ dpkg -l | grep libsystemd
ii libsystemd-dev:armhf 232-25+deb9u3
armhf systemd utility library - development files
ii libsystemd0:armhf 232-25+deb9u3
armhf systemd utility library
At least, v1.7.3 confirms that configure will succeed.
It seems that the periphery of pkg - config has been modified with
r4757 etc, but is there anything related to this area?
# I'm sorry. I had no ability to read the configure file.
Attempting to configure r4762 is now "libsystemd not found".
However, we have confirmed that libsystemd related packages are
installed as follows.
It needs ht libsystemd-dev package with the header files.
It may also be the case that the difference is that configure was
generated but aclocal was not used, pkg-config autoconf macros did not
get instantiated and this makes the systemd detection fail. So, not
just run 'autoconf' but also aclocal (or run autoreconf that combines them).
I saw that the libhiredis printout is a problem, and I fixed that
printout in r4764.
In r4657 there is a change in configure.ac in the pkg-config macros for
making python module config use it. This change could be the culprit,
but I don't understand how detecting pkg-config could be a problem for
systemd detection later that also uses pkg-config.
referenced by listen_dnsport.c:148 (services/listen_dnsport.c:148)
.libs/listen_dnsport.o:(systemd_get_activated)
collect2: error: ld returned 1 exit status
Makefile:322: recipe for target ‘unbound’ failed
make: *** [unbound] Error 1
I am also worried about warnings appearing on the way as follows.
services/listen_dnsport.c: In function ‘systemd_get_activated’:
services/listen_dnsport.c:148:8: warning: implicit declaration of function ‘sd_is_socket_sockaddr’ [-Wimplicit-function-declaration]
if(sd_is_socket_sockaddr(
^~~~~~~~~~~~~~~~~~~~~
I tried it with commit of trunk @ 4820.
In this case, is there anything else you need to deal with?
Are you interested in using the socket activation code? Because I got
replies for the NSD daemon that systemd socket activation is not useful
for DNS servers and the code has bugs (and I want to remove bugs). It
is possible to not use the sockaddr code, but I wanted to add more
checking to remove potential bugs. If you use systemd, perhaps you can
tell me what is actually useful for systemd users; and then I'll use
that version of the systemd_get_activated routine.
The code repository version should howevery have much better readiness
signalling for systemd, I took it out of a signal handler and rewrote it
elsewhere to only get enabled when the use-systemd config option in
unbound.conf is set to yes.
If you need code without the sockaddr check, here is the patch:
Thank you for your reply and information.
I am running this build in the following environment.
$ uname -mrs
Linux 4.14.18-sunxi armv7l
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.5 (stretch)
Release: 9.5
Codename: stretch
The version of systemd in this environment was 232.
$ dpkg -l | grep systemd
ii libpam-systemd:armhf 232-25+deb9u4
armhf system and service manager - PAM module
ii libsystemd-dev:armhf 232-25+deb9u4
armhf systemd utility library - development files
ii libsystemd0:armhf 232-25+deb9u4
armhf systemd utility library
ii python-systemd 233-1
armhf Python 2 bindings for systemd
ii python3-systemd 233-1
armhf Python 3 bindings for systemd
ii systemd 232-25+deb9u4
armhf system and service manager
ii systemd-sysv 232-25+deb9u4
armhf system and service manager - SysV links
I checked the debian repository, but this seems to be the latest at the moment.
In the debian environment, do you think that build can not be built
with systemd enabled?
Thank you for your reply and information.
I am running this build in the following environment.
I see this version of Debian is not at that version for systemd. Okay,
I have applied the patch I proposed previously to the unbound source, so
that unbound can build for that system. Thank you for checking the
version numbers.