[dns-operations] Compiling ncap on Debian/Linux (Was: "NS .", the attack of the month?

[Ray.Bellis at nominet.org.uk]

> Does not work for me yet (note the -shared despite --disable-shared in
> ncap's configure):

The -shared is because mod_test.so is a shared module that is loaded at 
run-time via dlopen(), regardless of whether the main binary is statically 
or dynamically linked.

> /bin/sh ./libtool --mode=link gcc -module -shared -o mod_test.so 
mod_test.lo
> gcc -shared -o mod_test.so mod_test.o 
> /usr/bin/ld: mod_test.o: relocation R_X86_64_32 against `a local 
> symbol' can not be used when making a shared object; recompile with 
-fPIC
> mod_test.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[1]: *** [mod_test.so] Error 1
> make[1]: Leaving directory `/home/bortzmeyer/tmp/ncap-1.5.0'
> make: *** [all] Error 2

I've just tried this myself on 64-bit CentOS 5.2, where the build normally 
works correctly anyway.

Check what's in the mod_test.lo file.  It should have references to both a 
"pic_object" and a "non_pic_object".  For some reason your linker appears 
to be choosing the non-pic version from $CWD, instead of the one built 
with -fPIC that on my system is built in the .libs/ directory.

In fact I've just tried a build with '--disabled-shared' too and now get 
the same error.  It appears that building a static version of the main 
binary prevents the build system from building the -fPIC version of 
mod_test.o that's needed to build the .so file.

At a guess, I think the autoconf system needs to be told that mod_test.o 
needs to be built with -fPIC independently of the settings used for the 
rest of the object files.

Ray