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
