[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 ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
