Autoconf generates the following code to check for the existance of res_mkquery: #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char res_mkquery(); int main() { res_mkquery() ; return 0; } This fails on my system because res_mkquery is actually exported as __res_mkquery, resolv.h contains "#define res_mkquery __res_mkquery". The configure script can be forced to work by changing 'res_mkquery' to '__res_mkquery' - but this will probably break on older versions of libresolv. I am using libresolv-2.3.4 and Autoconf version 2.13. Actual Results: checking for res_mkquery... no checking for res_mkquery in -lbind... no checking for res_mkquery in -lresolv... no configure: error: No resolver library found Reproducible: Always Steps to Reproduce: 1. emerge mtr (or any other program which uses an Autoconf generated configure script to check for the existance of libresolv) Portage 2.0.50-r8 (gcc34-amd64-2004.1, gcc-3.4.0, glibc-2.3.4.20040605-r0, 2.6.6) ================================================================= System uname: 2.6.6 x86_64 4 Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -march=athlon64 -fweb -ftracer" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -march=athlon64 -fweb -ftracer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://194.83.57.11/sites/www.ibiblio.org/gentoo/ http://194.83.57.3/sites/www.ibiblio.org/gentoo/ http://194.83.57.2/sites/www.ibiblio.org/gentoo/ http://194.83.57.7/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa amd64 apm avi berkdb crypt dvd esd foomaticdb gdbm gif gpm gtk2 imlib java jpeg libg++ libwww mikmod mozilla moznocompose moznoirc mpeg mysql ncurses nls nptl oggvorbis opengl pam pdflib perl png python quicktime readline sdl slang spell ssl tcltk tcpd threads truetype xinerama xml2 xmms xv xvid zlib"
Just noticed that the version of Autoconf reported in emerge info differs from the output of 'autoconf --version' (which reports 2.13). This seems a bit odd.
That's not so odd. autoconf is a wrapper script and is controlled by WANT_AUTOCONF. what glibc version do you have?
$ gcc --version gcc (GCC) 3.4.0 20040601 (Gentoo Linux 3.4.0-r6, ssp-3.4-2, pie-8.7.6.3) $ ll /lib/libc.so.6 lrwxrwxrwx 1 root root 13 Jun 7 21:00 /lib/libc.so.6 -> libc-2.3.4.so
Well, can you post the output of "epm -qi glibc"? also, attach your /usr/include/resolv.h. thanks.
Created attachment 34877 [details] /usr/include/resolv.h # epm -qi glibc Name : glibc Version : 2.3.4.20040605 Release : Slot: 2.2 Install date: Mon Jun 7 21:00:03 2004 Build Host: x86_64-pc-linux-gnu Group : sys-libs License: LGPL-2 Size : 299602645 Packager : lv URL : http://sources.redhat.com/glibc/ Description : GNU libc6 (also called glibc2) C library resolve.h is attached.
No considerable change from 2.3.2 to 2.3.4 as far as the header file goes. can I see your objdump -Tt /lib/libresolv-2.3.4.so ? in my glibc (2.3.2) there's two symbols: res_mkquery as well as __res_mkquery (both at the same offset), I'd be interested to know if your .so lacks the first symbol.
Created attachment 34880 [details] libresolv-2.3.4 symbol table $ objdump -Tt /lib/libresolv-2.3.4.so|grep res_mkquery 0000000000007350 g DF .text 00000000000000c7 GLIBC_2.2.5 __res_mkquery
I have compiled glibc-2.3.4 (2.3.4.20040619) and my symbol table DOES have res_mkquery: 000063b0 w DF .text 0000009f GLIBC_2.0 res_mkquery 000063b0 g DF .text 0000009f GLIBC_2.2 __res_mkquery I wonder if that's an amd64 issue alone. (or just 64 archs?)
this is normal. i thought i remembered a patch from suse that makes configure.in look for __res_mkquery instead, and the glibc from fedora is exactly like ours: ayanami libc # objdump -Tt ./lib64/libresolv-2.3.3.so | grep res_mkquery 0000000000000000 l df *ABS* 0000000000000000 res_mkquery.c 0000000000007e10 g F .text 00000000000000c7 __res_mkquery 0000000000007e10 g DF .text 00000000000000c7 GLIBC_2.2.5 __res_mkquery i really dont think this is a bug. i might be wrong, but i think only x86 and ppc have res_mkquery along with __res_mkquery.
If it is not a bug, it's a braindamage - libresolv should be consistent in the symbols it exports. Unless there's a very good reason not to, but as this is a resolver issue, not something that might be arch-tied, I can't think of any. Ok, so do we work around this issue per ebuild, or is some general autoconf hack possible?
i'd say per ebuild... sed -i -e "s/res_mkquery/__&/g" configure.in autoconf cant hurt to report upstream whenever a problem like this occurs. x86 should export the __ versions as well as res_mkquery, so it wont have to be an arch specific thing either.
Either that or adding another AC_CHECK_LIB(resolv, __res_mkquery, , ... ) to configure.in. (like I just did in mtr)
