To sed or not to sed

[Lars Hecking]

 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?