On Sun Aug 11, 2002 at 11:31:13AM -0400, Rob Landley wrote:
> Personally, I question the klibc work a bit because it's reinventing the
> wheel with projects like uclibc already mostly there. But Al pointed out the
> license issue with static linking against LGPL libraries, and in any case a
Keep in mind that you _can_ staticly link even closed source
stuff against an LGPL library... You just need to "Accompany the
work with a written offer, valid for at least three years" to
provide users with an object file that can be re-linked against
newer versions of the LGPL library. Or simply provide the .o
file. See the LGPL Section 6...
> to one side: I'm not fond of glibc and am looking to replace it in my own
> system, but it hasn't made it to the top of my to-do list yet. (Dietlibc is
> straight GPL: it can't even be the dynamic replacement for glibc in a real
> world linux distribution. HPA suggested I look at newlibc, which I've added
> to my to-do list).
As far as I know, uClibc is the only library that is able to
replace glibc for real world linux distributions... And I've
looked long and hard (which was why I ended up making uClibc),
-Erik
-- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:25 EST