2.3.0 build error: implicit declaration of function 'faccessat'; did you mean 'access'? [-Wimplicit-function-declaration]

[barracuda156]

--->  Building opam
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_ocaml_opam/opam/work/opam-full-2.3.0" && /usr/bin/make -w all 
make: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_ocaml_opam/opam/work/opam-full-2.3.0'
dune build --profile=release --root .  --promote-install-files -- opam-installer.install opam.install
File "src/core/dune", line 13, characters 11-21:
13 |     (names opam_stubs)
                ^^^^^^^^^^
src/core/opamCommonStubs.c: In function 'opam_is_executable':
src/core/opamCommonStubs.c:55:9: error: implicit declaration of function 'faccessat'; did you mean 'access'? [-Wimplicit-function-declaration]
src/core/opamCommonStubs.c:55:19: error: 'AT_FDCWD' undeclared (first use in this function)
src/core/opamCommonStubs.c:55:19: note: each undeclared identifier is reported only once for each function it appears in
src/core/opamCommonStubs.c:55:38: error: 'AT_EACCESS' undeclared (first use in this function)

[kit-ty-kate]

Could we have more information? What architecture and macOS version is that?
faccessat is part of the libc since POSIX.1-2008

[barracuda156]

@kit-ty-kate It is absent prior to macOS 10.10 (and not architecture-specific), as well as on some other platforms: https://www.gnu.org/software/gnulib/manual/html_node/faccessat.html

[kit-ty-kate]

I'm not sure we want to spend the time to support such old systems.

I'm personally happy to support older hardware to avoid them being thrown in the landfill or for conservation effort but older hardware should have reasonably up-to-date software in my opinion (either by installing an up-to-date Linux/BSD or using the various macOS patches going around on the internet), especially when it comes to specialized tools such as opam

[barracuda156]

Given that opam 2.2.0 built fine, adding a fallback shouldn’t be particularly troublesome though.

faccessat was added here: 0e74798

[kit-ty-kate]

Given that opam 2.2.0 built fine, adding a fallback shouldn’t be particularly troublesome though.

sure, but any legacy code has some amount of crust that keeps adding up and costs precious maintenance time in the long term.

[barracuda156]

It depends, of course, but usually just having a clear condition in a macro works fine, as long as the new code is a drop-in replacement. Nothing is needed to maintain a fallback, since legacy systems won’t change.

[dra27]

I strongly disagree with the notion that "nothing is needed to maintain a fallback". The maintenance argument notwithstanding, having any kind of automatic fallback means that if something in future were to go wrong with our detection code, we'd suddenly start building a less secure or even buggy opam, where without having the fallback code we'd instead have a very obvious build error.

[barracuda156]

@dra27 Since it is known which systems do not have faccessat, it is not needed to have a compile-time check for its presence (assuming a concern it may go wrong), but instead use an explicit macro for a fallback (which cannot go wrong).

[dra27]

The macro itself can go wrong (I'm thinking of fun unintended consequences like ocaml/ocaml#13520).

If this wants to be maintained downstream as a priority for MacPorts, that's fine, but I don't think that any code associated with this has a place upstream here.

[dra27]

Happy to revisit this if there's any supported or modern OS exhibiting this problem, but otherwise closing this.

[barracuda156]

For the record, if someone bumps into this looking for a fix, it is done in MacPorts now: macports/macports-ports@fae7017