From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: unbound 1.6.1 => '--with-libevent'-option ineffective!?
Date: Mon, 10 Apr 2017 16:34:53 +0100
Message-ID: <1491838493.11653.9.camel@ipfire.org>
In-Reply-To: <91b2873f-5f47-e7ae-f791-ed171311a0cf@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7606240164867497302=="
List-Id: <development.lists.ipfire.org>

--===============7606240164867497302==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

thanks for looking into this.

On Mon, 2017-04-10 at 10:16 +0200, Matthias Fischer wrote:
> Hi,
>=20
> Today there was a confirmation of my assumption, the 'configure' option
> '--with-libevent-support' is NOT enough (unbound-users(a)unbound.net):
>=20
> ***SNIP***
> > > > > When building unbound with --with-libevent support, the make
> > > > > install phase should also call make unbound-event-install or else
> > > > > unbound-event.h does not get installed and the header file for
> > > > > using the unbound event functionality is not available.
> > >=20
> > > Hello,
> > >=20
> > > the same "missing unbound-event.h" happen when building getdns
> > > > > (https://getdnsapi.net)
> > >=20
> > > Thanks for the hint, Paul!
>=20
> This install is triggered by the option --enable-event-api .=C2=A0=C2=A0Just
> enabling --with-libevent does not trigger the install by itself.
>=20
> Best regards, Wouter
> ***SNAP***

This rather sounds to me that any libraries that link against libunbound will
only use libevent then. This is probably not a good idea not to abstract this.

> The 'libevent' update on the '1.4.15-stable' has unfortunately not
> built, there were heaps of errors.
>=20
> Because 'unbound' detects an existing 'libevent2' installation
> (Changelog, line 1609: Detect libevent2 install automatically by
> configure.) I first concentrated on updating 'libevent2' to 2.1.8
> because '2.0.22' from 2014-01-05 seemed rather old.
>=20
> The detection worked, 'unbound' with '--with-libevent' and
> '--enable-event-api' and 'libevent2 2.1.8' run both here in test.

My version is already linked against libevent:

[root(a)ipfire ~]# ldd /usr/sbin/unbound
	linux-vdso.so.1 =3D>=C2=A0=C2=A0(0x00006ad33eb06000)
	libssl.so.10 =3D> /usr/lib/libssl.so.10 (0x00006ad33e67c000)
	libevent-2.0.so.5 =3D> /usr/lib/libevent-2.0.so.5 (0x00006ad33e434000)
	librt.so.1 =3D> /lib/librt.so.1 (0x00006ad33e22b000)
	libcrypto.so.10 =3D> /usr/lib/libcrypto.so.10 (0x00006ad33dde9000)
	libpthread.so.0 =3D> /lib/libpthread.so.0 (0x00006ad33dbcc000)
	libc.so.6 =3D> /lib/libc.so.6 (0x00006ad33d836000)
	libgcc_s.so.1 =3D> /usr/lib/libgcc_s.so.1 (0x00006ad33d620000)
	libdl.so.2 =3D> /lib/libdl.so.2 (0x00006ad33d41c000)
	/lib64/ld-linux-x86-64.so.2 (0x00006ad33e8e8000)

>=20
> Special feature:
> 'Kbd 1.12' complains because of a few 'rootfile'-changes, otherwise no
> other conspicuousness. Operation is stable.

This is probably caused by something else... It's already happening in the la=
st
nightly build.

>=20
> Best,
> Matthias

--===============7606240164867497302==
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"
MIME-Version: 1.0

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC
Q2dBR0JRSlk2NllkQUFvSkVJQjU4UDl2a0FrSHRtNFAvMVN6NjBPRTM0U24yRGtwVkVnZG5nR2wK
Y3ZGcUxseUpuemxDNEJ3YklGQWpyVU1RYnk3TVZqZ2dnY2hGT3JwTmU5OExTUVVNZHVvV1ByVHNB
L0luclFVegpFQmhUdXJZWmxuK0VoMXdSTUFybUJrcHQ5VTNUam1ZbVdqOVk2dVZYdUtzZ0JHR2I0
b3F5ZnJPRkhxbDJ6N0VXCit3bll2SWlOcVVYUzEwK3NDUmk5NDJjNUNJLzlXdmk2bzNDanFyZHdK
VDkyRE9PMjdYcEZjeDIzbW9LMnhzWS8KV1A3WC9oQXY4cVRsdFVUM3FPTDlNVEhBd0tXZDFjbU02
ZTlEQlhTd2tKdEd6L0ZqcjUxQXdRSENuMWpVQ3RtZwpOUG1MSnIvMFlGWldKblU3dWRnRmlhcFUv
REJqUnFjdW9FS2xPSDFxb0YxaFBGa3JZSG53RGlLaW9MY0JCakxFCitidDlGRkREK0o1eXNyN3NW
bktzWjRxUGs5SU1JNlRjblczaFIvRUtvRlRsTTltTlhQdFRIc3ZXa3U2aWx4eEQKRzE0Z1FZZjRN
MEhMTkJRaG9XMTk1dG8zMGJJQ0VRK3pMWEZuTmpCalcxeDY5K1QxTG04S2NJSWg4S3Y2ekJjaQo0
ZlZQY0w3TEt5UklGTjhOVW5GTE1VQ0RmS2JyaGVzcmRDenpUV3FwRU9uT1lMdWlGMkFpMTY1aWNM
blliaXc2ClZKQk1aaEhTN2Y2NnJOZy9qOWNhSTBHc1gwSGo0QmdDcWRROHBHWXJEZWdOQk1pK21k
SjRnMGRGZmdkdjhRR1MKSlBGWkMxNGhmNU93dDcvcWVxck1KMmVLS3pzOC9QNUxBWHl0OEE2N0hm
MXhwWUNDRDJTbXcydk40amNnUlBIQQo4L3YydGUyeVdmQVpNRVB5eHVZUQo9NVlseQotLS0tLUVO
RCBQR1AgU0lHTkFUVVJFLS0tLS0K

--===============7606240164867497302==--