> I've committed the core changes to add --with-libdir and updated most of > the extensions which I could test here. > > Hans, can you test out HEAD on your SLES box? You should just use > --with-libdir=lib64 and then e.g. --with-mysql=/usr will correctly pick > up the system MySQL libraries in /usr/lib64. *Don't* pass /usr/lib64 > directly in any --with-foo= parameters, that won't work. Let me know if > there are any remaining problems.
Things look to work in the latest CVS checkouts (2004-12-12) of both php4 and php5. I've typically been using this ./configure for testing: ./configure --prefix=/usr/local/php --with-apxs=/usr/local/apache/bin/apxs --with-openssl --with-zlib --with-bz2 A quick recap: -- released PHP versions (4.3.9 and 5.0.2) can't locate any libs not in /lib or /usr/lib. For 64bit systems, which put 64bit versions of libraries in /lib64 and /usr/lib64, ./configure or compile breaks. -- the latest RCs of both 4.3.10 and 5.0.3 work properly, and will always use libs in /lib64 or /usr/lib64, and ./configure and compile work correctly. > To everyone else, the changes should make no difference if --with-libdir > isn't used but please shout at me if I broke something... One caveat, however, is that --with-libdir doesn't seem to have any effect. In both 4 and 5 CVS versions, supplying --with-libdir=lib64, --with-libdir=lib, or not specifying it all, have no effect. lib64 libraries are always used. While an academic problem (ie, why would I want to specify lib on a lib64 system), there doesn't seem to be any way to force the 32 bit libs on a 64bit system. Even if both 32bit and 64bit versions of a library exist on the system, the 64bit libs will always be used. A strange, unrelated problem. After a successful make, a make install fails for both 4 and 5 from CVS. The error: cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so cp: cannot stat `libs/libphp4.so': No such file or directory When I look at libs, the only file is libphp4. A rename of libphp4 to libphp4.so and then make install works. For PHP 5, this is of course libphp5. Any insight into this would be appreciated. Thanks Joe and everyone - this seems to get things working for both 4 and 5. I'm going to continue testing, and then document all of this for future generations, and will keep you in the loop if something else looks wrong. --- Hans Zaunere President, Founder New York PHP http://www.nyphp.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
