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

ID: 19319 User updated by: vlb@gene.com Reported By: vlb@gene.com -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Tru64 Unix (n/a) PHP Version: 4.2.2 New Comment: > Don't have many versions in there. Simple as that. Yes, well, this isn't an ideal world, is it? The upshot of this is that PHP's way of determining the version of c-client (as used by phpinfo()) is badly flawed. Configure sticks a #define into the code based on the .h files it finds in the specified imap=DIR directory. However, configure does NOT ensure that this is the directory from which the actual c-client.a library is later linked. Thus, the result is that phpinfo() can very possibly be completely wrong (believable, but wrong). If phpinfo cannot ensure that its informaton is correct, it should not be supplying information. Feel free to move this bug to phpinfo, but it's not bogus. The information sent from configire (#define HAVE_IMAP2001) is fragile, the c- client library used may or may not be the one that goes with the header files that were used, and phpinfo is spouting nonsense. Previous Comments: ------------------------------------------------------------------------ [2002-09-09 17:17:22] sniper@php.net Don't have many versions in there. Simple as that. And about the version stuff, feel free to complain to the author of the c-client. It sucks in many other ways too. (there are no functions in the library which tells the version..) ------------------------------------------------------------------------ [2002-09-09 13:20:25] vlb@gene.com 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 this bug report at http://bugs.php.net/?id=19319&edit=1