#19319 [NEW]: wrong -L path from configure results in incorrect c-client lib info

From: vlb@gene.com Operating system: Tru64 Unix (n/a) PHP version: 4.2.2 PHP Bug Type: *Configuration Issues Bug description: wrong -L path from configure results in incorrect c-client lib info My configure options: setenv LDFLAGS '-lclua -limc'; \ ./configure \ --with-mysql=/usr/local/mysql \ --with-imap=/usr/local/test \ --with-kerberos=/usr/local \ --with-ldap \ --enable-cli \ --with-gettext \ --enable-discard-path \ --prefix=/usr/local/test The LDFLAGS are required for ($&#&!) Tru64 Unix clusters Note that I have specified that IMAP functionality is under /usr/local/test; libc-client.a is installed in /usr/local/test/lib. When I run configure, it finds the c-client library and (correctly) sets #define HAVE_IMAP2001 1 in main/php_config.h BUT when I run make, the two stanzas that use -lc-client also have this order for searching libraries -L/usr/local/lib -L/usr/local/test/lib Unfortunately, there is an (old) libc-client.a in /usr/local/lib... it (may) be replaced when I am finished testing this build but until then it is required to stay in place. So, in summary, 1) I have configured --with-imap=/usr/local/test to specify the location of the c-client library 2) configure has inserted a (correct) #define that causes phpinfo() to claim the c-client library found in /usr/local/test 3)configure has also set up the -L options in the Makefiles so that a different (and incorrect) c-client library is found first and linked in. 4) The result is that So PHP is actually linked with a different c-client library than is claimed by phpinfo() Desired behaviour: 1) phpinfo should be smarter - Use something other than a #define set by configure to determine version of a library! For example, use one of the library's functions, or look for the existence of a function or a #define expected in a given version of the library. 2) Check locations specified in configure options before the "standard well-known places"... I admit that, depending on the circumstances, this is going to be difficult if not impossible, but desired behaviour #1 (above) should at least point out any problems :/ I realize that having multiple versions of a library installed is unusual behaviour and can readily cause problems. Believe me when I say I have tried diligently to convince my client to update the "installed" library in /usr/local/lib and I have failed to convince them to do so :-( However, if phpinfo had not inaccurately represented the version of the c-client library in use, I would have saves several days of debugging and hair-tearing. Sigh. -- Edit bug report at http://bugs.php.net/?id=19319&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19319&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19319&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19319&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19319&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19319&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19319&r=support Expected behavior: http://bugs.php.net/fix.php?id=19319&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19319&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19319&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19319&r=globals