Everything

php

AMD64 and libdir Broken?

php.internals

Hans Zaunere

21 years ago

Some time ago we talked about compiling PHP on an AMD64.  Joe Orton was kind enough to patch the 5.1 branch to include the --with-libdir directive to ./configure to allow for searching in libs in such places as /lib64 and /usr/lib64 and it worked great.

However, after downloading the php5-200502052330.tar.gz snapshot, things seem broken again.  My ./configure starts out like this:

./configure --with-libdir=lib64 --prefix=/usr/local/php --with-apxs=/usr/local/apache/bin/apxs

.....


Which had worked fine before.  However, when compiling this snapshot, I get the original errors during link time, such as:

*** Warning: linker path does not have real file for library -lxml2.
*** 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 libxml2 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libdl-2.3.3.so

Thus, libphp5.so isn't created.  Seems like Joe's patch was broken somehow or somehow changed.  Any news or ideas?  Many thanks,


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

Joe Orton

21 years ago

On Sat, Feb 05, 2005 at 07:03:52PM -0500, Hans Zaunere wrote:
...

> However, after downloading the php5-200502052330.tar.gz snapshot,
> things seem broken again.  My ./configure starts out like this:
>
> ./configure --with-libdir=lib64 --prefix=/usr/local/php --with-apxs=/usr/local/apache/bin/apxs
>
> .....
>
> Which had worked fine before.  However, when compiling this snapshot,
> I get the original errors during link time, such as:
>
> *** Warning: linker path does not have real file for library -lxml2.

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

Hans Zaunere

21 years ago

> > However, after downloading the php5-200502052330.tar.gz snapshot,
> > things seem broken again.  My ./configure starts out like this:
> >
> > ./configure --with-libdir=lib64 --prefix=/usr/local/php --with-
> apxs=/usr/local/apache/bin/apxs
> >
> > .....
> >
> > Which had worked fine before.  However, when compiling this snapshot,
> > I get the original errors during link time, such as:
> >
> > *** Warning: linker path does not have real file for library -lxml2.
>
> 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.

Yeah, but these types of message spew out for every lib - I just picked an example.

> 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

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.

> 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

I'll give this a shot and give feedback.

Thanks again,


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

Joe Orton

21 years ago

On Mon, Feb 07, 2005 at 10:09:29AM -0500, Hans Zaunere wrote:

>
> > > However, after downloading the php5-200502052330.tar.gz snapshot,
> > > things seem broken again.  My ./configure starts out like this:
> > >
> > > ./configure --with-libdir=lib64 --prefix=/usr/local/php --with-
> > apxs=/usr/local/apache/bin/apxs
> > >
> > > .....
> > >
> > > Which had worked fine before.  However, when compiling this snapshot,
> > > I get the original errors during link time, such as:
> > >
> > > *** Warning: linker path does not have real file for library -lxml2.
> >
> > 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.
>
> Yeah, but these types of message spew out for every lib - I just picked an example.

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

Hans Zaunere

21 years ago

> > > > However, after downloading the php5-200502052330.tar.gz snapshot,
> > > > things seem broken again.  My ./configure starts out like this:
> > > >
> > > > ./configure --with-libdir=lib64 --prefix=/usr/local/php --with-
> > > apxs=/usr/local/apache/bin/apxs
> > > >
> > > > .....
> > > >
> > > > Which had worked fine before.  However, when compiling this snapshot,
> > > > I get the original errors during link time, such as:
> > > >
> > > > *** Warning: linker path does not have real file for library -lxml2.
> > >
> > > 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.
> >
> > Yeah, but these types of message spew out for every lib - I just picked an
> example.
>
> Is that "Yeah", you *do* have both the .la and .so file in /usr/lib64,

Both files are present.

> just to confirm?  Could you upload the complete configure/make output
> somewhere so I can have a look?

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

Jani Taskinen

21 years ago

On Mon, 7 Feb 2005, Hans Zaunere wrote:

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

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

Hans Zaunere

21 years ago

> > 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 :)
>
>      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.

That makes sense, since no matter what version of libtool is installed in the system, the results are the same (it doesn't work :)

>      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..

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

Rasmus Lerdorf

21 years ago

Jani Taskinen wrote:

> On Mon, 7 Feb 2005, Hans Zaunere wrote:
>
>> 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 :)
>
>
>     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..

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

Lester Caine

21 years ago

Rasmus Lerdorf wrote:

> 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.

<snip>

> 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?

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?

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services

Rasmus Lerdorf

21 years ago

Lester Caine wrote:

> Rasmus Lerdorf wrote:
>
>> 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.
>
> <snip>
>
>> 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?
>
> So where are we on compiling PHP on AMD64 systems.

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

Lester Caine

21 years ago

Rasmus Lerdorf wrote:

> 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.

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

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services

Hans Zaunere

21 years ago

> >> 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.
> >
> > <snip>
> >
> >> 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?
> >
> > So where are we on compiling PHP on AMD64 systems.
>
> 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.

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.

[root@daedal INSTALLED]# rm -rf php5.1dev/

[root@daedal INSTALLED]# date
Mon Feb 14 13:13:54 EST 2005

[root@daedal INSTALLED]# cvs -d :pserver:cvsread@cvs.php.net:/repository checkout -d php5.1dev php-src

[root@daedal INSTALLED]# cd php5.1dev/

[root@daedal php5.1dev]# ./buildconf

[root@daedal 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

[root@daedal php5.1dev]# make

[root@daedal 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