making static linkage useful (oh the horror!)

[Adam Megacz]

So you oppose static linkage altogether?

  - a

"Erik Poupaert" <erik.poupaert@chello.be> writes:
> >>>>> BTW, I also think it would be really cool if we could produce
> >>>>> statically linked binaries that would dlopen() libgcj.dll/libgcj.so
> >>>>> *if available* and use that library instead of the statically linked
> >>>>> classes.  This way even statically linked binaries could take
> >>>>> advantage of updates to libgcj when the user installs a new version.
> 
> Imagine the application has gone through an iteration of deployments and
> tests. It finally works like should. That actually means that there is "no
> advantage of updates" to take. The wanted and deterministic behaviour of the
> application has been fixed; and the application is just supposed to continue
> working as it works. By the way, the appropriate way to fix or update the
> application, is to go through a new iteration of deployments and tests.
> 
> Now some new application, independent from the first one gets deployed. It
> carries a new version of libgcj, that the first application will load
> automatically. There are now two possibilities. Either the first application
> keeps on working like before, or else its behaviour changes because of the
> new libgcj. This change in behaviour is not wanted (otherwise such change
> would have been effected through the iteration of deployments and tests).
> Further, the developer may not have installed this new version of libgcj on
> his machine. If the user complains about the changed behaviour, the
> developer will not necessarily be able to reproduce the new behaviour. He
> may not even know that some other application has installed the new libgcj;
> or exactly which new libgcj has been installed. And now we are in the middle
> of the dll hell: "it works on my machine, why doesn't it work on yours?".
> 
> 

--