[dynlink] Error on dynamic link

[ejgallego]

In the following repos, which is pretty simple:

(library
 (name m)
 (public_name foo-link.plugin)
 (modules m)
 (libraries cohttp-lwt-unix))

(executable
 (name g)
 (public_name g)
 (modules g)
 (libraries findlib.dynload))

where all that what g does is:

let _ =
  try
    Findlib.init ();
    Fl_dynload.load_packages ~debug:true ["foo-link.plugin"]
  with
  | Dynlink.Error err ->
    Format.eprintf "%s@\n%!" (Dynlink.error_message err)

I get:

error loading shared library: /home/egallego/.opam/coq.dev/lib/lwt/unix/lwt_unix.cmxs: undefined symbol: caml_mutex_lock

I dunno if that's a bug in Dune or in Fl_dynload. Repos https://github.com/ejgallego/foo-link

[bobot]

If you add threads to the library field of g it works. Dune considers that the predicate mt is always true statically and dynamically but it doesn't link always with threads.

I don't know what can be done except more documentation because I don't want to link with threads if the user doesn't request it (hypothesis of sequential programming would be broken). Perhaps the case can be detected at runtime and a proper error message provided.

[hbrunie]

I have same error with INTEL openmp.

dune exec ./main.exe
./mm_bench.x: error while loading shared libraries: libiomp5.so: cannot open shared object file: No such file or directory
Fatal error: exception (Failure "Command exited with code 127: ./mm_bench.x 11 1 1 3 512 8")
Raised at Stdlib.failwith in file "stdlib.ml", line 29, characters 17-33
Called from Shexp_process__Process.map.(fun) in file "process-lib/src/process.ml", line 522, characters 40-45
Called from Shexp_process__Process.exec in file "process-lib/src/process.ml", line 167, characters 16-51
Called from Shexp_process__Process.exec in file "process-lib/src/process.ml", line 171, characters 13-44
Re-raised at Shexp_process__Process.exec in file "process-lib/src/process.ml", line 177, characters 9-20
Called from Shexp_process__Process.exec in file "process-lib/src/process.ml", line 212, characters 20-45
Called from Shexp_process__Process.exec in file "process-lib/src/process.ml", line 167, characters 18-51
Called from Shexp_process__Process.exec in file "process-lib/src/process.ml", line 160, characters 16-49
Re-raised at Shexp_process__Process.exec in file "process-lib/src/process.ml", line 163, characters 10-21
Called from Dune__exe__Main.exec_bench_of_death in file "main.ml", line 521, characters 15-98
Called from Dune__exe__Main in file "main.ml", line 529, characters 9-31

Although everything is well linked, and I can launch the binary mm_bench.x without going through dune:

ldd ../c_bench/mm_bench.x 
    linux-vdso.so.1 (0x00002aaaaaad3000)
    libpapi.so.5.7 => /opt/cray/pe/lib64/libpapi.so.5.7 (0x00002aaaaacd3000)
    libm.so.6 => /lib64/libm.so.6 (0x00002aaaab088000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab3c0000)
    libdnnl.so.2 => /global/u1/h/hbrunie/usr/lib64/libdnnl.so.2 (0x00002aaaab5df000)
    libiomp5.so => /opt/intel/compilers_and_libraries_2019.3.199/linux/compiler/lib/intel64/libiomp5.so (0x00002aaaaf2d2000)
    libgcc_s.so.1 => /opt/gcc/8.3.0/snos/lib64/libgcc_s.so.1 (0x00002aaaaf6c7000)
    libc.so.6 => /lib64/libc.so.6 (0x00002aaaaf8df000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaafc9a000)
    libpfm.so.4 => /usr/lib64/libpfm.so.4 (0x00002aaaafe9e000)
    /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
    librca.so.0 => /opt/cray/rca/default/lib64/librca.so.0 (0x00002aaab0282000)
    libz.so.1 => /lib64/libz.so.1 (0x00002aaab0486000)
    libstdc++.so.6 => /opt/gcc/8.3.0/snos/lib64/libstdc++.so.6 (0x00002aaab069d000)
    libimf.so => /opt/intel/compilers_and_libraries_2019.3.199/linux/compiler/lib/intel64/libimf.so (0x00002aaab0a26000)
    libintlc.so.5 => /opt/intel/compilers_and_libraries_2019.3.199/linux/compiler/lib/intel64/libintlc.so.5 (0x00002aaab0fc6000)

[bobot]

Sorry, in which way do you think it is related?

[hbrunie]

I thought it was related because it is a link error at runtime. I thought this was the topic of this issue.

On Fri, Feb 5, 2021, 8:43 AM François Bobot notifications@github.com wrote:

Sorry, in which way do you think it is related?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ocaml/dune/issues/2100#issuecomment-773857655, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABL772RRV2PPO5MRTCLQWU3S5OOSRANCNFSM4HJHNTKA .

[bobot]

It was a link error, but with dynamic linking of an ocaml library. Yours seems an error with static linking of an ocaml library which depends on a C shared library which failed to load. If it is the case could you open another issue, with perhaps a way to reproduce the error? Thank you.