Compile otherlibs/ C stubs in two version for native and bytecode

[OlivierNicole]

Currently, the libraries in otherlibs/ use a set of C files that are compiled and used to generate both a static library ($(CLIBNAME).$(A), where $(A) is a on Linux) and a dynamic one (dll$(CLIBNAME).$(SO)).

While working on ThreadSanitizer support, we found ourselves needing to use specific compilation flags for the native backend, and therefore to compile otherlibs libraries in two different versions, one for bytecode and one for native. This seems to be a natural enough need to propose a PR for it. @dra27 mentioned that he has a Windows-related use case for this, too.

[shindere]

Many thanks! This looks very nice to me and I think there is not much need to spend tim on the details, because all these makefiles are going to vanish anyway. Here are a few very minor suggestions: * Squash the commits (I assume that was your intention)* * For symmetry, I'd use byt as a prefix for the bytecode verison of the stub library but others may disagree here * You could use a variable to define the C sources andthen compute your lists of objects fromthere, as is done in the Unix case, that would save some redundency

[OlivierNicole]

• For symmetry, I'd use byt as a prefix for the bytecode verison of the stub library but others may disagree here

i also prefer symmetry, but I mimicked what is already done for libthreads. I’m happy to do the symmetric solution if you prefer though.

[OlivierNicole]

• You could use a variable to define the C sources andthen compute your lists of objects fromthere, as is done in the Unix case, that would save some redundency

Done. I also squashed the commits, and fixed a typo that prevented make install from working.

[shindere]

Olivier Nicole (2022/12/21 05:52 -0800):

> * For symmetry, I'd use byt as a prefix for the bytecode verison of the stub library but others may disagree here i also prefer symmetry, but I mimicked what is already done for `libthreads`. I’m happy to do the symmetric solution if you prefer though.

I'd tend to do the symmetric one, including htreads. Let's try and fallback to non-symmetry only if somebody complains. :-)

[OlivierNicole]

• For symmetry, I'd use byt as a prefix for the bytecode verison of the stub library but others may disagree here i also prefer symmetry, but I mimicked what is already done for libthreads. I’m happy to do the symmetric solution if you prefer though.

I'd tend to do the symmetric one, including htreads. Let's try and fallback to non-symmetry only if somebody complains. :-)

OK, done.

[shindere]

Olivier Nicole (2022/12/22 03:52 -0800):

> > * For symmetry, I'd use byt as a prefix for the bytecode verison of the stub library but others may disagree here i also prefer symmetry, but I mimicked what is already done for `libthreads`. I’m happy to do the symmetric solution if you prefer though. > > I'd tend to do the symmetric one, including htreads. Let's try and fallback to non-symmetry only if somebody complains. :-) OK, done.

Thanks. The PR looks as reasonable as permitted by the current state of our build system so I am going to approve and merge.

[xavierleroy]

The build fails at installation time on bytecode-only systems:

make[1]: Entering directory '/builds/workspace/main/flambda/false/label/ocaml-linux-32/otherlibs/runtime_events'
if test -f dllcamlruntime_eventsbyt.so; then \
  /usr/bin/install -c -p \
    dllcamlruntime_eventsbyt.so "/home/ci/ocaml-tmp-install-3276/lib/ocaml/stublibs"; \
fi
if test -f dllcamlruntime_eventsnat.so; then \
  /usr/bin/install -c -p \
    dllcamlruntime_eventsnat.so "/home/ci/ocaml-tmp-install-3276/lib/ocaml/stublibs"; \
fi
/usr/bin/install -c -p -m 644 libcamlruntime_eventsbyt.a "/home/ci/ocaml-tmp-install-3276/lib/ocaml/"
/usr/bin/install -c -p -m 644 libcamlruntime_eventsnat.a "/home/ci/ocaml-tmp-install-3276/lib/ocaml/"
/usr/bin/install: cannot stat 'libcamlruntime_eventsnat.a': No such file or directory
../Makefile.otherlibs.common:105: recipe for target 'install' failed

[OlivierNicole]

Sorry for forgetting to check the bytecode-only build. I propose a fix in #11842.