* Michael S. Gilbert: > thanks for the update on the situation. based on the link, upstream's > response is not entirely hostile. see: > > Feature 3- (dynamic code loading) is already available in bytecode > through the Dynlink API. I understand there's a demand for having it > in native-code as well, and that might be possible without too much > fuss, at least on selected operating systems. > > so, perhaps if the work is done for them, they would be willing to > accept the changes.
Note that dynamic linking in itself doesn't solve our problem. We also need a stable ABI across recompilations: we want to be able to recompile camlimages, and use that from an unchanged advi binary compiled to a different camlimages version. (Even without that, dynamic linking will reduce in disk and memory space savings, so it is not completely pointless.) This is not a Caml-specific problem, it is shared by practically all programming languages which support separate compilation, with the exception of C (due to its simple linking model) and Java (due to precise guidelines about binary compatibility). For example, for both C++ and Ada, you have to be very careful when you try to make ABI-preserving changes. With templatized C++ code, this is often impossible (and you've got a physical dependency on the template code anyway). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
