On 26-Nov-2008, at 9:48 AM, Izumi Tsutsui wrote:
BTW, NetBSD/sun2 doesn't have dynamic link (PIC) support (yet) and it still seems working with fully static linking environment (on TME).
The problem here is that while the linking might work, the resulting system still doesn't completely work. Getting to a single user shell is no test at all, obviously. Even a multi-user shell is no real test. See if you can build any significant chunk of pkgsrc and get fully working packages for a better test. The first thorny things that crop up are with i18n stuff and how the blind breakage of the CITRUS code on static-linked systems causes huge and unnecessary fallout.
But I won't blame even if it will be removed once fully static linking support becomes a showstopper against other more important enhancements.
I think that's a very poor attitude to have about this issue.The real problem here though is that the need for static linking doesn't really, and cannot ever really, stand in the way of any important enhancements, at least in terms of concrete program features(*). Dynamic linking really can only ever add operational features to a system. Some of hose operational features may, or may not, be important in a given environment. Other such operational features are only important in runtime environments where recompilation is out of the question and/or re-deployment and re- install of large parts of the runtime environment is not practical.
In other words any program feature can be added to a static linked system -- and in an much easier and better performing way than can be done with dynamic loading. Of course you pay in some small ways for additional storage requirements, but often the gains of static linking far out-weigh the costs, whereas from my point of view the extremely high costs of always doing dynamic runtime linking almost never pay off in operational gains, especially not in open-source systems. Even OSX has given up on some of the best potential operational benefits of dynamic linking, and they've had to invest in huge amounts of toolchain work to get around some of the worst overhead and costs of dynamic linking.
The current problem in NetBSD is that it seems to be slowly sliding into the situation where everything must be dynamically linked because the developers making use of dynamic loading (beyond the automatic basic use of runtime libraries) are not even paying attention to what they're doing -- they blindly make their code work for dynamic loading, assume that's the only way the universe can work, and go off leaving things broken for static linked environments. Some of them seem to be so far gone down this slippery slope that they don't even believe their code can be made to work in static linked environments, yet often the restructuring necessary is either trivial and/or makes everything far simpler and more robust. They lose out to a better understanding of how things really work due to their blindness. Though it's not so true in the basic NetBSD code base itself, this situation is even holds for use often enough for basic use of runtime libraries where programmers don't understand the dependencies between and contents of libraries and they end up relying on the runtime loader accidentally putting things together in a way that might work some of the time but when it breaks there'll be clue in the code as to why. Meanwhile a simple static link of the program will immediately reveal the conflicts and dependency problems causing the breakage. I see this all the time in X11 applications, over and over again the same mistakes are made because programmers haven't even tried to static-link their code.
It is good that NetBSD, especially as a source code distribution, fully supports dynamic runtime linking of system libraries as well as runtime loading of modules where user managed extensibility is important. I wouldn't want to see that support removed. I also don't actually believe the ability to create and run static linked programs will ever really disappear on NetBSD. However NetBSD already fails to behave and work properly if it is static linked, and even getting it to fully and properly static link itself requires some deep understanding of /usr/share/mk and all its innards, as well as even some changes to the build system too. Getting the build tools themselves to be static linked (which provides a very significant boost in build performance) also requires tweaks and fixes to the build infrastructure. I've recently carried forward many of my changes and fixes from 1.6 to 4.0 to create a successfully static linked native NetBSD system, and I've successfully integrated and tested patches to fix CITRUS in a static-only build. All this work was non-trivial. Fixing enough of PAM to work in a static-only build would be even more work, though arguably it would be easier to toss PAM out and import the BSD Auth stuff which is agnostic about dynamic linking and loading.
(*) there's probably some much better phrase to use here than "program features", but I can't think of it right now. I'm just trying to distinguish from "operational features", which is also probably not an ideal phrase to describe what I'm trying to talk about.
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>
Attachment:
PGP.sig
Description: This is a digitally signed message part