[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
To sed or not to sed
From: |
Lars Hecking |
Subject: |
To sed or not to sed |
Date: |
Tue, 4 Feb 2003 16:04:29 +0000 |
User-agent: |
Mutt/1.5.2i |
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?
- To sed or not to sed,
Lars Hecking <=