FAQ
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

Search Discussions

  • Joe Orton at Feb 7, 2005 at 9:30 am
    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 at Feb 7, 2005 at 3:09 pm

    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 at Feb 7, 2005 at 4:18 pm

    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 at Feb 7, 2005 at 4:56 pm

    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




    joe

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jani Taskinen at Feb 10, 2005 at 12:52 pm

    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 at Feb 10, 2005 at 2:49 pm

    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 at Feb 10, 2005 at 4:23 pm

    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 at Feb 12, 2005 at 8:10 am

    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 at Feb 12, 2005 at 8:54 am

    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 at Feb 12, 2005 at 9:05 am

    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 at Feb 14, 2005 at 6:29 pm

    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
  • Joe Orton at Feb 15, 2005 at 2:47 pm

    On Mon, Feb 14, 2005 at 01:28:26PM -0500, Hans Zaunere wrote:
    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.
    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
  • Hans Zaunere at Feb 20, 2005 at 2:12 am

    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.
    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?
    http://daedal.nyphp.com/pub/
    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)
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 6, '05 at 12:04a
activeFeb 20, '05 at 2:12a
posts14
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase