|Anonymous | Login | Signup for a new account||2018-08-16 04:16 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007716||OCaml||compiler driver||public||2018-01-30 18:39||2018-01-30 20:53|
|Target Version||Fixed in Version|
|Summary||0007716: Reverse ordering of .so arguments and "-dllib -l" options in ocamlc's command line|
|Description||The issue that I'm describing here concerns a corner case of the bytecode linking, I think, so it may not be considered actually as a bug, but I think some improvement would be welcome in this area.|
The context is that I'm trying to link a bytecode executable which uses C dynamic libraries (under Linux for now), and my build architecture involves moving ocaml library files after they are constructed, before linking. So, I use -noautolink to ignore the embedded path information and provide low-level linking options by hand. Furthermore, my ld.conf does not contain all the required paths either.
The order in which ocamlc puts shared libraries specified with -dllib or as anonymous arguments does not appear to be explicitly specified (I may be wrong) as well as the exact linking process, but by instrumenting the compiler I have observed the following features about the way ocamlc checks the linking consistency:
- all libraries specified as anonymous arguments (full path to a .so on the ocamlc command line) are checked before those specified with '-dllib', even if they appear after on the command line.
- libraries specified as anonymous arguments are checked in reverse order w.r.t. the command line
- same thing for libraries specified with '-dllib -l...'
- the search path used by the "C" part of the dll checking process (variable "caml_shared_libs_path" in dynlink.c) does not seem to be identical to the one in which the "OCaml" part search for libraries (Config.load_path, used in bytelink.ml). This means that libraries must be checked in the right order even if the appropriate -dllpath option is passed.
I'm not sure if the situation actually correspond to what was intended, but anyway I believe things could be improved in three ways:
- ensuring consistency between caml_shared_libs_path and the path used in bytelink.sml (Config.load_path) w.r.t. -dllpath in particular.
- maybe changing the "reverse order" behavior (though it may be an issue for compatibility)
- providing debug information, for example under the -verbose flag (I couldn't get the link command right until instrumenting the linker). Setting OCAMLPARAM to v=0x100 when calling ocamlc also helps, but it's not obvious to discover it.
|Steps To Reproduce||Here is a partial example. The command line is|
ocamlc [...] -noautolink [...] -dllib -lunix -dllib -lzarith -dllib -lbigarray -dllib -lgmp_caml [...] /absolute/path/to/libmpfr.so /absolute/path/to/libgmp.so [...]
The debugging (patch attached) prints:
and the link is successfull. If instead I put gmp before mpfr, it fails with:
File "_none_", line 1:
Error: Error on dynamically loaded library: /absolute/path/to/libmpfr.so: libgmp.so.3: cannot open shared object file: No such file or directory
|Tags||No tags attached.|
|Attached Files||bytelink.patch [^] (663 bytes) 2018-01-30 18:39 [Show Content]|
|2018-01-30 18:39||turpin||New Issue|
|2018-01-30 18:39||turpin||File Added: bytelink.patch|
|Copyright © 2000 - 2011 MantisBT Group|