Re: [PHP4BETA] Configuration problems with "kitchen sink" PHP installation

From: Date: Sat, 29 Jan 2000 02:19:39 +0000
Subject: Re: [PHP4BETA] Configuration problems with "kitchen sink" PHP installation
Groups: php.version4 
Request: Send a blank email to php-version4+get-9549@lists.php.net to get a copy of this message
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@knowpost.com> 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

« previous php.version4 (#9549) next »