FAQ
I'm doing a PHP compile for New York PHP's AMD64 Project. The goal is
to enable all the hottest and modern extensions, and then let people
hack with their favorite extensions to find problems and bugs under a
64bit architecture. We're running SuSE Enterprise 9.1 on a dual AMD64
Opteron box, with 4GB of RAM.

I notice a number of strange issues while running ./configure. Most of
which I've been able to work through, and which I've documented to be
revisited later (the complete process of setting the box up is
documented and will be on nyphp.org when completed).

However, there is one issue I'm pretty unclear on - and, unfortunately
it might relate to some of the other issues, which makes matters more
confusion.

I can post the entire ./configure if requested, but this is pertinent at
this point:

....<snip>
--with-dom=/usr/lib64 --with-zlib-dir=/usr/lib64 \
--with-dom-xslt=/usr/lib64 --with-dom-exslt=/usr/lib64 \
--enable-exif --enable-ftp \
--with-gd=/usr/lib64 --with-jpeg-dir=/usr/lib64 \
--with-png-dir=/usr/lib64 --with-zlib-dir=/usr/lib64 \
--with-freetype-dir=/usr/lib64 \
....</snip>

The ./configure stops with this error message:

checking whether to enable truetype string function in GD... no
checking whether to enable JIS-mapped Japanese font support in GD... no
checking for jpeg_read_header in -ljpeg... no
configure: error: Problem with libjpeg.(a|so). Please check config.log
for more information.

And config.log contains this relevant snippet at the end:

configure:29794: checking whether to enable truetype string function in
GD
configure:29819: checking whether to enable JIS-mapped Japanese font
support in GD
configure:31813: checking for jpeg_read_header in -ljpeg
configure:31832: gcc -o conftest -g -O2 -Wl,-rpath,/usr/lib64
-L/usr/lib64 -Wl,-rpath,/usr/ssl/lib -L/usr/ssl/lib conftest.c -ljpeg
-lexslt -lxml -lxslt -lz -lcurl -lbz2 -lz -lresolv -lm -ldl -lnsl -lssl
-lcrypto -ldl -lcurl -lz -lssl -lcrypto -ldl -lxml2 -lz -lm 1>&5
usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux
/bin/ld: cannot find -lxml
collect2: ld returned 1 exit status
configure: failed program was:
#line 31821 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */

char jpeg_read_header();

int main() {
jpeg_read_header();
return 0;
}


At first glance, it appears the problem is in libjpeg - but it's not.
Notice "cannot find -lxml"

I have only libxml2 installed:

amd:~/INSTALLED/php-4.3.8 # ldconfig -p | grep -i libxml
libxml2.so.2 (libc6,x86-64) => /usr/lib64/libxml2.so.2
libxml2.so.2 (libc6) => /usr/lib/libxml2.so.2
libxml2.so (libc6,x86-64) => /usr/lib64/libxml2.so
amd:~/INSTALLED/php-4.3.8 #

So why is it looking for -lxml? I haven't been able to spot a --without
flag that does the trick, either. There is also the link flag of
-lxml2, which is correct. Am I missing something here, or do I really
need to install libxml in addition to libxml2 (which totally doesn't
seem right)?

So that's the main question right now.

There are some other issues that I've mostly worked around, but figure
I'll drop by this list for additional comments and thoughts. And, they
might add some complications to the issue above.

-- In general, I've found that PHP's ./configure tends to assume things
are in /usr/lib. However, on this and other 64bit x86 platforms, what
we want is typically in /usr/lib64. A prime example of this is libjpeg.

After the RPM's install, ./configure couldn't find libjpeg, even though
ldconfig knew where it was - it is in /usr/lib64. The error:

configure: error: libjpeg.(a|so) not found.

The solution: symlink libjpeg.so from /usr/lib64 into /usr/lib - but is
this right? I've tried numerous flags to configure, but nothing worked.
When examining config.log in this case, I see "gcc -o conftest
-L/usr/lib64...." which looks to be on the right track, yet ./configure
is still breaking.

-- On a similar note is the specifying of specific directories. In the
./configure snippet above, you'll notice I typically use /usr/lib64 with
any --with directive. I know this might be wrong, but using /usr
doesn't help either (for instance, --with-jpeg-dir=/usr doesn't work).

In fact, there appear to be some inconstancies, and certainly some
questions:

--with-openssl (must not have any directory after it, which isn't
inline with what ./configure --help says).

--with-zlib=/usr (this works - but what if I want to force the 64bit
library version, in /usr/lib64?)

