Re: To sed or not to sed

[Robert Boehne]

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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool