[PATCH] fix mbregex for VPATH builds
Hi, mbregex breaks a VPATH build in the 4.3 branch currently, here is a fix: Index: ext/mbstring/config.m4 === RCS file: /repository/php-src/ext/mbstring/config.m4,v retrieving revision 1.28.2.4 diff -u -r1.28.2.4 config.m4 --- ext/mbstring/config.m4 26 Oct 2003 03:42:27 - 1.28.2.4 +++ ext/mbstring/config.m4 27 Oct 2003 11:47:40 - @@ -53,6 +53,7 @@ AC_DEFINE([HAVE_MBREGEX], 1, [whether to have multibyte regex support]) PHP_MBSTRING_ADD_INCLUDE([mbregex]) +PHP_MBSTRING_ADD_BUILD_DIR([mbregex]) PHP_MBSTRING_ADD_SOURCES([ php_mbregex.c
[PHP-DEV] CVS Account Request: jorton
Commit of autoconf code cleanups to php4 (4_3 branch) needed for systems which have system libraries in /usr/lib64 rather than /usr/lib. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: jorton
On Thu, Mar 13, 2003 at 04:18:51PM +0100, Sascha Schumann wrote: On Thu, 13 Mar 2003, Joe Orton wrote: Commit of autoconf code cleanups to php4 (4_3 branch) needed for systems which have system libraries in /usr/lib64 rather than /usr/lib. Please post patches. I have done, Sascha :) It was suggested privately that I apply direct. msgid [EMAIL PROTECTED] joe -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] fixes for /usr/lib64 systems
Hi, I've got a bunch of fixes for systems which have system libraries in /usr/lib64 rather than /usr/lib - these are needed for some upcoming 64-bit Linux ports. These fixes are based on patches from SuSE developers [EMAIL PROTECTED] [EMAIL PROTECTED]. Should I submit changes to ext/*/config.m4 in bulk or individually? Here's the first fix to prevent adding /usr/lib64 to LDFLAGS: Index: acinclude.m4 === RCS file: /repository/php4/acinclude.m4,v retrieving revision 1.218.2.8 diff -u -r1.218.2.8 acinclude.m4 --- acinclude.m424 Feb 2003 15:12:11 - 1.218.2.8 +++ acinclude.m46 Mar 2003 10:22:59 - @@ -177,7 +177,7 @@ unset ac_new_flags for i in [$]$1; do case [$]i in --L/usr/lib|-L/usr/lib/) ;; +-L/usr/lib|-L/usr/lib/|-L/usr/lib64|-L/usr/lib64/) ;; *) ac_new_flags=[$]ac_new_flags [$]i ;; esac done @@ -906,7 +906,9 @@ dnl add a library to linkpath/runpath dnl AC_DEFUN([PHP_ADD_LIBPATH],[ - if test $1 != /usr/lib; then + case x$1 in + x/usr/lib|x/usr/lib64) ;; + *) PHP_EXPAND_PATH($1, ai_p) ifelse([$2],,[ _PHP_ADD_LIBPATH_GLOBAL([$ai_p]) @@ -917,7 +919,7 @@ _PHP_ADD_LIBPATH_GLOBAL([$ai_p]) fi ]) - fi + esac ]) dnl -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fixes for /usr/lib64 systems
On Thu, Mar 06, 2003 at 07:27:05PM +0800, James Devenish wrote: In message [EMAIL PROTECTED] on Thu, Mar 06, 2003 at 10:25:14AM +, Joe Orton wrote: Hi, I've got a bunch of fixes for systems which have system libraries in /usr/lib64 rather than /usr/lib - these are needed for some upcoming 64-bit Linux ports. These fixes are based on patches from SuSE developers [EMAIL PROTECTED] [EMAIL PROTECTED]. Should I submit changes to ext/*/config.m4 in bulk or individually? Here's the first fix to prevent adding /usr/lib64 to LDFLAGS: [...] +-L/usr/lib|-L/usr/lib/|-L/usr/lib64|-L/usr/lib64/) ;; Of all the problems I've had using PHP on 64-bit platforms (e.g. bug #21973, which refers mainly to lib directory naming under commercial 64-bit environments), this was not one of them -- yay. So I am curious: - What is the purpose of having the mechanism to remove or not remove /usr/lib (and why not do the same for /lib and other vendor directories)? - Why do 64-bit Linux operating systems need the special hard-coded treatment? - Will the same be done for other operating systems? /usr/lib64 exists so that you can have 64-bit libraries installed alongside 32-bit libraries in /usr/lib - this is a precedent that comes from Sun or SGI or somewhere I believe. IRIX is the top Google hit for lib64 in any case. (In fact I think you can get /usr/lib32 as well for some IRIX/MIPS, since there are two different flavours of 32-bit ABI) Adding /usr/lib64 or /usr/lib to the library search path at minimum causes a re-ordering of the library search path, which means in some circumstances you pick up the wrong versions of libraries. e.g. if you have a libfoo in /usr/lib, but you want to compile against a different version you have installed in /home/jim/lib, you start with -L/home/jim/lib -lfoo. If the configure script then adds -L/usr/lib to LDFLAGS, you might end up with the system libfoo again, which is wrong. On a lib64 system, if you do have the 32-bit libraries installed in /usr/lib, but want to compile against the 64-bit libraries in /usr/lib64, adding /usr/lib to the library search path breaks everything horribly, since you pick up the 32-bit libc etc. Regards, joe -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fixes for /usr/lib64 systems
On Thu, Mar 06, 2003 at 08:06:57PM +0800, James Devenish wrote: In message [EMAIL PROTECTED] on Thu, Mar 06, 2003 at 11:52:15AM +, Joe Orton wrote: ... On a lib64 system, if you do have the 32-bit libraries installed in /usr/lib, but want to compile against the 64-bit libraries in /usr/lib64, adding /usr/lib to the library search path breaks everything horribly, since you pick up the 32-bit libc etc. Okay, so 64-bit Linux needs the path hack because it will try and use 32-bit binaries with its 64-bit ABI instead of recognising that the 32-bit binaries cannot be used and skipping over them? Is that what you're saying? Yes, that's why it is needed - though I'm surprised if this problem is unique to the linker used on Linux. (especially since GNU binutils isn't uniquely used on Linux :) I'm fairly sure I've had problems on IRIX before when the linker picks up libraries with a different ABI. Regards, joe -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
