2010/5/3 Lennart Sorensen <lsore...@csclub.uwaterloo.ca>: > On Mon, May 03, 2010 at 08:14:38AM +0300, Timo Teräs wrote: >> Yes, static linking would be more bullet proof. But either the user, or >> the package manager needs jump through hoops in this case. There needs to >> be the static versions compiled, they need to get installed, then finally >> replaced with dynamic versions, etc. > > Why would it need to be replaced with a dynamic version? Why could the > package manager not always be staticly linked and ust stay that way?
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) Yes for upgrade, I'll probably recommend do that with static version and maybe even tell people to manually replace /bin/busybox with /bin/busybox.static. Still i think beeing able to set ABI_VERSION is a good idea. >> I'm not saying everyone needs to use this. I'm not asking support for this. >> I'm not even recommending this for anyone. >> >> I only want to do it myself, because it solves my immediate problems >> with less work and more user friendly way than static linking. The package >> manager is there to handle the other issues. > > Well user friendly to who? Less work for who? It sounds like just > linking the package manager and related tools staticly solves everything. > Sounds like the least work of all. 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. -- Natanael Copa _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc