The current CVS is having trouble compiling on Solaris platforms (Solaris 8/SPARC for me) and from what I can tell, the problem is thanks to Sun's sed.
While the Solaris shell itself can handle an insane number of command line argument characters, the default Solaris sed truncates it's input down to 4,000 characters. This causes problems when it comes time to link everything together during the final stages of the make, as the command libtool receives can become quite long: /bin/ksh libtool --silent --mode=link gcc -export-dynamic -DPHP_ATOM_INC -I/setup/php/php4/include -I/setup/php/php4/main -I/setup/php/php4 -I/setup/php/php4/Zend -I/setup/php/php4/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/setup/php/php4/TSRM -g -O2 -L/usr/ucblib -R /usr/ucblib ext/ctype/ctype.lo ext/mbstring/mbfilter_ja.lo ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo... (more, more, more) main/internal_functions.lo -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lsocket -lsocket -lcrypt -ldl -o php Output line too long. Output line too long. Output line too long. gcc: ext/stan: No such file or directory make: *** [php] Error 1 # Sun's sed can't handle the input, but GNU sed can. After installing GNU sed and messing around with $PATH so GNU sed would be found before Sun's sed, the build works as expected. The above error was produced doing a plain, argument-less configure on Solaris 8 (SPARC) using autoconf 2.53 and a CVS checkout from Friday. It can also be reproduced if you configure with enough extensions -- anything that'll get the linking line above longer than 4000 characters. The problem may exist on other platforms, such as IRIX, where sed apparently has an input limit of just over 8,000 characters or so. Determining the best sed to use is a pain in the arse, as they're all a little different, but I'm thinking GNU sed should be a requirement on UNIX systems, since you're going to have to be using gcc anyways. There were apparently plans to put a macro in autoconf that would determine the best sed to use (prefering GNU sed above the others), but it appears it was dropped because of the distinct differences in seds from platform to platform. The macro is here: http://mail.gnu.org/pipermail/autoconf-patches/2002-January/008138.html Would it be overly difficult to perform this check during configure and use GNU sed over any system seds? (I have only a passing familiarity with the PHP build system, having mucked around in config.m4 a bit, but never really doing much with it beyond that.) J -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
