http://www.gentoo.org/proj/en/qa/asneeded.xml Unaware of correct way to fix this problem, would do myself If I could This problem occurs in both versions of php when using --as-needed in LDFLAGS configure:71453: i686-pc-linux-gnu-gcc -o conftest -O2 -march=i686 -mtune=athlon-xp -pipe -ggdb -pthread -D_REENTRANT -I/usr/include -L/us r/lib -Wl,-O1,-z,combreloc,--as-needed,--sort-common,--enable-new-dtags -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -lldap -llber conftest. c -lgds -lt1 -lfreetype -lX11 -lXpm -lpng -lz -ljpeg -lexslt -lxml2 -lxslt -lz -ldb-4.3 -lresolv -lm -ldl -lnsl -lgssapi_krb5 -lkrb5 -lk5c rypto -lcom_err -lssl -lcrypto -ldl -lxml2 -lz -lm >&5 /tmp/..var/portage/php-4.4.2-r6/temp/cc0SdkIx.o: In function `main': /tmp/..var/portage/php-4.4.2-r6/work/php-4.4.2/conftest.c:290: undefined reference to `ldap_bind_s' collect2: ld returned 1 exit status configure:71459: $? = 1 configure: failed program was: | /* confdefs.h. */ ---<snipped>---- | /* end confdefs.h. */ | /* Define ldap_bind_s to an innocuous variant, in case <limits.h> declares ldap_bind_s. | For example, HP-UX 11i <limits.h> declares gettimeofday. */ | #define ldap_bind_s innocuous_ldap_bind_s | | /* System header to define __stub macros and hopefully few prototypes, | which can conflict with char ldap_bind_s (); below. | Prefer <limits.h> to <assert.h> if __STDC__ is defined, since | <limits.h> exists even on freestanding compilers. */ | | #ifdef __STDC__ | # include <limits.h> | #else | # include <assert.h> | #endif | | #undef ldap_bind_s | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char ldap_bind_s (); | /* The GNU C library defines this for functions which it implements | to always fail with ENOSYS. Some functions are actually named | something starting with __ and the normal name is an alias. */ | #if defined __stub_ldap_bind_s || defined __stub___ldap_bind_s | choke me | #endif | | int | main () | { | return ldap_bind_s (); | ; | return 0; | } configure:71492: result: no configure:71498: error: LDAP build check failed. Please check config.log for more information.
added blocker as per instructions.
Need latest unstable cyrus-sasl. *** This bug has been marked as a duplicate of 116458 ***
I do not belive this is the same bug. cyrus-sasl compiles fine for me ( 2.1.22 ) the problem occurs when compiling _PHP_ with --as-needed, the configure tests to see if cyrus-sasl is installed fail, so surely the problem is in php's config scripts due to bad linking order somehow. I am using the lastest version of of Cyrus-sasl that exists in portage, and it includes an as-needed patch as incated by * Applying cyrus-sasl-2.1.22-as-needed.patch ... " the line the configure script executes is: i686-pc-linux-gnu-gcc -o conftest -O2 -march=i686 -mtune=athlon-xp -pipe -ggdb -pthread -D_REENTRANT -I/usr/include -L/usr/lib -Wl,-O1,-z,combreloc,--as-needed,--sort-common,--enable-new-dtags -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -lldap -llber test2.c -lgds -lt1 -lfreetype -lX11 -lXpm -lpng -lz -ljpeg -lexslt -lxml2 -lxslt -lz -ldb-4.3 -lresolv -lm -ldl -lnsl -lgssapi_krb5 -lkrb5 -lk5crypto /tmp/ccUqVAwh.o: In function `main': /tmp/test2.c:289: undefined reference to `ldap_bind_s' collect2: ld returned 1 exit status which fails ( well, thats my manual simulation using the same source file/compile line ) I toyed with the order of operands a little, and placing the conftest.c before the -lldap parameter permits this command to complete without failure. I will attempt to figure out how to fix the config script as per instructions to resolve this issue.
Created attachment 95010 [details, diff] php_ldap_assneeded patch this appears to fix the configure test problem, mainly by reorganizing the "ac_link" parameters so that the .c file is listed before the -lldap instead of after it :) epatch "${FILESDIR}/php_ldap_asneeded.patch" before php4_4-sapi_src_unpack in the ebuild to use :) tested successfull configuration with dev-lang/php-4.4.2-r6 but i suspect this patch could be applied on any version of php. ( compiling as we speak..so.. i presume its a fix, somebody please confirm ) [ebuild R ] dev-lang/php-4.4.2-r6 USE="apache apache2 bcmath berkdb bzip2 calendar cgi cjk cli crypt ctype doc exif expat flatfile force-cgi-redirect ftp gd gdbm gmp iconv inifile ipv6 kerberos ldap mcal mcve memlimit mhash mysql ncurses nls odbc pcntl pcre posix postgres readline session sharedext snmp sockets spell sqlite ssl sysvipc threads tokenizer truetype unicode wddx xml xmlrpc xpm xsl yaz zip zlib -adabas -birdstep -cdb -concurrentmodphp -curl -db2 -dbase -dbmaker -dbx -debug -discard-path -empress -empress-bcs -esoob -fastbuild -fdftk -filepro -firebird -frontbase -gd-external -hardenedphp -hyperwave-api -imap -informix -interbase -iodbc -java-external -java-internal -libedit -ming -mnogosearch -msql -mssql -oci8 -oci8-instant-client -oracle7 -overload -ovrimos -pfpro -pic -recode -sapdb -sharedmem -solid -sybase -sybase-ct"
"While using autotools there are usually small cases where this happens, because usually libs are fed either via the LIBS variable in the configure script or are listed in the LDADD/LIBADD variables for the target which is being built. The only case when this happens to be a problem is when the libraries get fed into LDFLAGS variable (which is incorrect)." It appears this is the case ( hence the LDFLAGS="$LDFLAGS $LIBADD" pattern ) so, if my understanding is correct, basically the php crew need to rewrite the config files :)
Created attachment 95715 [details, diff] ebuild that "works for me" with this ebuild and attached patches I managed to build php with --as-needed and following useflags: "apache2 bcmath berkdb bzip2 calendar cgi cjk cli crypt ctype curl curlwrappers doc exif force-cgi-redirect ftp gd-external gdbm gmp hash iconv imap ipv6 ldap memlimit mhash mysql mysqli ncurses nls pcntl pcre pdo-external posix postgres readline reflection sasl session sharedext simplexml snmp soap sockets spell spl sqlite ssl sysvipc threads tidy tokenizer truetype unicode xml xmlreader xmlrpc xmlwriter xsl zip zlib -adabas -apache -birdstep -cdb -concurrentmodphp -db2 -dbase -dbmaker -debug -discard-path -empress -empress-bcs -esoob -fastbuild -fdftk -filepro -firebird -flatfile -frontbase -gd -hardenedphp -hyperwave-api -informix -inifile -interbase -iodbc -java-external -kerberos -libedit -mcve -ming -msql -mssql -oci8 -oci8-instant-client -odbc -pdo -pic -qdbm -recode -sapdb -sharedmem -solid -sybase -sybase-ct -vm-goto -vm-switch -wddx -xpm -yaz" One of those patches has the same name as the one in portage tree, but it has been modified. One thing that bothers me is a lot of DT_TEXTRELOC's, should it be this way ? And those patches should be cleaned, cause I done it by instinct, as I have nearly no knowledge of m4 macros and libtool.
Created attachment 95716 [details, diff] Required patch. Oops, that comment about a patch in tree was about a different package. Well, I hope it helps somebody.
One correction: as those who looked into the ebuild may have noticed, it's an ebuild for dev-lang/php-5.1.6-r2, not php-4.
A little more input, the issue that bug reporter noticed and fixed with his patch, is solved in mine by the chunks for acinclude.m4, that part is essential and probably is an upstream bug with --as-needed, I'm not 100% sure if the other parts are necessary but they seem to look fine.
PHP4 is completely unmaintained upstream, use PHP5.
