You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7716 Reporter: turpin Status: new Resolution: open Priority: normal Severity: minor Platform: all OS: all OS Version: all Version: 4.06.0 Category: compiler driver Monitored by:@nojb@dbuenzli
Bug 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.
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
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.
Original bug ID: 7716
Reporter: turpin
Status: new
Resolution: open
Priority: normal
Severity: minor
Platform: all
OS: all
OS Version: all
Version: 4.06.0
Category: compiler driver
Monitored by: @nojb @dbuenzli
Bug 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:
I'm not sure if the situation actually correspond to what was intended, but anyway I believe things could be improved in three ways:
Best Regards
Tiphaine Turpin
MathWorks
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:
!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
File attachments
The text was updated successfully, but these errors were encountered: