RE: PHP 4.0 Bug #8774 Updated: undefined versioned symbol name __ns_name_unpack@@GLIBC2.1

From: Date: Thu, 18 Jan 2001 20:10:05 +0000
Subject: RE: PHP 4.0 Bug #8774 Updated: undefined versioned symbol name __ns_name_unpack@@GLIBC2.1
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-44511@lists.php.net to get a copy of this message
Given that I've recompiled and re-installed glibc.2.1.3, how could it not be a bug in php? I thought that versioning problems come about when the compiled program "requires" a specific version of an exported function, and the source library doesn't have that version. BTW, what does "atm" (as in 'Your system is not quite well atm') mean? - Mark -----Original Message----- From: Bug Database [mailto:php-dev@lists.php.net] Sent: Thursday, January 18, 2001 3:25 AM To: mark@arcabama.com Subject: PHP 4.0 Bug #8774 Updated: undefined versioned symbol name __ns_name_unpack@@GLIBC2.1 ID: 8774 Updated by: sniper Reported By: mark@arcabama.com Old-Status: Open Status: Bogus Bug Type: Compile Failure Assigned To: Comments: This is not any bug in PHP. Your system is not quite well atm. If you compile GLIBC then you should know what you're doing. Otherwise it is just asking for trouble.I suggest you reinstall your system and use a newer distribution instead. --Jani Previous Comments: --------------------------------------------------------------------------- [2001-01-17 21:03:23] mark@arcabama.com PHP 4.0.4 will not compile on my linux system as a module, although it will compile into a standalone executable. The standalone configure script that I'm using is: ================================= #! /bin/sh # # Created by configure "./configure" "--prefix=/usr" "--with-config-file-path=/etc" "--enable-calendar" "--enable-force-cgi-redirect" "--with-gd=/usr" "--with-jpeg-dir=/usr" "--with-mysql=/usr" "--with-zlib=/usr" "--with-png-dir=/usr" "--with-regex=system" "$@" ================================= The module configure script that I'm using is: ================================= #! /bin/sh # # Created by configure "./configure" "--prefix=/usr" "--with-apxs=/usr/bin/apxs" "--with-config-file-path=/etc" "--enable-calendar" "--with-gd=/usr" "--with-jpeg-dir=/usr" "--with-mysql=/usr" "--with-zlib=/usr" "--with-png-dir=/usr" "--with-regex=system" "--with-exec-dir=/home/httpd/php" "$@" ==================== The module compile crashes in what appears to be the final link to build libphp, on the following line with the following message: ================================ /bin/sh /usr/download/php-4.0.4/libtool --silent --mode=link gcc -I. -I/usr/download/php-4.0.4/ -I/ usr/download/php-4.0.4/main -I/usr/download/php-4.0.4 -I/usr/download/php-4. 0.4/Zend -I/usr/include/ mysql -I/usr/download/php-4.0.4/ext/xml/expat/xmltok -I/usr/download/php-4.0 .4/ext/xml/expat/xmlpars e -I/usr/download/php-4.0.4/TSRM -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -DNO_D L_NEEDED -DXML_BYTE_ORDE R=12 -g -O2 -o libphp4.la -rpath /usr/download/php-4.0.4/libs -avoid-version -L/usr/lib/mysql -R /usr/lib/mysql stub.lo Zend/libZend.la sapi/apache/libsapi.la main/libmain.la ext/calendar/libcale ndar.la ext/gd/libgd.la ext/mysql/libmysql.la ext/pcre/libpcre.la ext/posix/libposix.la ext/session/ libsession.la ext/standard/libstandard.la ext/xml/libxml.la ext/zlib/libzlib.la TSRM/libtsrm.la -ldl -lz -lmysqlclient -lpng -lz -lgd -ljpeg -lresolv -lbind -lm -ldl -lcrypt -l nsl -lresolv -L/usr/lib -ljpeg /usr/i586-pc-linux-gnu/bin/ld: .libs/libphp4.so: undefined versioned symbol name __ns_name_unpack@@GLIBC_2.1 /usr/i586-pc-linux-gnu/bin/ld: failed to set dynamic section sizes: Bad value ======================= I have tried quite a few things to fix this problem, including rebuilding and reinstalling the glibc library (v2.1.3). When I run nm against libresolv, __ns_name_unpack doesn't have an explicit version attached to it (i.e., it shows up as __ns_name_unpack, not __ns_name_unpack@@GLIBC_x.y). - Mark --------------------------------------------------------------------------- Full Bug description available at: http://bugs.php.net/?id=8774

« previous php.dev (#44511) next »