Re: [PHP4BETA] Configuration problems with "kitchen sink" PHP installation From: R. P. Channing Rodgers, M.D. (rodgers <email protected>)
Date: 01/28/00

Joey,

Many thanks for taking the time to respond (your domain name is quite
appropriate!) -- your comments were most helpful, esp. and especially
for a guy lacking a colleague peering over his shoulder
that he can talk things through with. I hope you and others will
read on, discussion of the various configuration problems follows.
This collegial interaction is deeply appreciated!

> > Note that we use the depot shared software repository scheme for locally
> > installed software, explaining the paths you will observe below:
> >
>
> I have never heard of "the depot shared software repository
> scheme", therefore I have very little input to offer! :)

I hope you *will* hear of it eventually. The scheme was invented ~10
years back by folks at NIST, and presented at USENIX conference. We
have been working with the folks at the Univ. Texas Advanced Research
Laboratory to create a suite of perl tools to manage the system.
It provides a much more powerful and disciplined way of managing local
software than the old /usr/local convention, and complements the Sun
pkg and Linux RPM packaging systems quite nicely. We hope to be
releasing it all under the GNU banner some time this year...

> > FLAG: --with-zlib=/depot/package/zlib_1.1.3 \
> > RESULT:
> > checking for gzgets in -lz... no
> > configure: error: Zlib module requires zlib >= 1.0.9.
> > COMMENT:
>
> Is it possible there is a libz.* somewhere EARLIER in your path
> that is being seen? That would explain this...

Duh! -- yes, you got it -- thanks! In /depot/lib, an older version got
linked in from a PNG graphics package we installed previously. But
there remains a mystery -- why does the configure script not look in the
specified directory first??? This seems odd behavior to me, why have
to supply a path to the flag if it is going to be ignored???
 
> > FLAG: --with-aspell=/depot/package/aspell_.28.3 \
> > RESULT:
> > checking for ASPELL support... configure: error: Could not find
> > aspell-c.h in /depot/package/aspell_.28.3/include - please copy it
> > manually from the aspell sources to
> > /depot/package/aspell_.28.3/include
>
> It seems to me that when you followed the reccomendation, things
> worked, right? So what's the concern?

No, I did not express myself well. The default intrinsic behavior of
the aspell .28.3 package itself is to install the header files in
the directory <base_directory>/aspell/include, whereas the configuration
appears to be expecting them to appear in <base_directory>/include, so
I had to manually move everyting up one directory level. From Peter
Kovacs <php4-peter <email protected>> separate posting, it appears that PHP
may not work with versions later than about .26 anyway -- does anyone
know if there are plans to update to the latest versions?
 
> > FLAG:--with-mm=/site/subsys/www/mm_1.0.12 \
> > RESULT:
> > checking for mm support... configure: error: cannot find mm library
> > COMMENT:
> > I don't understand what is wrong: we do have a file
> > /site/subsys/www/mm_1.0.12/lib/libmm.la
>
> .la is not, to my knowledge, a valid library file? At least, it is
> not on my Solaris 2.6 (UltraSparc/5).

[wiping egg from face] -- yes, we had misinstalled the mm package.

> > FLAG: --with-imap=../imap_4.7a/c-client
> > RESULT:
> > checking for IMAP support... configure: error: could not find mail.h
> > in ../imap_4.7a/c-client/include !
> > COMMENT:
> > I used the Univ. of Wash. imap system. I find the two (identical)
> > files in the IMAP source directory, ../imap_4.7a:
> > ./src/c-client/mail.h
> > ./c-client/mail.h
> > whereas the configuration script appears to be expecting to find it
> > in a path ending with "/include"
> >
>
> Do not pass the location of the imap source...it is looking for
> the installed version, in /usr/local/include, or equiv.

Thanks -- this is an important point that is not made clearly in the
PHP installation documents -- that arguments to the flags are generally
the installed and not the source directories. However, in the case of
IMAP, this still does not solve the installation problem. The Univ. of
Washington IMAP package Makefile does not have an install target!
The instructions are concerned only with installing the 3 imap binaries
it creates, which you end up doing manually. There are no lib or
include directories discussed. If the PHP configuration is expecting
to find header files in hte IMAP installation tree, the PHP installation
documentation will have to specify which ones need to be installed and
where.
 
> > FLAG: --with-xml=shared,/site/subsys/www/expat_1.1 \
> > RESULT:
> > checking host system type... Configuration name missing.
> > Usage: ./config.sub CPU-MFR-OPSYS
> > or ./config.sub ALIAS
> > where ALIAS is a recognized configuration type.
> >
> > checking build system type... Configuration name missing.
> > Usage: ./config.sub CPU-MFR-OPSYS
> > or ./config.sub ALIAS
> > where ALIAS is a recognized configuration type.
> > COMMENT:
> > I have not got a CLUE as to what the problem is here, sorry! 8^)
> >
>
> Have to say, I've never seen =shared, passed before...no clue!

I'll experiment with rebuilding without the shared argument being
present, and see what happens.

Many Thanks, Rick Rodgers 

-- 
PHP 4.0 Beta Mailing List <http://www.php.net/version4/>
To unsubscribe, e-mail: php4beta-unsubscribe <email protected>
For additional commands, e-mail: php4beta-help <email protected>
To contact the list administrators, e-mail: php4beta-admin <email protected>