Build of GNU Make failed on Apple Silicon

[devillove084]

./lib/findprog-in.c:137:25: error: implicit declaration of function 'eaccess' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (eaccess (progpathname, X_OK) == 0)
^
./lib/findprog-in.c:137:25: note: did you mean 'access'?
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:431:6: note: 'access' declared here
int access(const char *, int);
^
./lib/findprog-in.c:211:21: error: implicit declaration of function 'eaccess' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (eaccess (progpathname, X_OK) == 0)
^
2 errors generated.

[jsharpe]

This is a known issue with building make on Apple Silicon on macOS. I don't have access to such a machine to debug this so fixing this requires contributions from the community.

[jsharpe]

To point anyone in the right direction - it seems configure has a check for eaccess which can define eaccess to access which from the error looks to be the behaviour needed for Apple Silicon. Someone with access to a Apple Silicon machine needs to track down why this test is giving the wrong results.
Grabbing the config.log file from the sandbox of a failed build would be a good start.

[keith]

How do you reproduce this? I tested on my M1 machine and building the toolchain directly, or the simple_make example works fine. Maybe because I have a full Xcode install though?

[jsharpe]

@devillove084 are you setting up a custom toolchain or any additional features or copts when you get this failure?

[devillove084]

@jsharpe I didn't use the above options, I just wanted to add the project using cppcoro to my bazel project.

[thirtyseven]

Here is the log for the eaccess check on my machine:

configure:7659: checking for eaccess
configure:7659: /private/var/tmp/_bazel_thirtyseven/c533580fa8099c591fb72f099acb5810/sandbox/darwin-sandbox/548/execroot/data-processing/external/local_config_cc/cc_wrapper.sh -o conftest -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 -D_FORTIFY_SOURCE=1 -DNDEBUG -ffunction-sections -fdata-sections -no-canonical-prefixes -Wno-builtin-macro-redefined -D__DATE__=redacted -D__TIMESTAMP__=redacted -D__TIME__=redacted  -undefined dynamic_lookup -headerpad_max_install_names -lc++ -lm conftest.c  >&5
configure:7659: $? = 0
configure:7659: result: yes

It looks like cc_wrapper.sh is hardcoding /usr/bin/gcc as the C++ compiler regardless of the custom toolchain my project has set up:

# Call the C++ compiler
/usr/bin/gcc "$@"

Edit: Actually don't think that's the issue, when I disable the custom CC toolchain it still fails. Furthermore the build script is using the same local_config_cc CC, so it would appear the eaccess check is possibly giving a legitimate false negative.

[darkrift]

I'm facing the same problem and I'd be glad to help debug this but I'm new to bazel and I would need some help to get me started on Bazel debugging and this module/plugin.

Maybe if we can reach out in slack that would be easier/faster to debug live ? @jsharpe

[jsharpe]

@darkrift are you setting any copts flags or using a custom toolchain? The most common reason for this failure I've seen is due to the -Werror flag being set.

Feel free to reach out to me on slack but I am in the UK so timezones may make live debugging trickier!

[omerbenamram]

this actually works on main, after #894 was merged, but no version was released since.

[hochhaus]

I too was seeing configure incorrectly detect symbols which were not available at compile time (in my case SYNC_FILE_RANGE while compiling postgres). I am unable to reproduce it now so I cannot confirm but I think the issue only existed when using "xcode command line tools".

In my case I believe that one of the following commands fixed it:

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -license

If neither of those help you it also could have been launching the xcode GUI, walking through the wizards and then existing the GUI prior to a full command line rebuild of your bazel targets.

[kpark-hrp]

@hochhaus Is there a way to get around the SYNC_FILE_RANGE error without having to do a full Xcode installation? Wondering if there is a way to mimic the Homebrew's postgresql@14 installation with this.

[hochhaus]

@kpark-hrp Unfortunately, I don't know of a way but I also didn't spend any time looking. If you find a solution could you please post the answer here?