#66636 closed defect (fixed)
ossp-uuid fails to compile on latest Ventura
Reported by: | daran0815 | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.0 |
Keywords: | Cc: | ||
Port: | ossp-uuid |
Description (last modified by daran0815)
Apparently the configuration tries to compile against macos sdk 13.0, when the latest xcode xcode only provides 13.1 (xcodebuild -showsdks: -sdk macosx13.1). The config log contains the following (excerpt):
## ----------- ## ## Core tests. ## ## ----------- ## configure:2016: checking whether make sets $(MAKE) configure:2038: result: yes configure:2095: checking for gcc configure:2122: result: /usr/bin/clang configure:2360: checking for C compiler version configure:2368: /usr/bin/clang --version >&5 Apple clang version 11.0.0 (clang-1100.0.33.17) Target: x86_64-apple-darwin22.2.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin configure:2372: $? = 0 configure:2379: /usr/bin/clang -v >&5 Apple clang version 11.0.0 (clang-1100.0.33.17) Target: x86_64-apple-darwin22.2.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin configure:2383: $? = 0 configure:2390: /usr/bin/clang -V >&5 clang: error: unsupported option '-V -Wno-framework-include-private-from-public' clang: error: no input files configure:2394: $? = 1 configure:2417: checking for C compiler default output file name configure:2439: /usr/bin/clang -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -arch x86_64 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -arch x86_64 conftest.c >&5 clang: error: invalid version number in 'MACOSX_DEPLOYMENT_TARGET=13.0' configure:2443: $? = 1 configure:2481: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2488: error: C compiler cannot create executables
Attachments (1)
Change History (9)
comment:1 Changed 22 months ago by daran0815
Description: | modified (diff) |
---|
comment:2 follow-up: 3 Changed 22 months ago by jmroot (Joshua Root)
Changed 22 months ago by daran0815
comment:3 Changed 22 months ago by daran0815
Replying to jmroot:
This error is usually the result of outdated command line tools. The main.log would show your installed version.
I attached the main.log. Can't really see anything outdated. This happened right after an upgrade to Ventura: I reinstalled the port, used "port selfupdate" which worked and then "port upgrade outdated" which failed as stated.
comment:4 Changed 22 months ago by jmroot (Joshua Root)
From the log:
:warn:archivefetch The Xcode Command Line Tools package appears to be installed, but its receipt appears to be missing. :warn:archivefetch The Command Line Tools may be outdated, which can cause problems. :warn:archivefetch Please see: <https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt>
comment:5 Changed 22 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to daran0815:
Apple clang version 11.0.0 (clang-1100.0.33.17)
This version of Clang is from Xcode 11.3.1 which (per XcodeVersionInfo) is for macOS 10.14 and 10.15. Not compatible with Ventura. Upgrade Xcode and/or Xcode CLT to a Ventura-compatible version.
comment:6 Changed 22 months ago by daran0815
Reinstalling the command line tools was cumbersome, but did in fact fix the issue.
comment:7 follow-up: 8 Changed 22 months ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | new → closed |
It would be nice if we required an output from "port diagnose" for tickets, and if port diagnose picked up this problem automatically for folks (if it doesn't robustly do so now).
Would save everyone a lot of time.
comment:8 Changed 22 months ago by jmroot (Joshua Root)
Replying to kencu:
It would be nice if we required an output from "port diagnose" for tickets, and if port diagnose picked up this problem automatically for folks (if it doesn't robustly do so now).
That's #63130. But the user has to run port diagnose
manually, whereas the warning I quoted above is already printed to stderr whenever a build is done.
This error is usually the result of outdated command line tools. The main.log would show your installed version.