|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19319 wrong -L path from configure results in incorrect c-client lib info
Submitted: 2002-09-09 13:20 UTC Modified: 2002-10-15 23:44 UTC
From: vlb at gene dot com Assigned:
Status: Not a bug Package: *Configuration Issues
PHP Version: 4.2.2 OS: Tru64 Unix (n/a)
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: vlb at gene dot com
New email:
PHP Version: OS:


 [2002-09-09 13:20 UTC] vlb at gene dot 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 \

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.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-09 17:17 UTC]
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 18:43 UTC] vlb at gene dot com
> 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.
 [2002-09-10 10:41 UTC]
There is no better way to do it without a version() type of function in c-client.  It's a best-guess and is usually right.  As with any other library, if you are going to have multiple versions, make sure none of them are on the standard LD path so you have full control over what gets used.  If you do have a version on your standard path, you can be pretty sure that it is the one that gets used no matter what.  That's just how stuff works.
 [2002-09-10 10:52 UTC] vlb at gene dot com
Given that PH claims to support configure options of the form
where DIR is the location into which foo and its components (e.g. .a or .h files) have been installed

THEN the user has a reasonable expectation that the components of foo (as fiund under DIR) will actually be used in compiling and linking the components of PHP.

If this is not possible, then PHP should not claim to have used the files from DIR.

> Don't have many versions in there. Simple as that.
The reason that ld has a specific search order, modifiable by the ordering of -Ldir flags is designed to handle just this situation. Systems with multiple copies (e.g. one in production, one in test) of libraries, headers, and binaries, are not unusual.

Either link in the libraries specified by 
one at a time to ensure that you get the correct one

or figure out a way to have phpinfo tell the truth

or document the bejeebers out of this.
 [2002-09-10 10:58 UTC] vlb at gene dot com
>As with any other library, if you are going to have 
>multiple versions, make sure none of them are on the
>standard LD path so you have full control over what gets

But that's exactly the point!  The librarys is _not_ in the 
standard path and I _exect_ full control. I specified the 
location in my  --with-imap=DIR configure option.


I'm not getting it because PHP is being linked with ALL 
libraries at once at that means there could be conflicts. 
In my case, the --with-kerberos=DIR location is overriding 
my --with-imap=DIR location.

As you point out ... "if you're going to have multiple full control".

Well, I expect full control and I'm not getting what I 
expect. That's rather the definition of a bug, isn't it?
 [2002-09-10 10:59 UTC]
The configure script does check one at a time, but on the final link we have to put all the -L entries in there.  You more than likely have other libraries that live in /usr/local/lib so they end up adding a -L/usr/local/lib to the link line.  This happens with every package I know of and is just the way stuff works.  
 [2002-09-10 10:59 UTC] vlb at cfcl dot com
>If you do have a version on your standard path, you can be 
pretty sure that it is the one that gets used no matter 

That's actually NOT true unless the one on the standard 
path is a .so and the "new" one (the one you want) is a .a.

Trust me; I've done a LOT of research into this lately :(
 [2002-09-10 11:07 UTC]
"Standard ld path" from my original statement also includes directories that you point configure at for other stuff.  If you want full control you need to put these libraries into their own directories and not lump them all into /usr/local/lib and expect PHP to sort out your mess.
 [2002-09-11 11:20 UTC] vlb at gene dot com
They _aren't_ lumped into /usr/local... if they WERE PHP wouldn't break.

A user has a reasonable expectation that if
is specified,, then DIR _will_ be used to find parts of foo.

Not used sometimes at PHP's whim and skipped over othertimes.

AND phpinfo is lying. Ether fix it or remove the incorrect information from the info screen.

People are _going_ to want to use test versions of libraries, etc that are in specified places other than the "standard" locations (or /usr/local/*). This is not a problem that is going to be specific to me.
 [2002-09-11 11:40 UTC]
But they are.  You have a libc-client in /usr/local/lib alongside other libraries you are linking PHP against.  You are trying to override the version in /usr/local/lib with your own in some test directory.  That's something that is very tricky for autoconf and friends to resolve.  We may have something in a future version, but don't hold your breath.  And you should realize that any autoconf-based package, which is just about everything these days, would have the exact same issue.  This is not a PHP-specific thing.
 [2002-10-15 23:44 UTC]
This really isn't any bug in PHP..complain to the GNU tools authors if you really think this is some bug.

PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Thu Sep 29 14:05:55 2022 UTC