#1 compile error on amd64

[Anonymous]

Using gcc 3.3.3 and 3.4 on an amd64 platform (gentoo
linux), I get the following compile error:

quark tmdns-0.5.1 # make
Making all in scripts
make[1]: Entering directory
`/home/christiaan/tmdns-0.5.1/scripts'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/home/christiaan/tmdns-0.5.1/scripts'
Making all in server
make[1]: Entering directory
`/home/christiaan/tmdns-0.5.1/server'
make all-am
make[2]: Entering directory
`/home/christiaan/tmdns-0.5.1/server'
gcc -g -O2 -o tmdns tmdns-conf.o tmdns-debug.o
tmdns-llist.o tmdns-dns.o tmdns-getifaddrs.o
tmdns-info.o tmdns-tmdns.o tmdns-serv_udp.o
tmdns-dns.o(.text+0xb2): In function `dns_compress_domain':
/home/christiaan/tmdns-0.5.1/server/dns.c:82: undefined
reference to `__dn_comp'
tmdns-dns.o(.text+0x93d): In function `dns_walk_buf':
/home/christiaan/tmdns-0.5.1/server/dns.c:429:
undefined reference to `__dn_expand'
tmdns-dns.o(.text+0x9f5):/home/christiaan/tmdns-0.5.1/server/dns.c:470:
undefined reference to `__dn_expand'
tmdns-info.o(.text+0x1821): In function `decode_packet_cb':
/home/christiaan/tmdns-0.5.1/server/info.c:1155:
undefined reference to `__dn_expand'
tmdns-info.o(.text+0x1a1a):/home/christiaan/tmdns-0.5.1/server/info.c:1231:
undefined reference to `__dn_expand'
collect2: ld returned 1 exit status
make[2]: *** [tmdns] Error 1
make[2]: Leaving directory
`/home/christiaan/tmdns-0.5.1/server'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/christiaan/tmdns-0.5.1/server'
make: *** [all-recursive] Error 1

[Nobody/Anonymous]

Logged In: NO

adding -lresolve to the linker flags solves the problem :)

[Freek Dijkstra]

Logged In: YES
user_id=249025

Though I only want to update zcip, and not tmdns, I just checked.

"-lresolve" should be added to this gcc command if it is present. The
configure script does so by checking for the dn_expand() function in the
resolv library.

I just got access to a host with Debian on an Opteron (= AMD64 =
x86_64). Configure gave this error: "checking for dn_expand in -lresolv...
cat: confdefs.h: No such file or directory
no". Apparently, there is a problem reading confdefs.h and confdefs.c om
AMD which causes this problem. This is most likely a problem cuased by
a bad configure script.

A summary:
- download 0.5.1, run configure script on AMD64: error
- download 0.5.1, run configure script on 686: no problem
- download CVS, autogen.sh on 686, run configure on 686: no problem
- download CVS, autogen.sh on 686, run configure on AMD64: no problem
- download CVS, autogen.sh on AMD64, run configure on 686: no problem
- download CVS, autogen.sh on AMD64, run configure on AMD64: no
problem

My conclussion: configure was generated with an older version of autoconf
(or automake?). I have autoconf 2.59, the configure script in the 0.5.1 was
generated with autoconf 2.57.

Resolution: make new distribution, using a newer autoconf version.

[Freek Dijkstra]

Logged In: YES
user_id=249025

I was close :-)

Just recreating the configure script didn't work. autoconf uses a specific
trick to detect if a function is defined in a library. In this case, it is
checking if the dn_expand() function exists. However, libresolv doesn't just
define "int dn_expand(unsigned char *msg, unsigned char *eomorig,
unsigned char *comp_dn, unsigned char *exp_dn, int length);" like you
would expect. Instead, it does "#define dn_expand __dn_expand". I have
no clue why libresolv does it in this way.

Anyway, autoconf just defines an empty dn_expand() function, and on 32-
bit machines, this will yield the symbol __dn_expand in the shared library.
So that works fine. However, apparently, on 64-bits machines that doesn't
work.

Adding "AC_CHECK_LIB(resolv, __dn_expand)" to configure.in (next to
the already existing "AC_CHECK_LIB(resolv, dn_expand)" does solve the
trick, though I find it a rather ugly solution.