#70790 closed defect (invalid)
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 (6)
Changed 8 weeks ago by jmroot (Joshua Root)
Attachment: | config.log.bz2 added |
---|
comment:1 Changed 8 weeks ago by jmroot (Joshua Root)
Description: | modified (diff) |
---|
comment:2 Changed 8 weeks 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 8 weeks 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.
comment:4 Changed 8 weeks ago by cjones051073 (Chris Jones)
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:5 Changed 8 weeks ago by jmroot (Joshua Root)
That's still quite strange, since the -arch arm64
option should make clang build for arm64 regardless of what architecture the program itself is running as. I guess you have your fix, and running natively is certainly preferable anyway, but please feel free to reopen if anyone figures out more about this and knows how we can prevent such problems when running via Rosetta.
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: