Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse ordering of .so arguments and "-dllib -l" options in ocamlc's command line #7716

Closed
vicuna opened this issue Jan 30, 2018 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Jan 30, 2018

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.

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

@github-actions
Copy link

github-actions bot commented May 7, 2020

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.

@nojb
Copy link
Contributor

nojb commented Jun 8, 2020

The path ordering issue was fixed in #9611

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants