Cmake macos deployment target11/16/2023 ![]() ![]() ![]() Results logged to /var/folders/5r/61nxx8hs53圆hhzm_r86jhjrq0r6qq/T/Ĭhecking for -with-universal-archs. Patching file Misc/NEWS.d/next/Build/īUILD FAILED (OS X 12.3.1 using python-build 20180424) $ pyenv install 3.8.4įound it was due to a bug in the latest version of Monterey as MACOSX_DEPLOYMENT_TARGET was previously set to 12.3.įixed it by setting MACOSX_DEPLOYMENT_TARGET=12.3.0 % pyenv install 3.8.4 MacOS Monterey 12.3.2 failed to install a new version of python. Therefore, ensuring your SDK is the default out-of-the-box as opposed to XCode's new SDK should be enough for the system to switch context when needed (and seems to work fine with pip+ clang). The built-in Big Sur SDK is version 10.15, which seems to work without an issue: λ ls /Library/Developer/CommandLineTools/SDKsĪfter the switch, multidict was installed successfully. InstalledDir: /Library/Developer/CommandLineTools/usr/bin At the time of writting this edit, I installed the Command Line Tools for Xcode 12.3 beta.Ĭhanges clang to a working version: λ clang -versionĪpple clang version 12.0.0 (clang-1200.0.32.2) To fix this, you must install the latest Command Line Tools from the official Apple website here. Xcode-select: error: invalid developer directory '/Library/Developer/CommandLineTools' You might receive an error when attempting the above change: Setting the xcode-select to the latest version via: sudo xcode-select -switch /Library/Developer/CommandLineTools ![]() InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin However, it seems this come with an unsupported version of clang: λ clang -versionĪpple clang version 11.0.3 (clang-1103.0.32.62) This was originally ].Previously I had installed XCode from the App Store (11.7) and set its SDKs as my default: sudo xcode-select -switch /Applications/Xcode.app/ The default arch and sysroot selected by the toolchain should work fine, and the user can override them if they want to. Most or all of the build system code related to this can be deleted. It should not set the sysroot or architectures. I don't think it's necessary or even desirable for Scribus to be doing this. Finally, there's no way Scribus could build for i386 on macOS anymore anyway since it started requiring Qt 5.10 or later in 2020 (and now requires Qt 5.14 on the Version15x branch) and ]. Falling back to i386 isn't reasonable: Mac OS X 10.6 was the last version that ran on i386 processors (and this build system will do the wrong thing if Mac OS X 10.6 is being used on an i386 processor), macOS 10.13 was the last version on which it was possible to build for i386, and macOS 10.14 was the last version on which is was possible to run i386 software. The immediate problem is ], where only known x86_64 macOS versions 10.6 through 13 are set to build for x86_64. Beta versions of macOS 14 Sonoma are already available and will exhibit this problem on x86_64 even with the latest Scribus development build system. The problem was ] but the problem will resurface every year when Apple releases a new version of macOS. Critically, when building on a version of macOS not known to the build system, it will fall back to building for i386. The Scribus build system has hundreds of lines of code ] for setting CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES explicitly based on the macOS version, architecture, and which SDK is installed. Scribus 1.5.8 fails to build on macOS 13 Ventura on x86_64 because it is trying to build for i386 instead of x86_64. 0016975: Build failure on newer macOS versions than were available when Scribus was released
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |