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

From: Date: Wed, 11 Sep 2002 16:40:06 +0000
Subject: #19319 [Opn]: wrong -L path from configure results in incorrect c-client lib info
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-19148@lists.php.net to get a copy of this message
 ID:               19319
 Updated by:       rasmus@php.net
 Reported By:      vlb@gene.com
 Status:           Open
 Bug Type:         *Configuration Issues
 Operating System: Tru64 Unix (n/a)
 PHP Version:      4.2.2
 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------

[2002-09-11 11:20:51] vlb@gene.com

They _aren't_ lumped into /usr/local... if they WERE PHP wouldn't
break.

A user has a reasonable expectation that if
   --with-foo=DIR
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-10 11:07:43] rasmus@php.net

"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-10 10:59:48] vlb@cfcl.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 
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 :(

------------------------------------------------------------------------

[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?
:-)

------------------------------------------------------------------------

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



Thread (12 messages)

« previous php.bugs (#19148) next »