I am running SuSE Enterprise 9, and would like to upgrade my php to version 5; however, Novell only officially supports version 4 at this time (there are no Novell-made PHP5 binaries). So, I decided to compile it from source. Unfortunately, the configure script fails.

Before I go into detail as to how the configure script fails, I would like to know if people have, in fact, compiled PHP5 for the EMT64 architecture, and if so, how they went about doing it.

I've used the following to configure. I did have an rpm install working great from ftp.suse.com, but the rpms seemed to have vanished from their site, and as I needed to add some features, I decided to manually install anyway.

At the moment, I am not configuring GD, due to unrelated issues for me, but php5.0.3 is working fine. I did try a quick ./configure with this same setup for 5.1.1, and it is failing on an out of date libxml something.

This may help get you started, and if interested, I still have the original rpm set from my March 2005 install, which worked fine on my original sles9 install.

./configure --prefix=/usr \
--datadir=/usr/share/php5 \
--mandir=/usr/share/man \
--bindir=/usr/bin \
--libdir=/usr/lib64 \
--includedir=/usr/include \
--with-_lib=lib64 \
--sysconfdir=/etc/php5/apache2 \
--with-config-file-path=/etc/php5/apache2 \
--with-config-file-scan-dir=/etc/php5/conf.d \
--with-exec-dir=/usr/lib64/php5/bin \
--enable-bcmath=shared \
--enable-calendar=shared \
--enable-ctype=shared \
--enable-dba=shared \
--enable-dbase=shared \
--enable-dbx=shared \
--enable-dio=shared \
--enable-dom=shared \
--enable-exif=shared \
--enable-filepro=shared \
--enable-ftp=shared \
--enable-gd-native-ttf=shared \
--enable-gd-jis-conv=shared \
--enable-mbstring=shared \
--enable-mbregex \
--enable-pcntl=shared \
--enable-posix=shared \
--enable-shmop=shared \
--enable-ucd-snmp-hack=shared \
--enable-soap=shared \
--enable-sockets=shared \
--enable-sqlite-utf8 \
--enable-sysvmsg=shared \
--enable-sysvsem=shared \
--enable-sysvshm=shared \
--enable-tokenizer=shared \
--enable-wddx=shared \
--enable-yp=shared \
--enable-magic-quotes \
--enable-libxml \
--enable-session \
--with-pcre-regex \
--enable-xml \
--enable-simplexml \
--enable-spl \
--enable-safe-mode \
--enable-sigchild \
--disable-debug \
--enable-memory-limit \
--enable-inline-optimization \
--with-apxs2=/usr/sbin/apxs2 \
--with-zlib=shared \
--with-bz2=shared \
--with-gdbm=shared \
--with-db4=shared \
--with-cdb=shared \
--with-freetype-dir=yes \
--with-inifile=shared \
--with-flatfile=shared \
--with-gettext=shared \
--with-gmp=shared \
--with-iconv=shared \
--with-ncurses=shared \
--with-pear \
--with-ttf \
--with-readline=shared \
--with-mm=shared \
--with-xmlrpc=shared \
--with-xsl=shared \
--with-pgsql=/usr

You should stick with 32-bit programs instead of 64-bit programs because EMT64 is just a feature in Intel processors to convert 64-bit programs into 32-bit programs. The speed will be much faster if it is compiled for 32-bit for Pentium 4 processors instead of 64-bit. If you want 64-bit x86 processors, Opterons or Athlon64 are the only processors.

To compile, make sure all glibc and other programs that php depends on like their header files are installed. To compile any program you run ./configure && make && make install. You may need to run make depend before running make.

I currently have two sites in place; one is a production site, and I'm thinking it's dependent on php 4.x. The other is in beta, and is a replacement of the other. It uses a lot of object-oriented code, and would greatly benefit from php 5.x.

If I upgrade my php, will it break my old site? I'm not really familiar with the changes from 4 to 5. If there are a few function name changes, I can deal with that... but if there are major behavioral changes, then I'll have to wait until the new site replaces the old one.

Concerning EMT64... This machine flies... I've really been impressed with its performance, based upon the cost (which was pretty affordable). However, as I have learned more about EMT64, I wished we'd have gone with an AMD solution. The next 64-bit OS we get will definitely have an AMD in it, though.