making static linkage useful (oh the horror!)

Thu Jan 16 10:39:00 GMT 2003

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