[PATCH, RFC] no LIBADD for convenience libraries
asp16 at alu.ua.es
Fri Aug 19 20:16:35 BST 2005
* Stephan Kulow [Fri, 19 Aug 2005 11:32:11 +0200]:
> > (*) The libtool in Debian, that is; the pruning-dependency code is
> > not integrated upstream yet. I know now exists --enable-new-ldflags,
> > which tries to solve the extra dependencies problem using linker
> > features rather than libtool ones; but at least in Debian we won't
> > be enabling it for now, since this feature is broken in several
> > architectures. I hope this breakage gets fixed soon , but in the
> Several? None from the SUSE supported.
sparc, alpha and hppa, but there seems to be a fix coming (for this
> > meantime, I constantly dream about KDE's libtool gaining this
> > prunning support (hey, dreaming is easy), so if there's something I
> > could do to make progress in that direction, I'd be more than
> > willing to help (FWIW, I'll be in Málaga).
> KDE 3.5 is in feature freeze and KDE 4 won't have libtool in the current
> form I may hope. But of course you're free to add the support in debian's
Is there a chance of having a libtool with pruning support for KDE 4,
even if upstream does not integrate it in time? IOW, would you be
willing to accept a patch early in the KDE 4 development cycle?
The --as-needed feature is marked as experimental by upstream, or so I
am told, and although this will presumably change in the future, there
may be reasons that force some distribution not to use it, so it'd be
great to have a second method to remove spurious dependencies from
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
And don't get me wrong - I don't mind getting proven wrong. I change my
opinions the way some people change underwear. And I think that's ok.
-- Linus Torvalds
More information about the kde-core-devel