--with-bz2=/usr/lib64 (and this also works - which you would think it
shouldn't, compared to the zlib above?)

And lastly, take these:

--with-curl=/usr/lib64
--with-zlib-dir=/usr/lib64

Both seem to work (so far). So what is the difference between a
directive having the -dir suffix and not?

For most compiles, I just set everything to /usr/local and /usr and it
works. Occasionally, there are problems, but they are usually easily
resolved with ldconfig runs, etc. However, in this case, having lib64
seems to have added another level of complexities and possible
permutations of what doing The Right Thing really is. Are these
potentially bugs and mis-documentations, or simply me missing the
obvious?

Any thoughts appreciated, thanks all,

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

Search Discussions

  • James Devenish at Sep 25, 2004 at 7:41 am
    In message <41EE526EC2D3C74286415780D3BA9F87046F7AFC@ehost011-1.exch011.intermedia.net>
    on Fri, Sep 24, 2004 at 07:21:45PM -0700, Hans Zaunere wrote:
    However, there is one issue I'm pretty unclear on - and, unfortunately
    it might relate to some of the other issues, which makes matters more
    confusion. [...]
    -- In general, I've found that PHP's ./configure tends to assume things
    are in /usr/lib. However, on this and other 64bit x86 platforms, what
    we want is typically in /usr/lib64. A prime example of this is libjpeg. [...]
    configure: error: libjpeg.(a|so) not found. [...]
    The solution: symlink libjpeg.so from /usr/lib64 into /usr/lib - but is
    this right? I've tried numerous flags to configure, but nothing worked.
    When examining config.log in this case, I see "gcc -o conftest
    -L/usr/lib64...." which looks to be on the right track, yet ./configure
    is still breaking.
    Yes, the PHP4 ./configure internals have been broken in this way for a
    number of years and bug reports have been filed accordingly. As you have
    noted, the compiler has no difficulty finding the libs but the configure
    script itself fails while performing its own (spurious) path search.
    This is an artificial failure and cannot be corrected with command-line
    options in the version you are using (4.3.8, by the looks of it). If
    this is the problem you are experiencing, then all you need to do is
    hack ./configure so that it ignores these "errors". For example, if
    ./configure fails on this:

    { echo "configure: error: libjpeg.(a|so) not found." 1>&2; exit 1; }

    then you can make PHP4 compile fully and correctly by changing it to
    this:

    { echo "configure: error: libjpeg.(a|so) not found." 1>&2; }
  • Rasmus Lerdorf at Sep 25, 2004 at 8:12 pm

    On Sat, 25 Sep 2004, James Devenish wrote:
    In message <41EE526EC2D3C74286415780D3BA9F87046F7AFC@ehost011-1.exch011.intermedia.net>
    on Fri, Sep 24, 2004 at 07:21:45PM -0700, Hans Zaunere wrote:
    However, there is one issue I'm pretty unclear on - and, unfortunately
    it might relate to some of the other issues, which makes matters more
    confusion. [...]
    -- In general, I've found that PHP's ./configure tends to assume things
    are in /usr/lib. However, on this and other 64bit x86 platforms, what
    we want is typically in /usr/lib64. A prime example of this is libjpeg. [...]
    configure: error: libjpeg.(a|so) not found. [...]
    The solution: symlink libjpeg.so from /usr/lib64 into /usr/lib - but is
    this right? I've tried numerous flags to configure, but nothing worked.
    When examining config.log in this case, I see "gcc -o conftest
    -L/usr/lib64...." which looks to be on the right track, yet ./configure
    is still breaking.
    Yes, the PHP4 ./configure internals have been broken in this way for a
    number of years and bug reports have been filed accordingly. As you have
    noted, the compiler has no difficulty finding the libs but the configure
    script itself fails while performing its own (spurious) path search.
    This is an artificial failure and cannot be corrected with command-line
    options in the version you are using (4.3.8, by the looks of it).
    Can't you just do:

    LDFLAGS=-L/usr/lib64 ./configure ...

    CPPFLAGS for compile-time stuff

    -Rasmus
  • James Devenish at Sep 26, 2004 at 6:43 am
    In message <Pine.LNX.4.58.0409251306510.13895@t42p.lerdorf.com>
    on Sat, Sep 25, 2004 at 01:12:15PM -0700, Rasmus Lerdorf wrote:
    Can't you just do:

    LDFLAGS=-L/usr/lib64 ./configure ...

    CPPFLAGS for compile-time stuff
    The compiler and linker have no problem. The problem is that the
    ./configure script does its *own* library path search, independently
    of the compiler and linker (why?) and it uses its own hard-coded paths.
    The compiler and linker have *no* problem finding the libraries, yet the
    ./configure attempts to pre-empt them and fails. Failure of ./configure
    does *not* indicate any compilation or linking problem in these cases.
    The failed tests have no bearing on the success or failure of PHP --
    ./configure doesn't even set any flags as a consequence of these tests.
    The practice has been on the increase in the ./configure system and
    appears to be used in both PHP 4.3.9 and 5.0.1. For example:

    % cd php-4.3.9; grep 'test -f.*/lib/lib' ./configure | wc -l
    42
    % cd ../php-5.0.1; grep 'test -f.*/lib/lib' ./configure | wc -l
    36
  • Hans Zaunere at Sep 25, 2004 at 7:30 pm
    However, there is one issue I'm pretty unclear on - and,
    unfortunately
    it might relate to some of the other issues, which makes matters
    more
    confusion. [...]
    -- In general, I've found that PHP's ./configure tends to assume
    things
    are in /usr/lib. However, on this and other 64bit x86 platforms,
    what
    we want is typically in /usr/lib64. A prime example of this is
    libjpeg.
    [...]
    configure: error: libjpeg.(a|so) not found. [...]
    The solution: symlink libjpeg.so from /usr/lib64 into /usr/lib - but
    is
    this right? I've tried numerous flags to configure, but nothing
    worked.
    When examining config.log in this case, I see "gcc -o conftest
    -L/usr/lib64...." which looks to be on the right track, yet
    ./configure
    is still breaking.
    Yes, the PHP4 ./configure internals have been broken in this way for a
    number of years and bug reports have been filed accordingly. As you have
    noted, the compiler has no difficulty finding the libs but the configure
    script itself fails while performing its own (spurious) path search.
    This is an artificial failure and cannot be corrected with
    command-line
    options in the version you are using (4.3.8, by the looks of it). If
    this is the problem you are experiencing, then all you need to do is
    hack ./configure so that it ignores these "errors". For example, if
    ./configure fails on this:

    { echo "configure: error: libjpeg.(a|so) not found." 1>&2; exit 1; }

    then you can make PHP4 compile fully and correctly by changing it to
    this:

    { echo "configure: error: libjpeg.(a|so) not found." 1>&2; }
    Thanks James. That's unfortunate about the configure script being
    broken. I do remember some issues years ago, but would have thought
    they were cleared up already.

    Getting around the libjpeg problem is doable, either by your method or
    by using a symlink, as I did. What I'm not able to figure out is how to
    eliminate the -lxml - is there a similar hack to the configure script
    that would cover this?

    Much appreciated,

    ---
    Hans Zaunere
    President
    New York PHP
    http://nyphp.org
  • Robert Silva at Sep 25, 2004 at 8:14 pm
    The root of your problem is that ext/domxml/config.m4 looks for libxml2
    specifically in $DOMXML_DIR/lib

    And if it doesn't find it there, then it defaults to using -lxml instead of
    -lxml2. Now where this breaks for you is that libxml doesn't exist, but
    libxml2 does.

    If you look at that config.m4 file, you will see tests around line 54 that
    are hardcoded to $DOMXML_DIR/lib

    Again, if you look at the Suse php config patch it will show you what you
    need to change to get it up and running.

    http://www.bobsilva.com/php-4.3.3-lib64.diff

    It's a big patch, but it does resolve the issues with php on a 64bit SuSE
    platform.

    Unfortunately the patch is for 4.3.3 so it is unlikely to work if applied to
    4.3.3
    Bob


    -----Original Message-----
    From: Hans Zaunere
    Sent: Saturday, September 25, 2004 12:31 PM
    To: James Devenish
    Cc: internals@lists.php.net
    Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64


    However, there is one issue I'm pretty unclear on - and,
    unfortunately
    it might relate to some of the other issues, which makes matters
    more
    confusion. [...]
    -- In general, I've found that PHP's ./configure tends to assume
    things
    are in /usr/lib. However, on this and other 64bit x86 platforms,
    what
    we want is typically in /usr/lib64. A prime example of this is
    libjpeg.
    [...]
    configure: error: libjpeg.(a|so) not found. [...]
    The solution: symlink libjpeg.so from /usr/lib64 into /usr/lib - but
    is
    this right? I've tried numerous flags to configure, but nothing
    worked.
    When examining config.log in this case, I see "gcc -o conftest
    -L/usr/lib64...." which looks to be on the right track, yet
    ./configure
    is still breaking.
    Yes, the PHP4 ./configure internals have been broken in this way for a
    number of years and bug reports have been filed accordingly. As you have
    noted, the compiler has no difficulty finding the libs but the configure
    script itself fails while performing its own (spurious) path search.
    This is an artificial failure and cannot be corrected with
    command-line
    options in the version you are using (4.3.8, by the looks of it). If
    this is the problem you are experiencing, then all you need to do is
    hack ./configure so that it ignores these "errors". For example, if
    ./configure fails on this:

    { echo "configure: error: libjpeg.(a|so) not found." 1>&2; exit 1; }

    then you can make PHP4 compile fully and correctly by changing it to
    this:

    { echo "configure: error: libjpeg.(a|so) not found." 1>&2; }
    Thanks James. That's unfortunate about the configure script being
    broken. I do remember some issues years ago, but would have thought
    they were cleared up already.

    Getting around the libjpeg problem is doable, either by your method or
    by using a symlink, as I did. What I'm not able to figure out is how to
    eliminate the -lxml - is there a similar hack to the configure script
    that would cover this?

    Much appreciated,

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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Sep 27, 2004 at 8:13 am

    On Sat, 25 Sep 2004, Robert Silva wrote:

    The root of your problem is that ext/domxml/config.m4 looks for libxml2
    specifically in $DOMXML_DIR/lib

    And if it doesn't find it there, then it defaults to using -lxml instead of
    -lxml2. Now where this breaks for you is that libxml doesn't exist, but
    libxml2 does.

    If you look at that config.m4 file, you will see tests around line 54 that
    are hardcoded to $DOMXML_DIR/lib

    Again, if you look at the Suse php config patch it will show you what you
    need to change to get it up and running.

    http://www.bobsilva.com/php-4.3.3-lib64.diff
    I think this patch is the way to go for this, but it won't address
    issues when you mix both 64bit and 32bit libraries as this one simply
    requires you to have everything in either 32bit or 64bit. So we can't
    really commit it.

    Derick
  • Joe Orton at Sep 27, 2004 at 4:10 pm

    On Mon, Sep 27, 2004 at 10:13:04AM +0200, Derick Rethans wrote:
    On Sat, 25 Sep 2004, Robert Silva wrote:
    Again, if you look at the Suse php config patch it will show you what you
    need to change to get it up and running.

    http://www.bobsilva.com/php-4.3.3-lib64.diff
    I think this patch is the way to go for this, but it won't address
    issues when you mix both 64bit and 32bit libraries as this one simply
    requires you to have everything in either 32bit or 64bit. So we can't
    really commit it.
    I don't know what you mean by that. You can't link both 32-bit or 64-bit
    libraries into one program, that doesn't work, of course.

    Fundamentally this approach is messy, but the alternative is to rewrite
    90% of ext/*/config*.m4 to not test for presence of libraries using
    "test -f".

    I have a patch based loosely on the SuSE patch which adds a
    --with-libdir flag, which defines PHP_LIBDIR and adjusts
    ext/*/config*.m4 to use that rather than assuming libraries are in
    /path/foo/lib/lib*.

    I've attached two patches: the first showing just the changes neeeded to
    configure.in and acinclude.m4, and the second including all the gory
    details to ext/*.

    Any objections to committing this to HEAD? Tested on RHEL3/x86_64 using
    --with-libdir=lib64 (where it builds rather than dying horribly), and on
    Fedora Core 3 test 2/i686 (where it still builds).

    joe
  • Derick Rethans at Sep 27, 2004 at 6:36 pm

    On Mon, 27 Sep 2004, Joe Orton wrote:
    On Mon, Sep 27, 2004 at 10:13:04AM +0200, Derick Rethans wrote:
    On Sat, 25 Sep 2004, Robert Silva wrote:
    Again, if you look at the Suse php config patch it will show you what you
    need to change to get it up and running.

    http://www.bobsilva.com/php-4.3.3-lib64.diff
    I think this patch is the way to go for this, but it won't address
    issues when you mix both 64bit and 32bit libraries as this one simply
    requires you to have everything in either 32bit or 64bit. So we can't
    really commit it.
    I don't know what you mean by that. You can't link both 32-bit or 64-bit
    libraries into one program, that doesn't work, of course.
    Ok, but having them in /lib and /lib32 at the same time does I guess.
    (though it still doesn't make sense to do so, and you can always symlink
    this).
    I have a patch based loosely on the SuSE patch which adds a
    --with-libdir flag, which defines PHP_LIBDIR and adjusts
    ext/*/config*.m4 to use that rather than assuming libraries are in
    /path/foo/lib/lib*.

    I've attached two patches: the first showing just the changes neeeded to
    configure.in and acinclude.m4, and the second including all the gory
    details to ext/*.

    Any objections to committing this to HEAD? Tested on RHEL3/x86_64 using
    --with-libdir=lib64 (where it builds rather than dying horribly), and on
    Fedora Core 3 test 2/i686 (where it still builds).
    It looks okay to me, but I'd like to hear some other comments too :)

    Derick
  • Joe Orton at Sep 27, 2004 at 7:49 pm

    On Mon, Sep 27, 2004 at 08:36:49PM +0200, Derick Rethans wrote:
    On Mon, 27 Sep 2004, Joe Orton wrote:
    On Mon, Sep 27, 2004 at 10:13:04AM +0200, Derick Rethans wrote:
    I think this patch is the way to go for this, but it won't address
    issues when you mix both 64bit and 32bit libraries as this one simply
    requires you to have everything in either 32bit or 64bit. So we can't
    really commit it.
    I don't know what you mean by that. You can't link both 32-bit or 64-bit
    libraries into one program, that doesn't work, of course.
    Ok, but having them in /lib and /lib32 at the same time does I guess.
    (though it still doesn't make sense to do so, and you can always symlink
    this).
    Sure, you could put your libraries in /bar and headers in /foo and this
    would confuse most of the library checks too. With an ideal configure
    script you could just export CPPFLAGS=-I/foo LDFLAGS=-L/bar, and that
    would work...

    joe
  • Robert Silva at Sep 27, 2004 at 4:16 pm
    The patch shown is what SuSE did for their RPM distribution of PHP.

    One solution may be with the --with-<module>= directive is to assume that
    dir may be an absolute path as well.

    --with-domxml=/usr/lib64

    for i in "" lib; do
    if test -f $DOMXML_DIR/$i/library.a -o -f $DOMXML_DIR/$i/library.so ...

    Instead of hardcoding to check a "lib" directory. As you can tell by the
    size of the patch suse made, there are a lot of areas where its assumed the
    library is located in a "lib" directory. While standard, I don't think it
    should be required.

    Actually, since most distributions have to make patches to work with their
    directory layout, maybe a more flexible solution is needed overall?

    Bob Silva


    -----Original Message-----
    From: Derick Rethans
    Sent: Monday, September 27, 2004 1:13 AM
    To: Robert Silva
    Cc: internals@lists.php.net
    Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
    On Sat, 25 Sep 2004, Robert Silva wrote:

    The root of your problem is that ext/domxml/config.m4 looks for libxml2
    specifically in $DOMXML_DIR/lib

    And if it doesn't find it there, then it defaults to using -lxml instead of
    -lxml2. Now where this breaks for you is that libxml doesn't exist, but
    libxml2 does.

    If you look at that config.m4 file, you will see tests around line 54 that
    are hardcoded to $DOMXML_DIR/lib

    Again, if you look at the Suse php config patch it will show you what you
    need to change to get it up and running.

    http://www.bobsilva.com/php-4.3.3-lib64.diff
    I think this patch is the way to go for this, but it won't address
    issues when you mix both 64bit and 32bit libraries as this one simply
    requires you to have everything in either 32bit or 64bit. So we can't
    really commit it.

    Derick

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Sep 27, 2004 at 6:37 pm

    On Mon, 27 Sep 2004, Robert Silva wrote:

    The patch shown is what SuSE did for their RPM distribution of PHP.

    One solution may be with the --with-<module>= directive is to assume that
    dir may be an absolute path as well.

    --with-domxml=/usr/lib64
    No, this is too different from what PHP always has been doing... thus a
    bad idea.

    Derick
  • Hans Zaunere at Oct 13, 2004 at 1:25 am

    The patch shown is what SuSE did for their RPM distribution of PHP.

    One solution may be with the --with-<module>= directive is to assume
    that
    dir may be an absolute path as well.

    --with-domxml=/usr/lib64
    No, this is too different from what PHP always has been doing... thus a
    bad idea.
    Out of curiosity, what has PHP been doing? I always see people specify
    a full directory, which typically works. As I mentioned in my original
    post, --with-module and --with-module-dir seem to have some
    inconsistencies themselves as well. What is the behavior?

    Going back to 64bit platforms, this is going to be a problem moving
    forward. AMD64 is all over the place, and thus having lib and lib64
    directories. While a SuSE patch works for SuSE, what about other AMD64
    distros? What happens on FreeBSD? Can PHP's ./configure be fixed to be
    flexible, as a ./configure script should be, or will platform specific
    hacks need to be made (which seems counter-intuitive, since that's what
    ./configure is for).

    H
  • Derick Rethans at Oct 13, 2004 at 7:14 am
    On Tue, 12 Oct 2004, Hans Zaunere wrote:
    The patch shown is what SuSE did for their RPM distribution of PHP.

    One solution may be with the --with-<module>= directive is to assume
    that
    dir may be an absolute path as well.

    --with-domxml=/usr/lib64
    No, this is too different from what PHP always has been doing... thus a
    bad idea.
    Out of curiosity, what has PHP been doing? I always see people specify
    a full directory, which typically works.
    That's a co-incidence then, as this:
    --with-domxml=/usr/lib
    is NOT working as you might think. You always need to do:
    --with-domxml=/usr
    as the php checks add /lib for you.
    As I mentioned in my original post, --with-module and
    --with-module-dir seem to have some inconsistencies themselves as
    well. What is the behavior?
    Where are the inconsistencies, can you point those out?
    Going back to 64bit platforms, this is going to be a problem moving
    forward. AMD64 is all over the place, and thus having lib and lib64
    directories. While a SuSE patch works for SuSE, what about other AMD64
    distros? What happens on FreeBSD? Can PHP's ./configure be fixed to be
    flexible, as a ./configure script should be, or will platform specific
    hacks need to be made (which seems counter-intuitive, since that's what
    ./configure is for).
    PHP's ./configure needs to be fixed of course, though for now the
    suggested patches are a bit suboptimal iirc. I would like to give it a
    shot, but I'll need to have access to a linux running on 64bit first :)

    Derick
  • Sascha Schumann at Oct 13, 2004 at 7:55 am

    Going back to 64bit platforms, this is going to be a problem moving
    forward. AMD64 is all over the place, and thus having lib and lib64
    That is hardly a new issue. Irix and other systems have had
    different lib directories for many years. The users of those
    systems always coped with the directory layouts the system
    providers imposed upon them. I am sure the same will work
    for users of the AMD64 platform.
    directories. While a SuSE patch works for SuSE, what about other AMD64
    distros? What happens on FreeBSD? Can PHP's ./configure be fixed to be
    FreeBSD amd64 installs its libraries into /usr/lib, as any
    sane OS does.

    - Sascha
  • Joerg Behrens at Oct 13, 2004 at 8:42 am

    Going back to 64bit platforms, this is going to be a problem moving
    forward. AMD64 is all over the place, and thus having lib and lib64
    That is hardly a new issue. Irix and other systems have had
    different lib directories for many years. The users of those
    systems always coped with the directory layouts the system
    providers imposed upon them. I am sure the same will work
    for users of the AMD64 platform.
    There is a difference between IRIX and the others. IRIX supports up to 3 ABIs named
    o32, n32 and 64 at once.

    Befor someone starts asking.. n32 is the new 32bit ABI which is now used since serveral years. The
    directory named usr/lib for o32, usr/lib32 for n32 and at least usr/lib64. Official freeware
    software pakages for IRIX from their freeware.sgi.com page have all modification to match to this
    layout. For php they used a patched configure with a var called $ABILIB which is similar to the suse
    patch or so

    Take a look to
    http://freeware.sgi.com/source/php/patches
    directories. While a SuSE patch works for SuSE, what about other AMD64
    distros? What happens on FreeBSD? Can PHP's ./configure be fixed to be
    FreeBSD amd64 installs its libraries into /usr/lib, as any
    sane OS does.

    Our AMD64 boxes which are runing a 64bit gentoo-linux have a usr/lib64 .... but the dudes have also
    a /usr/lib which is a symlink to the lib64 directory. I cant believe that they have made any big
    changes to all of the configures.

    How does it looks to other OSs like Tru64 and Solaris?

    regards
    Joerg
  • Joe Orton at Oct 13, 2004 at 2:26 pm

    On Wed, Oct 13, 2004 at 09:55:15AM +0200, Sascha Schumann wrote:
    Going back to 64bit platforms, this is going to be a problem moving
    forward. AMD64 is all over the place, and thus having lib and lib64
    That is hardly a new issue. Irix and other systems have had
    different lib directories for many years. The users of those
    systems always coped with the directory layouts the system
    providers imposed upon them. I am sure the same will work
    for users of the AMD64 platform.
    IRIX and other systems don't ship with copies of MySQL, Postgres, cURL,
    Berkeley DB libraries, blah blah blah, which it's useful to be able to
    use from PHP.
    directories. While a SuSE patch works for SuSE, what about other AMD64
    distros? What happens on FreeBSD? Can PHP's ./configure be fixed to be
    FreeBSD amd64 installs its libraries into /usr/lib, as any
    sane OS does.
    So other than vague slurs on OS sanity, are there objections to
    committing my --with-libdir patch to HEAD?

    http://news.php.net/php.internals/13012

    joe
  • Sascha Schumann at Oct 13, 2004 at 3:12 pm

    On Wed, 13 Oct 2004, Joe Orton wrote:
    On Wed, Oct 13, 2004 at 09:55:15AM +0200, Sascha Schumann wrote:
    Going back to 64bit platforms, this is going to be a problem moving
    forward. AMD64 is all over the place, and thus having lib and lib64
    That is hardly a new issue. Irix and other systems have had
    different lib directories for many years. The users of those
    systems always coped with the directory layouts the system
    providers imposed upon them. I am sure the same will work
    for users of the AMD64 platform.
    IRIX and other systems don't ship with copies of MySQL, Postgres, cURL,
    Not true. Refer to Joerg's post for counterexamples.
    Berkeley DB libraries, blah blah blah, which it's useful to be able to
    use from PHP.
    directories. While a SuSE patch works for SuSE, what about other AMD64
    distros? What happens on FreeBSD? Can PHP's ./configure be fixed to be
    FreeBSD amd64 installs its libraries into /usr/lib, as any
    sane OS does.
    So other than vague slurs on OS sanity, are there objections to
    committing my --with-libdir patch to HEAD?
    I will look at it later.

    - Sascha
  • Joe Orton at Oct 21, 2004 at 9:42 am

    On Wed, Oct 13, 2004 at 05:12:22PM +0200, Sascha Schumann wrote:
    On Wed, 13 Oct 2004, Joe Orton wrote:
    So other than vague slurs on OS sanity, are there objections to
    committing my --with-libdir patch to HEAD?
    I will look at it later.
    Have you had a chance to look at it, Sascha?

    joe
  • Derick Rethans at Oct 13, 2004 at 3:24 pm

    On Wed, 13 Oct 2004, Joe Orton wrote:

    FreeBSD amd64 installs its libraries into /usr/lib, as any
    sane OS does.
    So other than vague slurs on OS sanity,
    Hey, even Debian sid does it ;-)
    are there objections to
    committing my --with-libdir patch to HEAD?

    http://news.php.net/php.internals/13012
    No objections from me, though this will not fix extensions in PECL or
    other third party exts.

    Derick
  • Sebastian Bergmann at Oct 13, 2004 at 7:29 am

    Hans Zaunere wrote:
    I notice a number of strange issues while running ./configure.
    For what it's worth: I never experienced any of the problems you
    describe with PHP (PHP_4_3, PHP_5_0, HEAD) on my AMD64 box which runs on
    Gentoo Linux (~amd64).

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Hans Zaunere at Oct 13, 2004 at 5:06 pm
    The patch shown is what SuSE did for their RPM distribution of
    PHP.
    One solution may be with the --with-<module>= directive is to
    assume that
    dir may be an absolute path as well.

    --with-domxml=/usr/lib64
    No, this is too different from what PHP always has been doing...
    thus a
    bad idea.
    Out of curiosity, what has PHP been doing? I always see people
    specify
    a full directory, which typically works.
    That's a co-incidence then, as this:
    --with-domxml=/usr/lib
    is NOT working as you might think. You always need to do:
    --with-domxml=/usr
    as the php checks add /lib for you.
    Sorry for the confusion. Because the previous post mentioned absolute
    paths, above, I took it to mean with a leading slash. As you mention,
    /usr or /usr/local/mysql is the way to do it currently, but still there
    are some inconsistencies, per below.
    As I mentioned in my original post, --with-module and
    --with-module-dir seem to have some inconsistencies themselves as
    well. What is the behavior?
    Where are the inconsistencies, can you point those out?
    Here are some notes additions from my previous post.

    In fact, there appear to be some inconstancies, and certainly some
    questions:
    --with-openssl (must not have any directory after it,
    which isn't inline with what ./configure --help says).
    This just seems right-out broken...
    --with-zlib=/usr (this works - but what if I want to
    force the 64bit library version, in /usr/lib64?)
    This is seems to be related to this thread, specifically lib64.
    --with-bz2=/usr/lib64 (and this also works - which you
    would think it shouldn't, compared to the zlib above?)
    Just confusion... perhaps on my part, or inconsistencies in the way
    ./configure works.
    And lastly, take these:

    --with-curl=/usr/lib64
    --with-zlib-dir=/usr/lib64

    Both seem to work (so far). So what is the difference
    between a directive having the -dir suffix and not?
    Compare --with-zlib and --with-zlib-dir, per above. Things sometimes
    "work" (meaning there are no obvious errors) and sometimes not; so how
    should the two be used? What does the suffix -dir mean and how should
    it be used?
    Going back to 64bit platforms, this is going to be a problem moving
    forward. AMD64 is all over the place, and thus having lib and lib64
    directories. While a SuSE patch works for SuSE, what about other
    AMD64
    distros? What happens on FreeBSD? Can PHP's ./configure be fixed
    to be
    flexible, as a ./configure script should be, or will platform
    specific
    hacks need to be made (which seems counter-intuitive, since that's
    what
    ./configure is for).
    PHP's ./configure needs to be fixed of course, though for now the
    suggested patches are a bit suboptimal iirc. I would like to give it a
    Agreed. ./configure should 1) have defaults of lib's locations 2) use
    system linker variables and most importantly 3) allow specific
    directories to be specified during ./configure time.
    shot, but I'll need to have access to a linux running on 64bit first
    :)

    That's not a problem, see follow-up message.

    Thanks Derick,

    H
  • Derick Rethans at Oct 14, 2004 at 6:22 am

    On Wed, 13 Oct 2004, Hans Zaunere wrote:

    As I mentioned in my original post, --with-module and
    --with-module-dir seem to have some inconsistencies themselves as
    well. What is the behavior?
    Where are the inconsistencies, can you point those out?
    Here are some notes additions from my previous post.

    In fact, there appear to be some inconstancies, and certainly some
    questions:
    --with-openssl (must not have any directory after it,
    which isn't inline with what ./configure --help says).
    This just seems right-out broken...
    OpenSSL is a special beast, though I can't see so quickly where the
    message is generated.
    --with-zlib=/usr (this works - but what if I want to
    force the 64bit library version, in /usr/lib64?)
    This is seems to be related to this thread, specifically lib64.
    Yes, so it's not an inconsistency ;-)
    --with-bz2=/usr/lib64 (and this also works - which you
    would think it shouldn't, compared to the zlib above?)
    Just confusion... perhaps on my part, or inconsistencies in the way
    ./configure works.
    If it works it is because we fall back to the default dir after this, so
    it would fallback to /usr/lib and /usr/include.
    And lastly, take these:

    --with-curl=/usr/lib64
    See above.
    --with-zlib-dir=/usr/lib64

    Both seem to work (so far). So what is the difference
    between a directive having the -dir suffix and not?
    Compare --with-zlib and --with-zlib-dir, per above. Things sometimes
    "work" (meaning there are no obvious errors) and sometimes not; so how
    should the two be used? What does the suffix -dir mean and how should
    it be used?
    zlib-dir is odd indeed, it will override the dir from --with-zlib. No
    clue why :)
    Agreed. ./configure should 1) have defaults of lib's locations 2) use
    system linker variables and most importantly 3) allow specific
    directories to be specified during ./configure time.
    1, sure, we do that. Not sure what you mean by 2) and 3) i don't agree
    with as it is common to specify the install root dir which we've been
    doing for ages.
    shot, but I'll need to have access to a linux running on 64bit first
    :)

    That's not a problem, see follow-up message.
    It wasn't a problem, more people already offered an account while you
    were sleeping ;-)

    Derick
  • Robert Silva at Oct 14, 2004 at 7:37 am
    For #2, I believe he is referring to searching LD_LIBRARY_PATH directories
    for libraries rather than hardcoding /lib everywhere (which is how its done
    now).

    #3 would be something to effect of --with-libdir=lib64,lib

    Since just about every extension has custom code to check for the existance
    (and path) of include files and libraries, wouldn't it just be easier to
    create PHP_FIND_INCLUDE|LIBRARY macros to handle this functionality?
    Internally, it could use several mechanisms: LD_LIBRARY_PATH (not very
    common, none of my linux boxes define this by default), --with-libdir or
    just hardcoded paths for lib and lib64. It may not be standard, but it would
    certainly be a lot more flexible as well as a cleaner solution than what is
    in use currently.

    Bob Silva





    -----Original Message-----
    From: Derick Rethans
    Sent: Wednesday, October 13, 2004 11:22 PM
    To: Hans Zaunere
    Cc: internals@lists.php.net
    Subject: RE: [PHP-DEV] ./configure, PHP, SuSE and the AMD64
    On Wed, 13 Oct 2004, Hans Zaunere wrote:

    As I mentioned in my original post, --with-module and
    --with-module-dir seem to have some inconsistencies themselves as
    well. What is the behavior?
    Where are the inconsistencies, can you point those out?
    Here are some notes additions from my previous post.

    In fact, there appear to be some inconstancies, and certainly some
    questions:
    --with-openssl (must not have any directory after it,
    which isn't inline with what ./configure --help says).
    This just seems right-out broken...
    OpenSSL is a special beast, though I can't see so quickly where the
    message is generated.
    --with-zlib=/usr (this works - but what if I want to
    force the 64bit library version, in /usr/lib64?)
    This is seems to be related to this thread, specifically lib64.
    Yes, so it's not an inconsistency ;-)
    --with-bz2=/usr/lib64 (and this also works - which you
    would think it shouldn't, compared to the zlib above?)
    Just confusion... perhaps on my part, or inconsistencies in the way
    ./configure works.
    If it works it is because we fall back to the default dir after this, so
    it would fallback to /usr/lib and /usr/include.
    And lastly, take these:

    --with-curl=/usr/lib64
    See above.
    --with-zlib-dir=/usr/lib64

    Both seem to work (so far). So what is the difference
    between a directive having the -dir suffix and not?
    Compare --with-zlib and --with-zlib-dir, per above. Things sometimes
    "work" (meaning there are no obvious errors) and sometimes not; so how
    should the two be used? What does the suffix -dir mean and how should
    it be used?
    zlib-dir is odd indeed, it will override the dir from --with-zlib. No
    clue why :)
    Agreed. ./configure should 1) have defaults of lib's locations 2) use
    system linker variables and most importantly 3) allow specific
    directories to be specified during ./configure time.
    1, sure, we do that. Not sure what you mean by 2) and 3) i don't agree
    with as it is common to specify the install root dir which we've been
    doing for ages.
    shot, but I'll need to have access to a linux running on 64bit first
    :)

    That's not a problem, see follow-up message.
    It wasn't a problem, more people already offered an account while you
    were sleeping ;-)

    Derick

    --
    Derick Rethans
    http://derickrethans.nl | http://ez.no | http://xdebug.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Hans Zaunere at Oct 22, 2004 at 12:32 pm

    As I mentioned in my original post, --with-module and
    --with-module-dir seem to have some inconsistencies themselves
    as
    well. What is the behavior?
    Where are the inconsistencies, can you point those out?
    Here are some notes additions from my previous post.

    In fact, there appear to be some inconstancies, and certainly some
    questions:
    --with-openssl (must not have any directory after it,
    which isn't inline with what ./configure --help says).
    This just seems right-out broken...
    OpenSSL is a special beast, though I can't see so quickly where the
    message is generated.
    --with-zlib=/usr (this works - but what if I want to
    force the 64bit library version, in /usr/lib64?)
    This is seems to be related to this thread, specifically lib64.
    Yes, so it's not an inconsistency ;-)
    --with-bz2=/usr/lib64 (and this also works - which you
    would think it shouldn't, compared to the zlib above?)
    Just confusion... perhaps on my part, or inconsistencies in the way
    ./configure works.
    If it works it is because we fall back to the default dir after this, so
    it would fallback to /usr/lib and /usr/include.
    And lastly, take these:

    --with-curl=/usr/lib64
    See above.
    --with-zlib-dir=/usr/lib64

    Both seem to work (so far). So what is the difference
    between a directive having the -dir suffix and not?
    Compare --with-zlib and --with-zlib-dir, per above. Things
    sometimes
    "work" (meaning there are no obvious errors) and sometimes not; so
    how
    should the two be used? What does the suffix -dir mean and how
    should
    it be used?
    zlib-dir is odd indeed, it will override the dir from --with-zlib. No
    clue why :)
    Agreed. ./configure should 1) have defaults of lib's locations 2)
    use
    system linker variables and most importantly 3) allow specific
    directories to be specified during ./configure time.
    1, sure, we do that. Not sure what you mean by 2) and 3) i don't agree
    For #2, per Robert Silva's post:

    "For #2, I believe he is referring to searching LD_LIBRARY_PATH
    directories for libraries rather than hardcoding /lib everywhere (which
    is how its done now)."

    with as it is common to specify the install root dir which we've been
    doing for ages.
    Supplying the install root is fine, but as we've seen, it's not always
    right and doesn't work. For a lib that's installed into /usr/lib64,
    what's the install root?
    shot, but I'll need to have access to a linux running on 64bit
    first
    :)

    That's not a problem, see follow-up message.
    It wasn't a problem, more people already offered an account while you
    were sleeping ;-)
    Hehe, fair enough - let me know if you need another account (this has
    SuSE). How are things looking so far?

    Thanks Derick,

    H
  • Derick Rethans at Oct 22, 2004 at 12:36 pm

    On Fri, 22 Oct 2004, Hans Zaunere wrote:

    For #2, per Robert Silva's post:

    "For #2, I believe he is referring to searching LD_LIBRARY_PATH
    directories for libraries rather than hardcoding /lib everywhere (which
    is how its done now)."
    Unfortunately it's not that easy from what I remember.
    with as it is common to specify the install root dir which we've been
    doing for ages.
    Supplying the install root is fine, but as we've seen, it's not always
    right and doesn't work. For a lib that's installed into /usr/lib64,
    what's the install root?
    /usr of course.
    Hehe, fair enough - let me know if you need another account (this has
    SuSE). How are things looking so far?
    AFAIK Joe is going to commit his patch, but we need to "fix" it for the
    PECL extensions too if applicable.

    Derick
  • Joe Orton at Oct 22, 2004 at 3:19 pm

    On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
    AFAIK Joe is going to commit his patch, but we need to "fix" it for the
    PECL extensions too if applicable.
    I was kind of waiting for Sascha to review it... do you want me to
    commit it now? PECL extensions (or any autoconf code in general) are
    not necessarily broken on bi-arch platforms, it's only if they use a
    certain style of configure check which is prevalant in ext/*/config*.m4.

    Regards,

    joe
  • Derick Rethans at Oct 22, 2004 at 3:33 pm

    On Fri, 22 Oct 2004, Joe Orton wrote:
    On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
    AFAIK Joe is going to commit his patch, but we need to "fix" it for the
    PECL extensions too if applicable.
    I was kind of waiting for Sascha to review it... do you want me to
    commit it now? PECL extensions (or any autoconf code in general) are
    not necessarily broken on bi-arch platforms, it's only if they use a
    certain style of configure check which is prevalant in ext/*/config*.m4.
    They should all do that, if they use an external library so it would be
    great to mail pecl-dev with instructions on how to fix the exts for both
    PHP 4.3, PHP 5.0 and PHP 5.1 ;-)

    regards,
    Derick
  • Hans Zaunere at Oct 22, 2004 at 12:44 pm

    For #2, per Robert Silva's post:

    "For #2, I believe he is referring to searching LD_LIBRARY_PATH
    directories for libraries rather than hardcoding /lib everywhere
    (which
    is how its done now)."
    Unfortunately it's not that easy from what I remember.
    with as it is common to specify the install root dir which we've
    been
    doing for ages.
    Supplying the install root is fine, but as we've seen, it's not
    always
    right and doesn't work. For a lib that's installed into /usr/lib64,
    what's the install root?
    /usr of course.
    Right, but that's still wrong. Since lib is hardcoded, it'll be
    searching /usr/lib, which is not the place that's to be used. Thus,
    it's not always good enough to just allow the install root dir to be
    specified - sometimes, per my #3, a specific directory needs to be used.
    Hehe, fair enough - let me know if you need another account (this
    has
    SuSE). How are things looking so far?
    AFAIK Joe is going to commit his patch, but we need to "fix" it for the
    PECL extensions too if applicable.
    Ok, sounds good - I'm looking forward to getting this sucker compiled
    once and for all :)

    H
  • Hans Zaunere at Oct 31, 2004 at 9:20 pm

    On Fri, Oct 22, 2004 at 02:36:00PM +0200, Derick Rethans wrote:
    AFAIK Joe is going to commit his patch, but we need to "fix" it
    for the
    PECL extensions too if applicable.
    I was kind of waiting for Sascha to review it... do you want me to
    commit it now? PECL extensions (or any autoconf code in general)
    are
    not necessarily broken on bi-arch platforms, it's only if they use a
    certain style of configure check which is prevalant in
    ext/*/config*.m4.
    They should all do that, if they use an external library so it would be
    great to mail pecl-dev with instructions on how to fix the exts for both
    PHP 4.3, PHP 5.0 and PHP 5.1 ;-)
    Has anything been committed yet? I'd like to test some things out once
    it has...

    Regards,

    H
  • Joe Orton at Nov 1, 2004 at 10:22 am

    On Sun, Oct 31, 2004 at 01:18:49PM -0800, Hans Zaunere wrote:
    Has anything been committed yet? I'd like to test some things out once
    it has...
    No, sorry, not yet. Since it seems nobody has any objections I will
    commit the changes to HEAD later this week.

    joe
  • Joe Orton at Nov 3, 2004 at 2:40 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.

    To everyone else, the changes should make no difference if --with-libdir
    isn't used but please shout at me if I broke something...

    Regards,

    joe

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedSep 25, '04 at 2:21a
activeNov 3, '04 at 2:40p
posts32
users9
websitephp.net

People

Translate

site design / logo © 2022 Grokbase