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

ID: 19319 Comment by: vlb@cfcl.com Reported By: vlb@gene.com Status: Bogus Bug Type: *Configuration Issues Operating System: Tru64 Unix (n/a) PHP Version: 4.2.2 New Comment: >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 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 :( Previous Comments: ------------------------------------------------------------------------ [2002-09-10 10:59:13] rasmus@php.net 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:58:04] vlb@gene.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 >used. 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 AM NOT GETTING THAT CONTROL 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 versions...you...have 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:52:57] vlb@gene.com Given that PH claims to support configure options of the form --with-foo=DIR 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 --with-foo=DIR 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:41:38] rasmus@php.net 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-09 18:43:04] vlb@gene.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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19319 -- Edit this bug report at http://bugs.php.net/?id=19319&edit=1