Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007716OCamlcompiler driverpublic2018-01-30 18:392018-01-30 20:53
Reporterturpin 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformallOSallOS Versionall
Product Version4.06.0 
Target VersionFixed in Version 
Summary0007716: Reverse ordering of .so arguments and "-dllib -l" options in ocamlc's command line
DescriptionThe 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.

Best Regards
Tiphaine Turpin
MathWorks
Steps To ReproduceHere 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:

!Clflags.dllibs:
/absolute/path/to/libgmp.so
/absolute/path/to/libmpfr.so
-lgmp_caml
-lbigarray
-lzarith
-lunix

and the link is successfull. If instead I put gmp before mpfr, it fails with:

!Clflags.dllibs:
/absolute/path/to/libgmp/libmpfr.so
/absolute/path/to/libgmp/libgmp.so
-lgmp_caml
-lbigarray
-lzarith
-lunix
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
TagsNo tags attached.
Attached Filespatch file icon bytelink.patch [^] (663 bytes) 2018-01-30 18:39 [Show Content]

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2018-01-30 18:39 turpin New Issue
2018-01-30 18:39 turpin File Added: bytelink.patch


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker