> because you want avoid 10 times bigger binary? (alpine linux's > apk-tools is 90k dynamic and 900k static due to libcrypto for > hashing/signing)
So what? libcrypto obviously wasn't designed for embedded environments. In fact, it's probably the most bloated free crypto library around. If the Alpine Linux guys need a smaller static executable, they can use a smaller crypto library, that does not pull the whole plate of spaghetti plate, glibc-style, when you yank at a single noodle. Do not blame extra bloat on static linking. Blame it on people who can't design lean software. > Still i think beeing able to set ABI_VERSION is a good idea. > (...) > But the price is that extra bloat for libcrypto, libz and uclibc dupe > code in there. I do understand that some people are willing to pay > that price. No problem. Current git is good. Everyone is happy. Lets > move on. That's fine, as long as the support for ABI_VERSION does not impact code that does not use it. If statically linked code is somehow made less efficient by adding dynamic ABI_VERSION support, not everyone's happy. If the libc.so dynamic code is somehow made bigger by adding dynamic ABI_VERSION support and users don't need it, not everyone's happy. In embedded environments, RAM is expensive, but storage memory is getting cheaper by the second. Cellphones embed full web browsers with Java and Macromedia Flash support. In most cases, bigger binaries for a package management suite will be *a lot* less of a problem than dynamic library upgrading nightmares. Vendors of embedded products want the upgrade system to just work. If it means adding 32 MB of storage memory and eliminating all risk of failure, they will do it. Support for upgrading the library does not belong to the libc. It belongs to the upgrade system. The libc should just do its work; thinking outside of itself, going meta, is going the way of the glibc. Let package manager designers handle the upgrading of the libc. Package managers are where it's at. -- Laurent _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
