[Unbound-users] unbound 1.4.6 build issue

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

You first two issues are fixed in svn r2305.

The libevent.so issue remains.  Could you retry with the newer svn; and
could you also see if libevent.so exists?  (and perhaps give me output
of make QUIET=no so we can look at the -Llibdir statements).  It could
be that no .so exists and thus the .a is linked with.

Perhaps this is about the flags that libevent was compiled with, i.e. it
insists on -fPIC for the libevent code?  Earlier there was a similar
issue with Solaris, as libevent did not set (some define) for
threadsafety, and thus could not be linked with unbound (that did set it).

Nice new compiler, by the way, I believe it supports -flto.  Which does
whole-program-optimization, from which perhaps unbound could gain some
speed :-)

Best regards,
   Wouter

On 10/24/2010 04:02 AM, Paul Wouters wrote:
> 
> 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
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at unbound.net
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzFNsMACgkQkDLqNwOhpPgObACghbasBIdxF1Fm0pe7WxYkuNfp
c4wAn28kG0U1bVVTqNqV/7HomC+q+ErL
=psXN
-----END PGP SIGNATURE-----