[PHP-INTERNALS] AMD64 and libdir Broken?

On Sat, Feb 05, 2005 at 07:03:52PM -0500, Hans Zaunere wrote:
...
I think this should only happen with a broken libxml2 installation. Do
you have both /usr/lib64/libxml2.la and /usr/lib64/libxml2.so? The PHP
HEAD build works fine for me still.

The version of libtool bundled with PHP is very old and doesn't
correctly support x86_64 Linux (and no doubt many other platforms); you
could try a patch like below, not sure it'll make a difference though:

Index: build/libtool.m4
===================================================================
RCS file: /repository/php-src/build/libtool.m4,v
retrieving revision 1.1
diff -u -r1.1 libtool.m4
--- build/libtool.m4 19 Jan 2005 17:52:32 -0000 1.1
+++ build/libtool.m4 7 Feb 2005 09:28:04 -0000
@@ -3393,7 +3393,7 @@
# This must be Linux ELF.
linux-gnu*)
case $host_cpu in
- alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64*)
+ alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* | s390* | x86_64*)
lt_cv_deplibs_check_method=pass_all ;;
*)
# glibc up to 2.1.1 does not perform some relocations on ARM

Ahh, that's probably it - so snapshots from snaps.php.net won't work? Any way to change that on a permanent basis?

Which leads to another question, per the recent 5.1 discussion. It's important that 5.1 works, out of the box, on AMD64 or EMT_64 box. Meaning, including you patch, Joe, and versions of libtool that will work.
I'll give this a shot and give feedback.

Thanks again,


---
Hans Zaunere
President, Founder
New York PHP
http://www.nyphp.org

Is that "Yeah", you *do* have both the .la and .so file in /usr/lib64,
just to confirm? Could you upload the complete configure/make output
somewhere so I can have a look?

joe

http://daedal.nyphp.com/pub/

make.cvs.txt
cvs HEAD as of two days ago.

make.snap.txt
php5-200502052330.tar.gz from http://snaps.php.net


I had originally tried to build from cvs, however ran into these errors. I figured it was a libtool problem, and that I might as well use the snapshot so I don't need to do a ./buildconf (even though this process worked a few months ago).

I went with a snapshot because of the versions stated as required at http://www.php.net/anoncvs.php. The snapshot uses:

ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)

My system build environment (Fedora Core 2, updated) has the following:

ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)
autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.8.3

This had worked a few months ago, when we first started on this stuff.

So it seems that the libtool version required, won't work for x86_64, and more libtool/auto* voodoo :)

Thanks Joe,


---
Hans Zaunere
President, Founder
New York PHP
http://www.nyphp.org

I fixed our build system (someone might think I broke it though :) so that
we really use only and only the libtool version we've bundled.

I think we should bundle libtool 1.5.10 in HEAD, but there are some issues
I need to fix before that happens. One of them is the requirement for autoconf 2.5x..

--Jani

I'd be +1, as long as we can have a stable compile for x86_64 systems (/lib64 and all that). Currently HEAD still won't compile. It looks like the --with-libdir option that Joe added is overlooked by the current libtool (even in HEAD).



---
Hans Zaunere
President, Founder

New York PHP
http://www.nyphp.org

AMP Technology
Supporting Apache, MySQL and PHP

I am still quite skeptical of this bundled libtool idea. It is
currently broken even on mainstream systems such as Debian x86 where do
to the crappy packaging it is really important that people can build
their own. See http://lerdorf.com/php/libtool.txt for a ./buildconf &&
./configure run on a current 4.3.11-dev on a Debian x86 box. The last
thing I want to do is start debugging libtool, but here is line 4096
from the generated libtool which throws so many errors:

4091 for obj in $save_libobjs
4092 do
4093 eval test_cmds=\"$reload_cmds $objlist $last_robj\"
4094 if test "X$objlist" = X ||
4095 { len=`expr "X$test_cmds" : ".*"` &&
4096 test "$len" -le "$max_cmd_len"; }; then
4097 objlist="$objlist $obj"

And just before that it also had a problem with a $max_cmd_len related test:

4061 if test "X$skipped_export" != "X:" && len=`expr "X$test_cmds" :
".*"` &&
4062 test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1;
then
4063 :
4064 else

Looking through it I don't see where $max_cmd_len is set. In my
/usr/bin/libtool it has:

# What is the maximum length of a command?
max_cmd_len=32768

near the top. Our generated one doesn't have that, so it appears ours
is 0 which causes this chaos where it gets into some infinite loop where
it sits and creates stuff in .libs forever. I had to ^C out of it and
you can see the resulting files it creates in .libs in my output.

Simply doing a cp /usr/bin/libtool . and re-running make fixes it and
the resulting binary works fine.

This may be fixable, but aren't the chances better that the native
libtool will work on the native machine?

-Rasmus

So where are we on compiling PHP on AMD64 systems.
I'm running SUSE9.1, and have the database engine (Firebird) running
fine, Apache (yes 2) is up and running as SUSE don't ship Apache1 now,
but that just leaves me with PHP to get working.
Do I need the latest 5.1 or will I be able to convince 5.0 to build?

Works ok as far as I know. The above-mentioned problem turned out to be
an incompatibility between my own ltmain.sh I was using and the
m4-generated libtool. With a completely clean tree it does work.

-R

Ta. When I find a few extra hours ... ;)

Not if you only have 64bit libs installed, which is dangerous, since otherwise it doesn't give any warnings and you're not getting what you think you are.

[[email protected] INSTALLED]# rm -rf php5.1dev/

[[email protected] INSTALLED]# date
Mon Feb 14 13:13:54 EST 2005

[[email protected] INSTALLED]# cvs -d :pserver:[email protected]:/repository checkout -d php5.1dev php-src

[[email protected] INSTALLED]# cd php5.1dev/

[[email protected] php5.1dev]# ./buildconf

[[email protected] php5.1dev]# ./configure --with-libdir=lib64 --prefix=/usr/local/php --with-apxs=/usr/local/apache/bin/apxs --with-openssl --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-curl --enable-dio --enable-exif --enable-ftp --with-gd=/usr --with-jpeg-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr --with-freetype-dir=/usr --with-gettext --with-gmp --with-mcrypt --with-mhash --with-mysql=/usr --with-mysql-sock=/tmp/mysql.sock --with-mysqli=/usr/bin/mysql_config --enable-shmop --enable-soap --enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-wddx --with-xmlrpc --with-xsl

[[email protected] php5.1dev]# make

[[email protected] php5.1dev]# make install
Installing PHP SAPI module: apache
[activating module `php5' in /usr/local/apache/conf/httpd.conf]
cp libs/libphp5.so /usr/local/apache/libexec/libphp5.so
cp: cannot stat `libs/libphp5.so': No such file or directory
apxs:Break: Command failed with rc=1
make: *** [install-sapi] Error 1


make install fails because libphp5.so is never created due to errors like this:

*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libdl-2.3.3.so

These errors occur for every library.

This all worked in December's CVS HEAD right after Joe put the patch in.


---
Hans Zaunere
President, Founder

New York PHP
http://www.nyphp.org

AMP Technology
Supporting Apache, MySQL and PHP

You did have some "-L/usr/lib "'s sneak in from somewhere in the make
output you posted. Can you also upload the config.log produced?

But again, it shouldn't really matter and it works fine for me here on
RHEL3/RHEL4 x86_64 boxes (with the 32-bit compat libs installed)

joe

Yeah, but it had worked on my box before without any compat libs. It linked against the 64bit libs without a problem and worked great.

Hopefully it's just a little glitch after you made the patch. Thanks Joe for taking a look.


---
Hans Zaunere
President, Founder

New York PHP
http://www.nyphp.org

AMP Technology
Supporting Apache, MySQL and PHP