[Petr Baudis]
> Can't say anything about the C++ stuff, but the second user of shared
> libraries is going to be lxdialog - hopefully this evening already,
> in my patches (it already works, I'm only cleaning out few details
> now; lxdialog + mconf is also user of both these extensions).
What is so all-fired great about shared libraries anyway? It's not
like our burning need is to save memory when two people run 'make
menuconfig' in parallel. What's wrong with 'ar cq libxxx.a $(OBJS)'
anyway? It's fast, it's easy, it's portable, and you never have to
worry about things like LD_LIBRARY_PATH or `-rpath'.
Sure, with Linux you can create a shared library with 'gcc -shared' ...
but what about bootstrapping a Linux kernel from a legacy OS? (Yes,
people do compile Linux on Solaris, for example.) HOSTCC may or may
not be gcc, and if it is, it may or may not support creating shared
libraries, and if it does, you might need funky flags or variables to
denote the link-time or run-time search path. Why bother? `ar' is
basically universal, both in availability and usage. (Well, *almost*
universal usage: if you want to run 'ranlib', be prepared for it not to
exist.)
Basically, what I'm saying is, I see no need for the existing .so in
the kernel build, much less another one. Static libraries are ever so
much easier to manage.
Peter
-
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 Nov 07 2002 - 22:00:47 EST