Everything

php

RE: ./configure, PHP, SuSE and the AMD64

php.internals

Hans Zaunere

21 years ago

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

21 years ago

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 [mailto:hans@nyphp.com]
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

21 years ago

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

21 years ago

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

21 years ago

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

21 years ago

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

21 years ago

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 [mailto:derick@php.net]
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

21 years ago

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