Cristian Rodríguez wrote:
El lun 01 abr 2013 18:56:56 CLST, Cristian Rodríguez escribió:
El 01/04/13 18:23, Linda Walsh escribió:
Why do getgrgid geeetgrnam getpwnam and getpwuid not build static?
This is by design, it is intended that way.
You say this about every new SUSE bug. But my question was *WHY*, show me any rational supported (by open discussion, not by internet-meme pages) DESIGN docs that show a need for building it that way.
see http://www.akkadia.org/drepper/no_static_linking.html bullet points 4 and 5 but I suggest you to read the whole article.
Couple of issues, um besides that being a viral internet-meme that's way over-cited, considering the author is only talking about 1 case. You took it seriously? Show me a reliable source. Not some ranting page. Second, look at what he says: fixes (either security or only bug) have to be applied to only one place: the new DSO(s). If various applications are linked statically, all of them would have to be relinked. By the time the problem is discovered the sysadmin usually forgot which apps are built with the problematic library. I consider this alone (together with the next one) to be the killer arguments. ---- He says DSO's not SO's, DSO's implied dlload -- something I've been trying to get suse to use in a number of areas. Instead, suse is using **VERSIONED** SO's that have SUSe-only symbols in them so security fixed versions can't be just dropped in, we need to wait for you to come up with a special suse version. Try dropping in libperl.so bug fix versions 16.1-16.3 for 16.0 -- see how well that works on Suse. Suse. is doing what he is cautioning against by locking in exact versions that can't allow dynamic libs to be upgraded without upgrading the WHOLE APP --- the whole RPM, but wait, it's interlocked with 60 other RPM's... suddenly your primary reason for not using static libs goes out the window. I couldn't upgrade libc-15/16 to libc-17 ON SUSE, because suse put a special SUSE-only symbol in their glib that all the apps depend on. So much for that dynamic lib argument there. As for the rest.. Then he talks about security, efficietn use of mem, networked code, a whole bunch of things that assume you are not talking about *RECOVERY tools* -- You ALWAYS have to look at context. I agree with nearly all his points -- for an *UP and RUNNING* SYSTEM. For recovery, all his arguments are crap. As for those g -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org