On 04/15/14 14:26, Chet Ramey wrote: > On 4/15/14, 5:00 AM, Michael Haubenwallner wrote: >> Is there a specific reason not to build readline with libtool, >> but maintain all the sharedlib platform details locally? > > libtool is large, slow, overly complicated, and introduces tremendous > overhead for even the simplest tasks.
Agreed. But there are platforms still in use where creating full-featured shared libraries is everything else but a simple task. And I do not expect readline itself to become libtoolize'd, but to allow for using an externally provided libtool script for (maybe site-specific) shared library creation. >> At the moment I'm preparing a patch to allow for using externally >> provided libtool as fallback, in case @SHARED_TARGET@ is empty >> because of --disable-shared or SHLIB_STATUS=unsupported. > > Is there some existing system for which this (unsupported) is an actual > problem? It's not the 'unsupported' part. For AIX I've found a non-trivial, but still manpage-following way to create shared libraries with full 'SONAME' support. It was fairly "easy" to implement this way within libtool, because of its already existing many-platforms/many-variants support "framework". What I'm tired of is reinventing the wheel for each home-brewed many-platform sharedlib support again and again. Instead, I'd love to see anyone to at least /allow/ outsourcing the shared library creation to libtool. Thanks! /haubi/ _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
