Opened 22 hours ago
Last modified 14 minutes ago
#70790 new defect
m4 build error on Sequoia
Reported by: | eschnett (Erik Schnetter) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.10.1 |
Keywords: | Sequoia | Cc: | |
Port: | m4 |
Description (last modified by jmroot (Joshua Root))
Building m4
on Sequoia fails in the configure stage. The relevant lines are
| #include <sys/types.h> | #include <sys/socket.h> | | int getpeername (int, void *, unsigned long int *); | int | main (void) | { | unsigned long int len; | getpeername (0, 0, &len); | ; | return 0; | } configure:58033: error: Cannot find a type to use in place of socklen_t
I believe the reason is the following. The compiler is invoked with
configure:58023: /usr/bin/clang -c -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk conftest.c >&5
but the file sys/socket.h
is not located in this sysroot. Instead, it is found at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/socket.h
.
Attachments (1)
Change History (4)
Changed 20 hours ago by jmroot (Joshua Root)
Attachment: | config.log.bz2 added |
---|
comment:1 Changed 20 hours ago by jmroot (Joshua Root)
Description: | modified (diff) |
---|
comment:2 Changed 4 hours ago by eschnett (Erik Schnetter)
Indeed I see on my system
uname -m = x86_64
which is wrong (I have an M3 chip). Investigating...
comment:3 Changed 14 minutes ago by eschnett (Erik Schnetter)
It turns out that my terminal emulator, and possibly also my shell, were x86_64
executables running with Rosetta. Maybe this confuses the install scripts? I thought that the default system architecture would still be arm64
, but apparently something was off.
Anyway, I'm now using a native terminal emulator and a native shell. All is working fine, and I was able to install m4
without problems.
Thanks for spotting the i386
clue.
Something seems to be wrong with the SDK you have. On my system:
Your
machine/endian.h
also seems to be includingi386/endian.h
when building for arm: