Andre Poenitz wrote: > On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: >> Jean-Marc Lasgouttes wrote: >>> What's wrong with static linking? At least it goes away when the >>> application goes away. >> Completely infeasible on Windows. ... >> Many people have done >> back-of-the-envelope calculations to demonstrate this; I think I did >> some myself, in a post to alt.folklore.computers some time back. > > Some time back I was disputing the sheer possibility to catch a virus > using email. Still ... "environments" ... came up that made _not catching > one_ an art... So "things done a while back" do not count in IT.
That's one of the silliest generalizations I've seen in some time. People who ignore the history of IT are doomed to repeat it. Usually poorly. In this specific case, the situation has only gotten worse. However, I have no particular interest in demonstrating it. If you think static linking is feasible on Windows, go ahead and build LyX that way. > Mac OS X pretty much shows that _not_ sharing shared libraries on an > application level is a feasible approach to DLL hell. I wouldn't take anything Apple does as a model. I've used too many Apple products. And avoiding shared code in applications is a solution to "DLL hell" (which is a system administration problem, not an application architecture one) in the same way that walking is a solution to airplane safety. >> It's a lousy idea in any case, as anyone who remembers compiling all >> of BSD 4.2 to switch from local-files resolution to DNS remembers. >> Dynamic linking lets you fix the bug or add the feature in one place. > > So why go from libstdc++.so.5 to libstdc++.so.6 at all, if > incompatible changes can be, as you seem to say, avoided? Because there are many changes that *are* compatible? I'm not a libstdc++ maintainer, so I don't know offhand what the differences in those two releases are; and I'm not going to trawl through the release notes to find out. But it's very rare that a bug fix, or even a new feature, needs to alter an existing API, so there's no reason for it to introduce incompatibility. (Maintaining undefined behavior isn't a compatibility issue. Applications that rely on undefined behavior are broken.) >> Dynamic linking is a good thing. It's worked very well on a number of >> OSes. > > Examples? Most mainframe OSes - all of the MVS and VM family, for example. Also IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix variants, such as SVR4 and AIX. I believe dynamic linking in VMS wasn't bad, though I only ever looked at it briefly. Worked pretty well on OS/2. For that matter, it often works well on Windows, when DLL management is done properly. >> It would work on Windows if Microsoft could figure out 1) how to >> version properly, and 2) how to maintain backward compatibility. And >> it's not like those are unsolved problems. > > I am happy to have learned now that these problems are solved. They were solved decades ago. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
