FYI - Sascha
---------- Forwarded message ---------- Date: Tue, 04 Feb 2003 21:24:36 -0600 From: Robert Boehne <[EMAIL PROTECTED]> To: Lars Hecking <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: To sed or not to sed Lars, You're in luck! CVS Libtool goes to great pains to ensure that the sed used by it is the best one available. It also has piecewise linking support, most of this added by me for AutoOpenCascade @sourceforge. This doesn't solve the problem completely, it can't work around it if the only "sed" available truncates to 2401 character lines. It will however pick /usr/ccs/bin/sed over /bin/sed on Solaris for example, because it won't truncate as much. HTH, Robert Lars Hecking wrote: > > I came across something really annoying recently that I would not consider > a libtool bug, but I figured the folks here are most qualified to suggest > a solution. > > The problem is php 4.3.0. They have rearranged their build system "for > better portability", and stopped using convenience libraries for the > various subdirectory builds. The consequence is that all objects are > passed to libtool on the command line - which can be a very long list, > depending on which features one compiles into php. > > On Solaris 7/8, this list of objects is too long for the native sed, > and linking fails (some error messages about "line too long"). I reported > this as a bug and was told to use GNU sed instead. > > Am I the only one who things that software should be buildable with > native standard tools? > > The fix for me is to edit the libtool script included with php, and add > an explicit PATH which includes GNU tools first (I don't want this change > in my build environment, so I change it only where needed). And this needs > to be done every time I build php :-/ > > Generally requiring GNU sed in libtool does not work in the same way as e.g. > in autoconf, because the requirement would affect all users of libtool, not > only those who build and install it. A possible partial solution could be > that libtool has a section near the top where all standard tools it uses > are declared, e.g. > > Sed=/usr/bin/sed > > which would at least make it easier to identify and change such components. > > I guess it's probably not possible to get rid of sed completely (other than > replacing it with perl, which probably nobody wants). Any other ideas? > > _______________________________________________ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php