making static linkage useful (oh the horror!)

Fri Jan 17 04:23:00 GMT 2003

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?".
>>
--