Cannot find -lmtime_clock_stubs in bytecode-only mode

[kit-ty-kate]

$ opam switch create bytecode-only --formula '"ocaml-variants" {>= "4.14" & < "4.15"} & "ocaml-option-bytecode-only"'
$ opam install dune mtime
$ echo '(executable (name test) (libraries mtime.clock.os))' > dune
$ echo '(lang dune 2.0)' > dune-project
$ touch test.ml
$ dune build
File "dune", line 2, characters 7-11:
2 |  (name test)
           ^^^^
/usr/bin/ld: cannot find -lmtime_clock_stubs: No such file or directory
collect2: error: ld returned 1 exit status
File "_none_", line 1:
Error: Error while building custom runtime system

but using a switch where ocamlopt is present, the last command works fine.

[kit-ty-kate]

The same can be reproduced without dune using ocamlc's -output-complete-exe option:

$ ocamlfind ocamlc -package mtime.clock.os -linkpkg -output-complete-exe test.ml
/usr/bin/ld: cannot find -lmtime_clock_stubs: No such file or directory
collect2: error: ld returned 1 exit status
File "test.ml", line 1:
Error: Error while building custom runtime system

[dbuenzli]

Could you please do in your bytecode switch a opam source --dev mtime && cd mtime && topkg build and checkout the .install to see if the stubs maybe don't get installed.

[kit-ty-kate]

I had checked before, the file is present

stublibs: [
  "_build/src-clock/dllmtime_clock_stubs.so" {"dllmtime_clock_stubs.so"} ]

[dbuenzli]

So it rather looks like a DLL lookup failure. Did you check the env vars (don't remember which) are correctly setup ?

[kit-ty-kate]

yes, everything is setup correctly. All other packages that use stubs work just fine (for example i just tried the same with sha)

[dbuenzli]

Maybe try to compare the outputs of ocamlobjinfo on the .cma to see if there's anything different between these two libs (mutatis mutandis).

[kit-ty-kate]

ah i think i get what's happening. It's not the .so that is missing but the .a that should be in lib/mtime/clock/os/ but is not.
In a switch where ocamlopt is present libmtime_clock_stubs.a is also present but not in bytecode-only mode.

[kit-ty-kate]

Should this issue be moved to the topkg repository ?

[kit-ty-kate]

It looks like this is caused by this line:

topkg/src/topkg_install.ml

Line 75 in 2a81eb1

List.exists (Filename.check_suffix src) lib_drops

which is a bit too eager to remove all .a, but I'm not sure how to fix that properly. I guess you'd have to introduce a distinction in topkg between:

• target file that has the .a suffix and should only be built when native mode is enabled (OCaml code)
• target file that has the .a suffix and should be built all the time because it is the result of C code

[dbuenzli]

Thanks @kit-ty-kate for the investigation. Will have a look into this in the upcoming days.

[dbuenzli]

Meanwhile you can try to test 5a2283b

[kit-ty-kate]

It works!! Thanks a lot! I'll open a subsequent PR on opam-repository to conflict previous versions of topkg with the bytecode-only mode to be merged at the same time as the release of topkg