Undefined Versioned Symbol

From: Date: Fri, 19 Jan 2001 20:24:21 +0000
Subject: Undefined Versioned Symbol
Groups: php.dev 
Request: Send a blank email to php-dev+get-44595@lists.php.net to get a copy of this message
I've been having problems getting php-4.0.4 to compile on my linux system; the make keeps breaking when libphp.so is being linked with an undefined versioned symbol name __ns_name_unpack@@GLIBC_2.1 error. I've rebuilt and reinstalled glibc2.1.3, and every library I know of that php depends on, but that didn't solve the problem. I saw a post in the php bug database about the exact same problem which the poster solved by creating a shared version of libbind (which is not supported in the isc.org release of bind). This lead me to run objdump on both libbind.a and libresolv.so.2. Here's what I found: objdump -x /lib/libresolv.so.2 | grep __ns_name: 00004424 g F .text 0000011a __ns_name_unpack 00004044 g F .text 000001db __ns_name_ntop objdump -x /usr/lib/libbind.a | grep __ns_name: [...snip...] 000003e4 g F .text 00000105 __ns_name_unpack 00000684 g F .text 00000063 __ns_name_uncompress 000006e8 g F .text 00000057 __ns_name_compress 00000000 g F .text 000001ae __ns_name_ntop [...snip...] If I'm reading this correctly (I'm not experienced in programming under linux), this looks like both libresolv.so.2 (a shared library, part of glibc) and libbind.a (a static library, part of bind) are exporting __ns_name_unpack and __ns_name_ntop. Somehow, this does not strike me as a good thing for programs like php, which link against both libraries. Is this potentially the source of my make problem? And, if so, what can I do about it? - Mark mark@arcabama.com

« previous php.dev (#44595) next »