Grokbase › Groups › PHP › php-internals › December 2004
FAQ

I've committed the core changes to add --with-libdir and updated most of
the extensions which I could test here.

Hans, can you test out HEAD on your SLES box? You should just use
--with-libdir=lib64 and then e.g. --with-mysql=/usr will correctly pick
up the system MySQL libraries in /usr/lib64. *Don't* pass /usr/lib64
directly in any --with-foo= parameters, that won't work. Let me know if
there are any remaining problems.
Things look to work in the latest CVS checkouts (2004-12-12) of both
php4 and php5. I've typically been using this ./configure for testing:

./configure --prefix=/usr/local/php
--with-apxs=/usr/local/apache/bin/apxs --with-openssl --with-zlib
--with-bz2

A quick recap:

-- released PHP versions (4.3.9 and 5.0.2) can't locate any libs not in
/lib or /usr/lib. For 64bit systems, which put 64bit versions of
libraries in /lib64 and /usr/lib64, ./configure or compile breaks.

-- the latest RCs of both 4.3.10 and 5.0.3 work properly, and will
always use libs in /lib64 or /usr/lib64, and ./configure and compile
work correctly.
To everyone else, the changes should make no difference if
--with-libdir
isn't used but please shout at me if I broke something...
One caveat, however, is that --with-libdir doesn't seem to have any
effect. In both 4 and 5 CVS versions, supplying --with-libdir=lib64,
--with-libdir=lib, or not specifying it all, have no effect. lib64
libraries are always used.

While an academic problem (ie, why would I want to specify lib on a
lib64 system), there doesn't seem to be any way to force the 32 bit libs
on a 64bit system. Even if both 32bit and 64bit versions of a library
exist on the system, the 64bit libs will always be used.

A strange, unrelated problem. After a successful make, a make install
fails for both 4 and 5 from CVS. The error:

cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so
cp: cannot stat `libs/libphp4.so': No such file or directory

When I look at libs, the only file is libphp4. A rename of libphp4 to
libphp4.so and then make install works. For PHP 5, this is of course
libphp5. Any insight into this would be appreciated.

Thanks Joe and everyone - this seems to get things working for both 4
and 5. I'm going to continue testing, and then document all of this for
future generations, and will keep you in the loop if something else
looks wrong.


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

Search Discussions

  • Jani Taskinen at Dec 12, 2004 at 9:57 pm ⇧

    On Sun, 12 Dec 2004, Hans Zaunere wrote:
    -- the latest RCs of both 4.3.10 and 5.0.3 work properly, and will
    always use libs in /lib64 or /usr/lib64, and ./configure and compile
    work correctly.
    Interesting to hear that 4.3.10 works as it hasn't been touched at all?
    (I might have missed some fix, but AFAICT, this was only fixed in PHP 5 :)

    --Jani
  • Hans Zaunere at Dec 12, 2004 at 10:48 pm ⇧

    -- the latest RCs of both 4.3.10 and 5.0.3 work properly, and will
    always use libs in /lib64 or /usr/lib64, and ./configure and compile
    work correctly.
    Interesting to hear that 4.3.10 works as it hasn't been touched at all?
    (I might have missed some fix, but AFAICT, this was only fixed in
    PHP 5 :)

    Yeah, but there's some caveats I'm discovering :)

    4.3.10 works *better* with lib64 and will compile with the basic
    extensions (where as 4.3.9 won't). However, --with-libdir isn't really
    included, and per my followup message, it seems that even in HEAD some
    extensions (noteably gd) aren't fully ported to using PHP_LIBDIR either.


    On a side note, compiling HEAD checked out as of just now is kicking out
    this compile error:

    /bin/sh /root/INSTALLED/php5/libtool --silent --preserve-dup-deps
    --mode=compile gcc -Iext/standard/ -I/root/INSTALLED/php5/ext/standard/
    -DPHP_ATOM_INC -I/root/INSTALLED/php5/include
    -I/root/INSTALLED/php5/main -I/root/INSTALLED/php5
    -I/root/INSTALLED/php5/Zend -I/usr/include/libxml2
    -I/usr/kerberos/include -I/usr/local/include -I/usr/include/mysql
    -I/root/INSTALLED/php5/TSRM -g -O2 -prefer-pic -c
    /root/INSTALLED/php5/ext/standard/streamsfuncs.c -o
    ext/standard/streamsfuncs.lo
    /root/INSTALLED/php5/ext/standard/streamsfuncs.c: In function
    `zif_stream_socket_pair':
    /root/INSTALLED/php5/ext/standard/streamsfuncs.c:61: error: too few
    arguments to function `php_socket_strerror'
    /root/INSTALLED/php5/ext/standard/streamsfuncs.c:70: warning: passing
    arg 2 of `add_next_index_zval' makes pointer from integer without a cast
    /root/INSTALLED/php5/ext/standard/streamsfuncs.c:71: warning: passing
    arg 2 of `add_next_index_zval' makes pointer from integer without a cast
    make: *** [ext/standard/streamsfuncs.lo] Error 1



    ---
    Hans Zaunere
    President, Founder
    New York PHP
    http://www.nyphp.org
  • Hans Zaunere at Dec 12, 2004 at 10:56 pm ⇧
    I've committed the core changes to add --with-libdir and updated
    most of
    the extensions which I could test here.

    Hans, can you test out HEAD on your SLES box? You should just use
    --with-libdir=lib64 and then e.g. --with-mysql=/usr will correctly
    pick
    up the system MySQL libraries in /usr/lib64. *Don't* pass
    /usr/lib64
    directly in any --with-foo= parameters, that won't work. Let me
    know if
    there are any remaining problems.
    Things look to work in the latest CVS checkouts (2004-12-12) of both
    php4 and php5. I've typically been using this ./configure for testing:
    ./configure --prefix=/usr/local/php
    --with-apxs=/usr/local/apache/bin/apxs --with-openssl --with-zlib
    --with-bz2

    A quick recap:

    -- released PHP versions (4.3.9 and 5.0.2) can't locate any libs not in
    /lib or /usr/lib. For 64bit systems, which put 64bit versions of
    libraries in /lib64 and /usr/lib64, ./configure or compile breaks.

    -- the latest RCs of both 4.3.10 and 5.0.3 work properly, and will
    always use libs in /lib64 or /usr/lib64, and ./configure and compile
    work correctly.
    To everyone else, the changes should make no difference if
    --with-libdir
    isn't used but please shout at me if I broke something...
    One caveat, however, is that --with-libdir doesn't seem to have any
    effect. In both 4 and 5 CVS versions, supplying --with-libdir=lib64,
    --with-libdir=lib, or not specifying it all, have no effect. lib64
    libraries are always used.

    While an academic problem (ie, why would I want to specify lib on a
    lib64 system), there doesn't seem to be any way to force the 32 bit libs
    on a 64bit system. Even if both 32bit and 64bit versions of a library
    exist on the system, the 64bit libs will always be used.

    A strange, unrelated problem. After a successful make, a make install
    fails for both 4 and 5 from CVS. The error:

    cp libs/libphp4.so /usr/local/apache/libexec/libphp4.so
    cp: cannot stat `libs/libphp4.so': No such file or directory

    When I look at libs, the only file is libphp4. A rename of libphp4 to
    libphp4.so and then make install works. For PHP 5, this is of course
    libphp5. Any insight into this would be appreciated.

    Thanks Joe and everyone - this seems to get things working for both 4
    and 5. I'm going to continue testing, and then document all of this for
    future generations, and will keep you in the loop if something else
    looks wrong.
    Some more interesting things that threw me off at first. While 4.3.10
    and 5.0.3 do handle lib64 much better than previous versions, and will
    compile with the basic extensions enabled on a lib64 only system, only
    HEAD really implements --with-libdir. These versions will break when
    more extensions are enabled.

    On HEAD, with-libdir has a significant effect with some of the
    extensions.

    However, with HEAD as of two minutes ago, it appears that the GD
    extension isn't fully aware of PHP_LIBDIR. The supporting jpeg, png,
    xpm, etc. libs are found correctly under /usr/lib64, but libgd itself
    isn't.

    Looking at ext/gd/config.m4, the trouble might be around the for loop on
    line 366 (there's no hint of PHP_LIBDIR). This results in the
    ./configure time error of:

    configure: error: Unable to find libgd.(a|so) anywhere under /usr

    Even though:

    # ldconfig -p | grep -i libgd
    libgd.so.2 (libc6,x86-64) => /usr/lib64/libgd.so.2
    libgd.so (libc6,x86-64) => /usr/lib64/libgd.so

    If I take the GD stuff out of ./configure, I then am using this:

    ./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-gettext \
    --with-gmp \
    --with-mcrypt \
    --with-mhash \
    --with-mysql=/usr \
    --with-mysqli=/usr/bin/mysql_config \
    --enable-shmop \
    --enable-soap \
    --enable-sockets \
    --without-sqlite \
    --enable-sysvmsg \
    --enable-sysvsem \
    --enable-sysvshm \
    --enable-wddx \
    --with-xmlrpc \
    --with-xsl


    Which works great, and looks like it wants to compile; except for the
    seemingly unrelated bug in HEAD that I noted in my previous post.

    Thanks,


    ---
    Hans Zaunere
    President, Founder
    New York PHP
    http://www.nyphp.org
  • Joe Orton at Dec 13, 2004 at 10:34 am ⇧

    On Sun, Dec 12, 2004 at 02:56:25PM -0800, Hans Zaunere wrote:
    Some more interesting things that threw me off at first. While 4.3.10
    and 5.0.3 do handle lib64 much better than previous versions, and will
    compile with the basic extensions enabled on a lib64 only system, only
    HEAD really implements --with-libdir. These versions will break when
    more extensions are enabled.
    4.3.10 and 5.0.3 don't have any lib64-type fixes in AFAIK - they should
    work no better or worse than previous versions: i.e. it should be OK
    until you start enabling any of the extensions which require libraries
    out of /usr/lib{,64}.
    On HEAD, with-libdir has a significant effect with some of the
    extensions.

    However, with HEAD as of two minutes ago, it appears that the GD
    extension isn't fully aware of PHP_LIBDIR. The supporting jpeg, png,
    xpm, etc. libs are found correctly under /usr/lib64, but libgd itself
    isn't.

    Looking at ext/gd/config.m4, the trouble might be around the for loop on
    line 366 (there's no hint of PHP_LIBDIR). This results in the
    ./configure time error of:

    configure: error: Unable to find libgd.(a|so) anywhere under /usr
    OK, I've just fixed that. Thanks for testing this stuff out!

    Regards,

    joe
  • Hans Zaunere at Dec 18, 2004 at 12:59 am ⇧
    Some more interesting things that threw me off at first. While
    4.3.10
    and 5.0.3 do handle lib64 much better than previous versions, and
    will
    compile with the basic extensions enabled on a lib64 only system,
    only
    HEAD really implements --with-libdir. These versions will break
    when
    more extensions are enabled.
    4.3.10 and 5.0.3 don't have any lib64-type fixes in AFAIK - they should
    work no better or worse than previous versions: i.e. it should be OK
    until you start enabling any of the extensions which require libraries
    out of /usr/lib{,64}.
    At the end of the day, 4.3.10 and 5.0.3 don't work, but they do seem
    "smarter" in some ways. For instance, for openssl, zlib, and bz2 they
    seem to detect the lib64 libraries without a problem. But, you're
    exactly right, the other extensions break.
    On HEAD, with-libdir has a significant effect with some of the
    extensions.

    However, with HEAD as of two minutes ago, it appears that the GD
    extension isn't fully aware of PHP_LIBDIR. The supporting jpeg,
    png,
    xpm, etc. libs are found correctly under /usr/lib64, but libgd
    itself
    isn't.

    Looking at ext/gd/config.m4, the trouble might be around the for
    loop on
    line 366 (there's no hint of PHP_LIBDIR). This results in the
    ./configure time error of:

    configure: error: Unable to find libgd.(a|so) anywhere under /usr
    OK, I've just fixed that. Thanks for testing this stuff out!
    That did it - HEAD from CVS works great, as does the GD extension now.
    Thanks much Joe - this is a critical step in getting PHP to work on
    these newer platforms.

    Any chance your changes could be back ported into 4 and 5 branches? I
    know I probably should have mentioned this before their release :)

    Thanks again,


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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedDec 12, '04 at 7:13p
activeDec 18, '04 at 12:59a
posts6
users3
websitephp.net

3 users in discussion

Hans Zaunere: 4 posts Joe Orton: 1 post Jani Taskinen: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase