Comment author: administrator

From: checker@d6.com

It would be very useful to be able to specify additional -dllpath's to
the toplevel. The use case is 3rd party dlls not stored with the cma
that links to them, and not stored in the dllpath in the cma (because
it might change, or is system specific, etc.).

There is already an environment variable for that:
CAML_LD_LIBRARY_PATH

-dllpath has a different goal: it tells the ocaml linker to
hardwire extra paths in the executable. It doesn't even work with the
librarian: they won't be stored in .cmas. Since this option is only
used for bytecode, and bytecode should rather be architecture
independant, I now agree with Xavier when he said we should deprecate
it (or replace it with a CAML_LD_RUN_PATH variable).
Note that ocamlmklib also has a -dllpath option, which is only a
synonym to -rpath: had a path inside a stub dll, to access system
C libraries. This just adds to the confusion.

Actually your suggestion of -dllpath as an alternative to
CAML_LD_LIBRARY_PATH makes more sense than the current meaning(s).

Maybe more important than these problem would be adding versioning
support in ocamlmklib: this is already possible by explicitly
specifying the stub library name, but an explicit option would
encourage using version numbers to avoid conflicts.

Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp
JG

Comment author: administrator

We'd rather not complicate the DLL search path issue even more.