Opened 16 months ago

Closed 16 months ago

Last modified 16 months ago

#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)

main.log (20.6 KB) - added by daran0815 16 months ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 16 months ago by daran0815

Description: modified (diff)

comment:2 Changed 16 months ago by jmroot (Joshua Root)

This error is usually the result of outdated command line tools. The main.log would show your installed version.

Changed 16 months ago by daran0815

Attachment: main.log added

comment:3 in reply to:  2 Changed 16 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.

Last edited 16 months ago by daran0815 (previous) (diff)

comment:4 Changed 16 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 in reply to:  description Changed 16 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 16 months ago by daran0815

Reinstalling the command line tools was cumbersome, but did in fact fix the issue.

comment:7 Changed 16 months ago by kencu (Ken)

Resolution: fixed
Status: newclosed

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 in reply to:  7 Changed 16 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.

Note: See TracTickets for help on using tickets.