3.22.0 does not build on systems without clock_gettime: how better to fix it?

[barracuda156]

@rgrinberg Hi, this is more of a question than bug report, though it is related to a recent breakage. The following commit c01c7d1 requires clock_gettime, which does not exist in Darwin < 16. So Dune build is broken now. However, legacy-support library supplies emulated version of it: https://github.com/macports/macports-legacy-support/blob/f89c155cbc2ca8714e4ada66c11b222353e8d87a/src/time.c
Since there is a lot of related code, carrying a fall-back is impractical. I could either revert the breaking commit locally or add a dependency on legacy-support. Could you tell me your opinion on what is preferable (assuming away rebasing costs for the first option, purely from point of view of functionality).

[Alizter]

I wouldn't mind keeping around a fallback. We already did one for Windows 7 #13905. It depends how complicated the fallback is of course.

[barracuda156]

@Alizter Thank you, it would be great.

[rgrinberg]

Do we need that entire file you've linked?

[barracuda156]

Do we need that entire file you've linked?

That was just for reference. If clock_gettime implementation there looks suitable, it can be borrowed.

@fhgwright @macportsraf FYI, if you would like to chime in.

[Alizter]

Something like this?

#if defined(__APPLE__) && /* macos version */
  struct timeval tv;
  gettimeofday(&tv, NULL);
  int64_t ns = ((int64_t)tv.tv_sec * 1000000000LL) + ((int64_t)tv.tv_usec * 1000LL);
#else
  struct timespec tp;
  clock_gettime(CLOCK_REALTIME, &tp);
  int64_t ns = ((int64_t)tp.tv_sec * 1000000000LL) + (int64_t)tp.tv_nsec;
#endif

[Alizter]

@barracuda156 Could you try out #13918

[barracuda156]

@Alizter I will try now and update you.

[barracuda156]

--->  Applying patch-clock_gettime.diff
Executing:  cd "/opt/local/var/macports/build/ocaml-dune-3d7a7125/work/dune-3.22.0" && /usr/bin/patch -t -N -p0 < '/opt/local/ppcports/ocaml/ocaml-dune/files/patch-clock_gettime.diff'
patching file otherlibs/stdune/src/time_stubs.c
Hunk #1 succeeded at 27 (offset -10 lines).
--->  Configuring ocaml-dune
Executing:  cd "/opt/local/var/macports/build/ocaml-dune-3d7a7125/work/dune-3.22.0" && ./configure --bindir /opt/local/bin --datadir /opt/local/share/ocaml-dune --docdir /opt/local/share/doc --etcdir /opt/local/etc --libdir /opt/local/lib/ocaml/site-lib --mandir /opt/local/share/man --sbindir /opt/local/sbin 
--->  Building ocaml-dune
Executing:  cd "/opt/local/var/macports/build/ocaml-dune-3d7a7125/work/dune-3.22.0" && DUNE_CONFIG__COPY_FILE=portable /usr/bin/make release 
ocamlc -output-complete-exe -intf-suffix .dummy -g -o .duneboot.exe -I boot unix.cma boot/types.ml boot/libs.ml boot/duneboot.ml
./.duneboot.exe
cd _boot && /opt/local/bin/ocamlc -c -g -I +threads wait4_stubs.c
otherlibs/stdune/src/wait4_stubs.c: In function 'dune_wait4':
otherlibs/stdune/src/wait4_stubs.c:81:3: error: implicit declaration of function 'clock_gettime' [-Wimplicit-function-declaration]
otherlibs/stdune/src/wait4_stubs.c:81:17: error: 'CLOCK_REALTIME' undeclared (first use in this function)
otherlibs/stdune/src/wait4_stubs.c:81:17: note: each undeclared identifier is reported only once for each function it appears in
make: *** [_boot/dune.exe] Error 2

[fhgwright]

In the case of the MacPorts build, then just using legacy-support is the most straightforward approach, and may help with other similar problems in the future. It's a small addition to the Portfile, requires no patches to the code, and is a very lightweight dependency. There's a legacysupport PortGroup to help with this. It includes a parameter to specify the OS version threshold for requiring legacy-support.

If the intent is to make this work for non-MacPorts builds, then that can still be done with legacy-support, but not as conveniently as it could be. I expect to add a legacy-support pkgconfig file to the next release to help with this sort of thing.

My suggestion is to just use legacy-support in the MacPorts build for now, and not worry about non-MacPorts builds until after pkgconfig support exists. Homebrew doesn't support old macOS versions anyway, so it would only matter to users building from source.

[barracuda156]

@fhgwright It is not straightforward with OCaml, really (adding PG does nothing). Not that it is particularly hard, I added legacy-support in a couple of OCaml packages, but it involved hacking build files.

[fhgwright]

@barracuda156

@fhgwright It is not straightforward with OCaml, really (adding PG does nothing). Not that it is particularly hard, I added legacy-support in a couple of OCaml packages, but it involved hacking build files.

Was that before or after the introduction of compiler_wrapper?

[barracuda156]

@fhgwright I can verify specifically, but this was rather recent: macos-powerpc/powerpc-ports@6f2dd1c
The problem is that Dune does not pick flags from environment (unless something changed recently in this regard).

[fhgwright]

@barracuda156

@fhgwright I can verify specifically, but this was rather recent: macos-powerpc/powerpc-ports@6f2dd1c The problem is that Dune does not pick flags from environment (unless something changed recently in this regard).

That's exactly the problem that compiler_wrapper was created to fix. It tends to get applied in a lot of cases where it isn't really necessary due to poor structuring of the PGs, but the general idea is that each compiler and linker command is replaced by a shell script that inserts the needed options into the command line as part of the invocation of the real tool. I have no idea whether it works in this particular case.