[Unbound-users] unbound 1.4.6 build issue

[Paul Wouters]

First, there were signs I was building with the "supplied" ldns library
instead of the system one. It turns out the configure code does some
automagic when it does not find the right ldns.h. This is very dangerous.

When people grab the unbound source rpm, and rebuild it using rpmbuild
and their ldns-devel is too old, they will end up with a static ldns
snapshot inside their frankenbuild unbound without realising this.
This has happened to me when I had ldns-1.6.4 installed and was building
unbound-1.4.6. It should error out with "ldns >= 1.6.6 not found"

I would really like to stress once more to NOT SHIP some ldns source
blob with unbound. Unbound and ldns are either one package or two,
but not both. I don't see libevent source blobs either. If you really
want to ship ldns as part of unbound, call it unbound-ldns and abandon
ldns as a separate package.

To ensure I am not mistakenly uses some static ldns blob, I now do an rm
of the ldns-src.tar.gz file before running unbound's configure script.
But anyone doing a manual install will still be hit by this.

Furthermore, the error I then got was "No ldns library found and
no ldns-src.tar.gz".  This confused before because ldns-devel was
installed. Turns out what configure really meant to say was "No new
enough ldns library found and no ldns-src.tar.gz". It would be useful
to update this error message.

The next build issues I got was a string of:

Depend compat/strlcpy.c
make[1]: Entering directory `/usr/lib64'
make[1]: *** No rule to make target `copy-headers'.  Stop.
make[1]: Leaving directory `/usr/lib64'
Depend validator/validator.c

This was due to --with-ldns=%{_libdir}
If I use --with-ldns it tries to get into the directory "yes".
So I had to leave out --with-ldns, and hope for the best since AFAIK unbound
requires ldns and configure searches and finds it fine.

I then got:

Link libunbound.la
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64/libevent.a(event.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64/libevent.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libunbound.la] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.P8A1Yf (%build)

This happens with and without --with-pic. The configure line on PIC shows:

checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no

I am a little confused why it is trying to use libevent.a and not libevent.so

This is using gcc (GCC) 4.5.1 20100907 (Red Hat 4.5.1-3)

Paul