CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-06-21T17:29:18-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16457Add support for PGI compiler on macOS2018-06-21T17:29:18-04:00Alexander SaprykinAdd support for PGI compiler on macOSI'm using the latest (16.10) PGI compiler (C) to builds a shared library. But when linking I get errors:
```
pgcc-Error-Unknown switch: -compatibility_version
pgcc-Error-Unknown switch: -install_name
```
It seems that PGI doesn't re...I'm using the latest (16.10) PGI compiler (C) to builds a shared library. But when linking I get errors:
```
pgcc-Error-Unknown switch: -compatibility_version
pgcc-Error-Unknown switch: -install_name
```
It seems that PGI doesn't recognise several options.https://gitlab.kitware.com/cmake/cmake/-/issues/16886property MACOSX_PACKAGE_LOCATION does not copy frameworks and resources recur...2024-01-08T15:33:16-05:00Sandy Martelproperty MACOSX_PACKAGE_LOCATION does not copy frameworks and resources recursively with some generators[test.tar.xz](/uploads/60c51a5482def2c90e6d51e6b1c5fb7b/test.tar.xz)
I have 3rd parties private frameworks and resource folders to be copied in the application bundle, I set the MACOSX_PACKAGE_LOCATION property on them:
set_source_file...[test.tar.xz](/uploads/60c51a5482def2c90e6d51e6b1c5fb7b/test.tar.xz)
I have 3rd parties private frameworks and resource folders to be copied in the application bundle, I set the MACOSX_PACKAGE_LOCATION property on them:
set_source_files_properties( private.framework PROPERTIES MACOSX_PACKAGE_LOCATION Frameworks )
set_source_files_properties( folder PROPERTIES MACOSX_PACKAGE_LOCATION Resources )
but they are only copied correctly when using the Xcode generator, make or ninja failed to copy the whole folder.
See attached project, run ./build.sh, compare the 2 .app generated.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16909CMAKE_SYSTEM_PROCESSOR is overwritten2017-05-22T09:52:46-04:00DiederickCMAKE_SYSTEM_PROCESSOR is overwrittenI'm trying to use cmake with different toolchain files to compile a library on Mac OS for armv7, armv7s, i386 and x86_64. Using toolchain files works fine, except I have to link with different libraries/frameworks based on the architectu...I'm trying to use cmake with different toolchain files to compile a library on Mac OS for armv7, armv7s, i386 and x86_64. Using toolchain files works fine, except I have to link with different libraries/frameworks based on the architecture/build. I was thinking that using CMAKE_SYSTEM_PROCESSOR was the right choice but I'm not entirely sure anymore.
When I set the CMAKE_SYSTEM_PROCESSOR in my toolchain file it's always reset to `x86_64` in my CMakeLists.txt (and external projects). I've tried using CACHED and non-cached variables. I've created a repository that can be used to reproduce the issue: https://github.com/roxlu/cmake_multi_arch
But besides this issue, I'm not sure how to handle building for the iOS simulator. When building for the iOS simulator one uses x86_64 (so CMAKE_SYSTEM_PROCESSOR would be x86_64) but I would still need to link with different libraries which are only available for iOS. In this case checking for x86_64 wouldn't be enough. Are there other options?https://gitlab.kitware.com/cmake/cmake/-/issues/17023setting CMAKE_RUNTIME_OUTPUT_DIRECTORY on OS X w/ the makefile generator brea...2017-06-30T00:01:20-04:00Edward Ruddsetting CMAKE_RUNTIME_OUTPUT_DIRECTORY on OS X w/ the makefile generator breaks linking binaries.I have a project ( https://github.com/HumbleNet/HumbleNet ) that when I build using the XCode generator everything works fine.. However when I use the Makefile generator it incorrectly generates the link.txt files.
This is recreatable w...I have a project ( https://github.com/HumbleNet/HumbleNet ) that when I build using the XCode generator everything works fine.. However when I use the Makefile generator it incorrectly generates the link.txt files.
This is recreatable with cmake 3.6.2, 3.7.1, and 3.8.2
This is what the apibuilder/CMakeFiles/APIBuilder.dir/link.txt is when I comment out the CMAKE_RUNTIME_OUTPUT_DIRECTORY assignment in the main CmakeListst.txt (line 16)
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fno-strict-aliasing -stdlib=libc++ -fvisibility=hidden -g -arch i386 -arch x86_64 -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ CMakeFiles/APIBuilder.dir/build_csharp.cpp.o CMakeFiles/APIBuilder.dir/build_export.cpp.o CMakeFiles/APIBuilder.dir/build_include.cpp.o CMakeFiles/APIBuilder.dir/build_loader.cpp.o CMakeFiles/APIBuilder.dir/builder.cpp.o CMakeFiles/APIBuilder.dir/utilities.cpp.o -o APIBuilder -Wl,-rpath,@executable_path/../Frameworks ../libjsonparser.a
However when I add that back in the "-o" ends up being ".".
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fno-strict-aliasing -stdlib=libc++ -fvisibility=hidden -g -arch i386 -arch x86_64 -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ CMakeFiles/APIBuilder.dir/build_csharp.cpp.o CMakeFiles/APIBuilder.dir/build_export.cpp.o CMakeFiles/APIBuilder.dir/build_include.cpp.o CMakeFiles/APIBuilder.dir/build_loader.cpp.o CMakeFiles/APIBuilder.dir/builder.cpp.o CMakeFiles/APIBuilder.dir/utilities.cpp.o -o . -Wl,-rpath,@executable_path/../Frameworks ../libjsonparser.a
This cmake works fine on linux using the Makefile generator.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/17132REGEX expression in install command is converted to lower case2017-08-03T16:03:15-04:00Pere MatoREGEX expression in install command is converted to lower caseCMake 3.8.1, MacOS 10.12
When specifying a REGEX expression to EXCLUDE files to be installed with INSTALL(DIRECTORY)the expression gets converted to lowercase.
The following statement in a CMakeLists.txt file
```
install(DIRECTORY mydir...CMake 3.8.1, MacOS 10.12
When specifying a REGEX expression to EXCLUDE files to be installed with INSTALL(DIRECTORY)the expression gets converted to lowercase.
The following statement in a CMakeLists.txt file
```
install(DIRECTORY mydir DESTINATION include REGEX aAbBcC EXCLUDE)
```
produces the cmake_install.cmake file with
```
if("${CMAKE_INSTALL_COMPONENT}" STREQUAL "Unspecified" OR NOT CMAKE_INSTALL_COMPONENT)
file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/include" TYPE DIRECTORY FILES "/Users/mato/mydir" REGEX "aabbcc" EXCLUDE)
endif()
```https://gitlab.kitware.com/cmake/cmake/-/issues/17233Compilation errors when compiling CMake on Mac OSX 10.12.6 with gcc 7.12017-08-30T14:32:29-04:00fuhlig1Compilation errors when compiling CMake on Mac OSX 10.12.6 with gcc 7.1Hi,
I tried to compile CMake 3.9.1 with gcc 7.1 on the latest Mac OSX release (10.12.6). During compilation I got the following errors
> ```
> [ 10%] Building C object Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/file.c.o
> In file inclu...Hi,
I tried to compile CMake 3.9.1 with gcc 7.1 on the latest Mac OSX release (10.12.6). During compilation I got the following errors
> ```
> [ 10%] Building C object Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/file.c.o
> In file included from /System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32:0,
> from /System/Library/Frameworks/Security.framework/Headers/Security.h:43,
> from /opt/alibuild/sw/SOURCES/CMake/v3.9.1/v3.9.1/Utilities/cmcurl/lib/urldata.h:148,
> from /opt/alibuild/sw/SOURCES/CMake/v3.9.1/v3.9.1/Utilities/cmcurl/lib/file.c:52:
> /System/Library/Frameworks/Security.framework/Headers/Authorization.h:192:7: error: variably modified 'bytes' at file scope
> char bytes[kAuthorizationExternalFormLength];
> ^~~~~
> ```
Since the problem is related to the native SSL/TLS implementation the problem could be solved by changing excluding Apple OS native SSL/TLS implementation. Please find the change in the respective CMakeLists.txt in the attached patch.
The second error is due to a missing header file which is probably included implicitly when using clang. The needed correction is also in the attached patch.
When running the tests the same tests fail as for the normal compilation with the clang compiler.
> ```
> The following tests FAILED:
> 78 - Architecture (Failed)
> 174 - BundleTest (Failed)
> 183 - TestsWorkingDirectory (Failed)
> 431 - CMake.GetFilenameComponentRealpath (Failed)
> ```
Best regards
Florian Uhlig
[gcc71_osx10126.patch](/uploads/2ca961cedd0da00724654c373c13a673/gcc71_osx10126.patch)
https://gitlab.kitware.com/cmake/cmake/-/issues/17258find_package() variables should be case-insensitive2017-09-11T13:12:38-04:00Robert Daileyfind_package() variables should be case-insensitiveWhen doing `find_package(Foo CONFIG)`, predefined variables will follow the pattern `Foo_FIND_COMPONENTS`. If I change the initial call to use `foo`, then the variables become `foo_FIND_COMPONENTS`. This is error prone and IMHO I think t...When doing `find_package(Foo CONFIG)`, predefined variables will follow the pattern `Foo_FIND_COMPONENTS`. If I change the initial call to use `foo`, then the variables become `foo_FIND_COMPONENTS`. This is error prone and IMHO I think the variables should be all-upper-case. So no matter what case the user chooses when they call `find_package()`, the config package scripts get the same variables. Furthermore, this makes sense given that the config file search behavior is also case insensitive. So given both scenarios mentioned previously, you'd get `FOO_FIND_COMPONENTS` in both.
For backward compatibility, you can continue to define the verbatim-case versions of those variables.https://gitlab.kitware.com/cmake/cmake/-/issues/16739iOS framework headers doesn't preserve folder hierarchy2023-04-19T05:43:03-04:00Robert BielikiOS framework headers doesn't preserve folder hierarchyIf I have a include header hierarchy as follows:
```
.
└── mylib
├── header.h - My libs header
├── header2.h
└── service
└── header.h - A header with same name as in folder above
```
and use:
```
SET(MY_HEADE...If I have a include header hierarchy as follows:
```
.
└── mylib
├── header.h - My libs header
├── header2.h
└── service
└── header.h - A header with same name as in folder above
```
and use:
```
SET(MY_HEADERS
mylib/header.h
mylib/header2.h
mylib/service/header.h
)
SET_TARGET_PROPERTIES(mylibtarget
PROPERTIES
FRAMEWORK TRUE
MACOSX_RPATH ON
...
PUBLIC_HEADER "${MY_HEADERS}"
...
)
```
I end up with a framework that has following structure:
```
.
└── mylib.framework
├── Headers
│ ├── header.h
│ └── header2.h
├── Info.plist
└── mylib
```
i.e. the root include hierarchy has been flattened, and not only that, the header.h in the framework is the "last" header.h in the include, the one in the **service** subfolder !! What I of course really should have is:
```
.
└── mylib.framework
├── Headers
│ ├── header.h
│ ├── header2.h
│ └── service
│ └── header.h
├── Info.plist
└── mylib
```
This is with cmake 3.7.1 on Mac OS X 10.11.6 and Xcode 8.2.1.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16731Ninja: response files not supported by `ar` on macOS2021-07-22T05:25:18-04:00Brad KingNinja: response files not supported by `ar` on macOSWhen using `CMAKE_NINJA_FORCE_RESPONSE_FILE` or creating a very large archive, the Ninja generator produces a response file rule. However, `ar` on macOS does not support response files.
Fixing this will require the Ninja generator to t...When using `CMAKE_NINJA_FORCE_RESPONSE_FILE` or creating a very large archive, the Ninja generator produces a response file rule. However, `ar` on macOS does not support response files.
Fixing this will require the Ninja generator to thread through information about what tool is being used and whether it supports response files. Also, in order to generate large archives on macOS without using response files we will need to resolve the existing TODO comment in the Ninja generator about using `ARCHIVE_APPEND` rules.https://gitlab.kitware.com/cmake/cmake/-/issues/16305cpack hangs after installation of project2017-10-13T13:17:55-04:00Adam Updegrovecpack hangs after installation of projectIm on Mac OSX 10.10 and using cmake version 3.5.2 with cpack to create a mac Bundle.
I have used cpack --debug and pack --verbose and found that everything installs fine and then cpack just hangs at:
'CPack Verbose: Package files to: l...Im on Mac OSX 10.10 and using cmake version 3.5.2 with cpack to create a mac Bundle.
I have used cpack --debug and pack --verbose and found that everything installs fine and then cpack just hangs at:
'CPack Verbose: Package files to: location_of_dmg'
This is the step where it creates the dmg. cpack was able to create the dmg no problem with an older version of my project with less files and installed libs. So it seems like cpack is having trouble packaging the larger size? Is there anything I may be missing here.
Thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/16427`find_package(Ruby)` returns incorrect paths on macOS2022-08-25T09:53:30-04:00Xu Cheng`find_package(Ruby)` returns incorrect paths on macOS* CMake Version: 3.7.0 (installed by `brew install cmake`)
* OS: macOS Sierra 10.12.1
### Detailed steps to reproduce the problem
* Install Ruby 2.3 by `brew install ruby`.
* Create `CMakeLists.txt` with below content.
```cmake
...* CMake Version: 3.7.0 (installed by `brew install cmake`)
* OS: macOS Sierra 10.12.1
### Detailed steps to reproduce the problem
* Install Ruby 2.3 by `brew install ruby`.
* Create `CMakeLists.txt` with below content.
```cmake
cmake_minimum_required (VERSION 3.7.0)
project(bug)
set(_RUBY_DEBUG_OUTPUT ON)
find_package(Ruby 2.3 REQUIRED)
```
* Run `cmake .`
### What happened
CMake finds Ruby header and libraries, which are all pointed to the system framework (as shown in below log). However, this is incorrect. Because the version of system Ruby is 2.0 instead of 2.3 as required by `CMakeLists.txt`.
```
[snip]
-- --------FindRuby.cmake debug------------
-- _RUBY_POSSIBLE_EXECUTABLE_NAMES: ruby2.3;ruby23;ruby;ruby2.1;ruby21;ruby2.0;ruby20;ruby1.9;ruby19;ruby1.8;ruby18
-- _RUBY_POSSIBLE_LIB_NAMES: ruby;ruby-static;ruby2.3;ruby23;ruby-2.3;ruby-2.3.0
-- RUBY_ARCH_DIR: /usr/local/Cellar/ruby/2.3.1_2/lib/ruby/2.3.0/x86_64-darwin16
-- RUBY_HDR_DIR: /usr/local/Cellar/ruby/2.3.1_2/include/ruby-2.3.0
-- RUBY_POSSIBLE_LIB_DIR: /usr/local/Cellar/ruby/2.3.1_2/lib
-- Found RUBY_VERSION: "2.3.0" , short: "2.3", nodot: "23"
-- _RUBY_REQUIRED_VARS: RUBY_EXECUTABLE;RUBY_INCLUDE_DIR;RUBY_LIBRARY;RUBY_CONFIG_INCLUDE_DIR
-- RUBY_EXECUTABLE: /usr/local/bin/ruby
-- RUBY_LIBRARY: /System/Library/Frameworks/ruby.framework
-- RUBY_INCLUDE_DIR: /System/Library/Frameworks/Ruby.framework/Headers
-- RUBY_CONFIG_INCLUDE_DIR: /System/Library/Frameworks/Ruby.framework/Headers
-- --------------------
-- Found Ruby: /usr/local/bin/ruby (found suitable version "2.3.0", minimum required is "2.3")
[snip]
```
### What should have happened
It should set `RUBY_LIBRARY`, `RUBY_INCLUDE_DIR` and `RUBY_CONFIG_INCLUDE_DIR` to Homebrew Ruby(v2.3) instead of system Ruby(v2.0).
### Cause and Workaround
This is caused as by default CMake has `CMAKE_FIND_FRAMEWORK` as `First` on macOS. In turn, `find_library` and `find_path` inside `FindRuby.cmake` will search macOS Framework before the paths supplied by `HINTS`.
Related Codes which trigger the bug:
* `find_path` in `FindRuby.cmake`: https://github.com/Kitware/CMake/blob/v3.7.0/Modules/FindRuby.cmake#L182-L187
* `find_library` in `FindRuby.cmake`: https://github.com/Kitware/CMake/blob/v3.7.0/Modules/FindRuby.cmake#L238
* Framework path by default has higher priority over `HINTS`: https://github.com/Kitware/CMake/blob/v3.7.0/Source/cmFindPathCommand.cxx#L48-L61
I suspect this bug has wider impact than just Ruby. It may be triggered by other macOS system Framework libraries (e.g. Python). To solve it, I think `HINTS` should have the highest priority, regardless the value of `CMAKE_FIND_FRAMEWORK`.
To workaround it, set `CMAKE_FIND_FRAMEWORK` to `Last` in `CMakeLists.txt`.https://gitlab.kitware.com/cmake/cmake/-/issues/16292FindPostgreSQL doesn't work for macports2018-01-09T14:46:10-05:00Martin GerhardyFindPostgreSQL doesn't work for macportsmacports installs libpg-fe.h into e.g /opt/local/include/postgresql96/server/catalog/
there is no extra directory per version, nor a dot in between them.
I was just able to find them by doing:
```
set(PostgreSQL_INCLUDE_ADDITIONAL_SEAR...macports installs libpg-fe.h into e.g /opt/local/include/postgresql96/server/catalog/
there is no extra directory per version, nor a dot in between them.
I was just able to find them by doing:
```
set(PostgreSQL_INCLUDE_ADDITIONAL_SEARCH_SUFFIXES "postgresql96")
set(PostgreSQL_TYPE_ADDITIONAL_SEARCH_SUFFIXES "postgresql96/server")
set(PostgreSQL_LIBRARY_ADDITIONAL_SEARCH_SUFFIXES "postgresql96")
set(PostgreSQL_ADDITIONAL_SEARCH_PATHS "/opt/local/include/postgresql96/server")
```https://gitlab.kitware.com/cmake/cmake/-/issues/16168"cmake -E tar" ignores COPYFILE_DISABLE environment variable2023-03-25T00:59:23-04:00Mark Moll"cmake -E tar" ignores COPYFILE_DISABLE environment variableI use cpack to generate source tar balls. If I do this on OS X, this results in lots of `._*` files (corresponding to extended attribute data) being included. If you use "file(GLOB *.cpp)" in your CMakeLists.txt (as I do), then you get l...I use cpack to generate source tar balls. If I do this on OS X, this results in lots of `._*` files (corresponding to extended attribute data) being included. If you use "file(GLOB *.cpp)" in your CMakeLists.txt (as I do), then you get lots of files that don't compile on any OS other than OS X. I believe that cpack uses "cmake -E tar" to create the TGZ files, so the problem is probably in this code. On OS X you can set the environment variable COPYFILE_DISABLE to prevent extended attribute data from being included in tar balls. This setting is used by tar, bsdtar, and gnutar on OS X, but "cmake -E tar" ignores it. Alternatively, a CPack/CMake variable to control whether extended attribute data should be included would also be good.https://gitlab.kitware.com/cmake/cmake/-/issues/16270POST_BUILD of MODULE library when the BUNDLE property is set to yes runs befo...2017-10-13T13:17:56-04:00Matt KeelerPOST_BUILD of MODULE library when the BUNDLE property is set to yes runs before resources and executables are copied into the bundleI was using cmake to create a macOS preference pane. I have something like
```
add_library(pref-pane MODULE ${NIB_LOCATION} ${INCLUDE_FILES} ${PREFPANE_SOURCES} ${PREFPANE_RESOURCES} ${XIB_FILE})
target_link_libraries(pref-pane .....I was using cmake to create a macOS preference pane. I have something like
```
add_library(pref-pane MODULE ${NIB_LOCATION} ${INCLUDE_FILES} ${PREFPANE_SOURCES} ${PREFPANE_RESOURCES} ${XIB_FILE})
target_link_libraries(pref-pane .....)
set_target_properties(pref-pane PROPERTIES OUTPUT_NAME ${REAL_NAME} BUNDLE YES BUNDLE_EXTENSION prefPane MACOSX_BUNDLE_INFO_PLIST ${MY_PLIST_TEMPLATE})
add_custom_command(TARGET pref-pane POST_BUILD COMMAND codesign -s ${IDENTITY} $<TARGET_FILE_DIR:pref-pane>/../..)
```
What I expected was for codesign to be run after everything was put into the bundle but what happens is that it is codesigned after the pref-pane module is created but before anything is copied around to the final destination.
As an aside, it would be nice for bundles to be able to get the top level of the bundle instead of having to rely on the module dir and up two levels.https://gitlab.kitware.com/cmake/cmake/-/issues/16155Mach-O rpath editing should check before performing its actions2017-10-13T13:17:56-04:00alcroitoMach-O rpath editing should check before performing its actionsHi,
I've stumbled upon a small issue when trying to build, install, re-build and re-install a project using CMake.
Configuration: OSX 10.11.5, XCode 7.3.1, CMake 3.5.2
If it happens that a dylib library is built and installed ve...Hi,
I've stumbled upon a small issue when trying to build, install, re-build and re-install a project using CMake.
Configuration: OSX 10.11.5, XCode 7.3.1, CMake 3.5.2
If it happens that a dylib library is built and installed very fast one after another, the installed(copied) library modification timestamp is going to be equal to the modification timestamp of the library in the build folder. Which means that subsequently calling make install, will skip copying the library, because the modification timestamps are the same.
This is due to the fact that the comparison is done on 1-second granularity (relevant CMake code can be found in `cmake/Source/cmFileTimeComparison.cxx`, function `cmFileTimeComparisonInternal::TimesDiffer` and also the install time check in `cmake/Source/cmFileCommand.cxx`, beginning of function `cmFileCopier::InstallFile`).
This leads to warnings when running make install again and the target library's rpaths are going to be removed at the install step (executed in `cmake_install.cmake` file, search for "`delete_rpath`" in the file).
I've attached a small reproducible project, and the output log of the build, install, and re-install.
Extract the archive, and run the commands as below:
```
$ cd test
$ cmake .
$ make && make install && make install
[ 25%] Building CXX object CMakeFiles/lib1.dir/test.cpp.o
[ 50%] Linking CXX shared library liblib1.dylib
[ 50%] Built target lib1
[ 75%] Building CXX object CMakeFiles/lib2.dir/test2.cpp.o
[100%] Linking CXX shared library liblib2.dylib
[100%] Built target lib2
[ 50%] Built target lib1
[100%] Built target lib2
Install the project...
-- Install configuration: ""
[ 50%] Built target lib1
[100%] Built target lib2
Install the project...
-- Install configuration: ""
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: no LC_RPATH load command with path: /Users/user/Dev/test found in: /Users/user/Dev/test/liblib2.dylib (for architecture x86_64), required for specified option "-delete_rpath /Users/user/Dev/test"
```
[osx_rpath_race_condition.tar.gz](/uploads/f21f321c9849b1c1f698e28a4f8c93d4/osx_rpath_race_condition.tar.gz)
https://gitlab.kitware.com/cmake/cmake/-/issues/16262macOS cmake-gui --install symlink permissions v. umask2017-10-13T13:17:56-04:00Andrew WmacOS cmake-gui --install symlink permissions v. umaskOSX 10.11. No previous CMake install on this drive.
Downloaded CMake 3.6.1 dmg for Darwin from cmake.org
Installed App. Opened. Followed "install command line" instructions.
```
% sudo "/Applications/CMake.app/Contents/bin/cmake...OSX 10.11. No previous CMake install on this drive.
Downloaded CMake 3.6.1 dmg for Darwin from cmake.org
Installed App. Opened. Followed "install command line" instructions.
```
% sudo "/Applications/CMake.app/Contents/bin/cmake-gui" --install
Password:
Linked: '/usr/local/bin/cmake' -> '/Applications/CMake.app/Contents/bin/cmake'
Linked: '/usr/local/bin/ctest' -> '/Applications/CMake.app/Contents/bin/ctest'
Linked: '/usr/local/bin/cpack' -> '/Applications/CMake.app/Contents/bin/cpack'
Linked: '/usr/local/bin/cmake-gui' -> '/Applications/CMake.app/Contents/bin/cmake-gui'
Linked: '/usr/local/bin/ccmake' -> '/Applications/CMake.app/Contents/bin/ccmake'
% cmake --version
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/local/share/cmake-3.6
cmake version 3.6.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
```
Workaround: building and installing from source works.https://gitlab.kitware.com/cmake/cmake/-/issues/16086Ninja generator doesn't handle multiple Mac apps using the same plist file wi...2017-10-13T13:17:56-04:00Kitware RobotNinja generator doesn't handle multiple Mac apps using the same plist file with MACOSX_BUNDLE_INFO_PLISTThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16086). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16086). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15255CPack Error: Error executing: /usr/bin/Rez during build2017-10-13T13:17:56-04:00Kitware RobotCPack Error: Error executing: /usr/bin/Rez during buildThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15255). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15255). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15997CMake 3.5 fails to build on OS X with GTK framework installed2017-10-13T13:17:56-04:00Kitware RobotCMake 3.5 fails to build on OS X with GTK framework installedThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15997). Further discussion may take place here.
---
Running bootstrap on OS X fails with GTK framework installed in /Library/Fra...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15997). Further discussion may take place here.
---
Running bootstrap on OS X fails with GTK framework installed in /Library/Frameworks.
Error is:
```
CMake Error at Modules/FindGTK2.cmake:182 (file):
file STRINGS file "/Library/Frameworks/Gtk.framework/Headers/gtk/gtk/gtkversion.h" cannot be read.
```
Actual path is `/Library/Frameworks/Gtk.framework/Headers/gtk/gtkversion.h`
I fixed the error by editing `Modules/FindGTK2.cmake` and changing references from `${GTK2_GTK_INCLUDE_DIR}/gtk/gtkversion.h` to `${GTK2_GTK_INCLUDE_DIR}/gtkversion.h`, Lines 631 and 883.https://gitlab.kitware.com/cmake/cmake/-/issues/16045OS X system GLUT should always be preferred to X11's2017-10-13T13:17:56-04:00Kitware RobotOS X system GLUT should always be preferred to X11'sThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16045). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16045). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15591CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES variables are actually clang-sp...2017-10-13T13:17:56-04:00Kitware RobotCMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES variables are actually clang-specific not osx-specificThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15591). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15591). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15205support for osx resource toolchain2017-10-13T13:17:56-04:00Kitware Robotsupport for osx resource toolchainThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15205). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15205). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15581cmake gets confused on apple because of the caseless files system2017-10-13T13:17:56-04:00Kitware Robotcmake gets confused on apple because of the caseless files systemThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15581). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15581). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15525FindCUDA: Sporadic build failures in parallel make on OS X2017-10-13T13:17:56-04:00Kitware RobotFindCUDA: Sporadic build failures in parallel make on OS XThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15525). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15525). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15488Strange things happen to paths below "/Volumes/Macintosh HD"2017-10-13T13:17:56-04:00Kitware RobotStrange things happen to paths below "/Volumes/Macintosh HD"This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15488). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15488). Further discussion may take place here.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/15650Linking large files on OS X can result in linker failing with "command line t...2017-10-13T13:17:56-04:00Kitware RobotLinking large files on OS X can result in linker failing with "command line too long" errorThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15650). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15650). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15485CFBundleExecutable path in a bundle should not be a relative path into bundle2017-10-13T13:17:56-04:00Kitware RobotCFBundleExecutable path in a bundle should not be a relative path into bundleThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15485). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15485). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15387FindwxWidget.cmake can not find the wxWidgets framework installed by Mac Port2017-10-13T13:17:56-04:00Kitware RobotFindwxWidget.cmake can not find the wxWidgets framework installed by Mac PortThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15387). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15387). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14998Error performing "make install" step for CMake 3.0 on OSX 10.9.3, building ag...2017-10-13T13:17:57-04:00Kitware RobotError performing "make install" step for CMake 3.0 on OSX 10.9.3, building against Qt5 (fixup_bundle failure)This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14998). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14998). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14733[OSX] Specify arch-specific flags with multiple CMAKE_OSX_ARCHITECTURES2017-10-13T13:17:57-04:00Kitware Robot[OSX] Specify arch-specific flags with multiple CMAKE_OSX_ARCHITECTURESThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14733). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14733). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15085generator expression for getting osx bundle folder2017-10-13T13:17:57-04:00Kitware Robotgenerator expression for getting osx bundle folderThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15085). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15085). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15835Teach BasicConfigVersion to support Apple universal binaries2017-10-13T13:17:57-04:00Kitware RobotTeach BasicConfigVersion to support Apple universal binariesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15835). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15835). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14267CMake does not detect framework path if it contains a trailing slash2017-10-13T13:17:57-04:00Kitware RobotCMake does not detect framework path if it contains a trailing slashThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14267). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14267). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14671install TARGETS with BUNDLE does not work for target that have the BUNDLE pro...2017-10-13T13:18:30-04:00Kitware Robotinstall TARGETS with BUNDLE does not work for target that have the BUNDLE property setThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14671). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14671). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13969BundleUtilities to bundle shared libraries without any executable2017-10-13T13:18:31-04:00Kitware RobotBundleUtilities to bundle shared libraries without any executableThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13969). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13969). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13893CMAKE_OSX_SYSROOT overwritten to "/"2017-10-13T13:18:31-04:00Kitware RobotCMAKE_OSX_SYSROOT overwritten to "/"This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13893). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13893). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13694CMAKE_OSX_SYSROOT isn't quoted, breaking builds when the SDK path contains a ...2020-06-30T09:17:39-04:00Kitware RobotCMAKE_OSX_SYSROOT isn't quoted, breaking builds when the SDK path contains a spaceThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13694). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13694). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13367Problem with Eclipse project generation : OpenGL and GLUT headers2017-10-13T13:18:31-04:00Kitware RobotProblem with Eclipse project generation : OpenGL and GLUT headersThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13367). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13367). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13784[OSX] Copy directories as easily as files into the application bundle2017-10-13T13:18:31-04:00Kitware Robot[OSX] Copy directories as easily as files into the application bundleThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13784). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13784). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13833fixup_bundle fails with libraries that aren't writable2017-10-13T13:18:31-04:00Kitware Robotfixup_bundle fails with libraries that aren't writableThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13833). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13833). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13271is_file_executable() from GetPrerequisites.cmake erroneously returns 0 for un...2017-10-13T13:18:31-04:00Kitware Robotis_file_executable() from GetPrerequisites.cmake erroneously returns 0 for universal binaries (MacOSX)This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13271). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13271). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13584Framework include directories propagate to other build tools2017-10-13T13:18:31-04:00Kitware RobotFramework include directories propagate to other build toolsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13584). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13584). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13754Ninja: Framework paths are not correctly added to g++ commandline args.2017-10-13T13:18:31-04:00Kitware RobotNinja: Framework paths are not correctly added to g++ commandline args.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13754). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13754). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/13520CodeBlocks - NMake generator says 'Copying OS X content ...'2017-10-13T13:18:31-04:00Kitware RobotCodeBlocks - NMake generator says 'Copying OS X content ...'This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13520). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=13520). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/12942Would like to specify a different default location for OSX binary2017-10-13T13:18:31-04:00Kitware RobotWould like to specify a different default location for OSX binaryThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12942). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12942). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/11665current implementation of CPACK_*_SCRIPT useless when project has subcomponents2017-10-13T13:18:32-04:00Kitware Robotcurrent implementation of CPACK_*_SCRIPT useless when project has subcomponentsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11665). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11665). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/11664CPACK_*_SCRIPT not correctly located in a CPACK generated DMG2017-10-13T13:18:32-04:00Kitware RobotCPACK_*_SCRIPT not correctly located in a CPACK generated DMGThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11664). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11664). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/17354How to remove `-install_name` options for mingw on mac OSX2017-10-16T13:01:16-04:00Leen GuiHow to remove `-install_name` options for mingw on mac OSXI installed the [bwapi][1] via wine on Mac OSX. And I try to cross-compile the ExampleAIModule of bwapi with CMake and MinGW on Mac OSX. The ExampleAIModule is actually a VS2017 project, I wrote a CMakeLists.txt, ran `cmake CMakeLists.tx...I installed the [bwapi][1] via wine on Mac OSX. And I try to cross-compile the ExampleAIModule of bwapi with CMake and MinGW on Mac OSX. The ExampleAIModule is actually a VS2017 project, I wrote a CMakeLists.txt, ran `cmake CMakeLists.txt && make VERBOSE=1` got some errors. `i686-w64-mingw32-g++` does not support `-install_name`, but CMake added it.
The folder structure:
BWAPI/ExampleAIModule/CMakeLists.txt
BWAPI/ExampleAIModule/Source/*.cpp *.h
BWAPI/include/*.h
BWAPI/lib/BWAPI.lib
BWAPI/lib/BWAPIClient.lib
`make` got errors:
Linking CXX shared library libExampleAIModule.dylib
/usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_link_script CMakeFiles/ExampleAIModule.dir/link.txt --verbose=1
i686-w64-mingw32-g++ -std=c++11 -O3 -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -o libExampleAIModule.dylib -install_name @rpath/libExampleAIModule.dylib CMakeFiles/ExampleAIModule.dir/Source/Dll.cpp.o CMakeFiles/ExampleAIModule.dir/Source/ExampleAIModule.cpp.o -L/.wine/drive_c/Starcraft/BWAPI/ExampleAIModule/../lib
i686-w64-mingw32-g++: error: rpath/libExampleAIModule.dylib: No such file or directory
i686-w64-mingw32-g++: error: unrecognized command line option ‘-install_name’
make[2]: *** [libExampleAIModule.dylib] Error 1
make[1]: *** [CMakeFiles/ExampleAIModule.dir/all] Error 2
CMakeLists.txt
cmake_minimum_required(VERSION 3.0.0 FATAL_ERROR)
set(PROJECT_NAME ExampleAIModule)
set(CPP_DIR_1 Source)
set(HEADER_DIR_1 Source)
project(${PROJECT_NAME} CXX)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
include_directories(../include)
link_directories(../lib)
file(GLOB SRC_FILES
${CPP_DIR_1}/*.cpp
${HEADER_DIR_1}/*.h
)
add_library(${PROJECT_NAME} SHARED
${SRC_FILES}
)
[1]: https://github.com/bwapi/bwapi/releases/download/v4.1.2/BWAPI_412_Setup.exehttps://gitlab.kitware.com/cmake/cmake/-/issues/17423INTERPROCEDURAL_OPTIMIZATION using Makefiles under MacOS2017-11-01T11:19:34-04:00Phillip KeldenichINTERPROCEDURAL_OPTIMIZATION using Makefiles under MacOSIn a C++ project on MacOS built using the Unix Makefiles generator, the call to check_ipo_supported seems to build a target `foo`. Building that target uses CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB; these are set to NOTFOUND.
...In a C++ project on MacOS built using the Unix Makefiles generator, the call to check_ipo_supported seems to build a target `foo`. Building that target uses CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB; these are set to NOTFOUND.
Other than this, building the entire project works fine (so CMake actually finds ar and ranlib or is, at least, able to build static and dynamic libraries and executables).
I use the following code to detect support for interprocedural optimization.
```cmake
set(_UTIL_IPO_SUPPORTED FALSE)
if(${CMAKE_MAJOR_VERSION} GREATER 2 AND ${CMAKE_MINOR_VERSION} GREATER 8)
cmake_policy(SET CMP0069 NEW)
include(CheckIPOSupported)
check_ipo_supported(RESULT _UTIL_IPO_SUPPORTED OUTPUT _UTIL_IPO_UNSUPPORTED_ERROR LANGUAGES CXX)
if(NOT _UTIL_IPO_SUPPORTED)
message(STATUS "Interprocedural/link-time optimization not supported: ${_UTIL_IPO_UNSUPPORTED_ERROR}")
endif()
endif()
```
This produces an error message that boils down to the detection script trying to run CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB, both set to NOTFOUND, resulting in a no-such-command error.
Setting CMAKE_CXX_COMPILER_AR and CMAKE_CXX_COMPILER_RANLIB manually by passing -D... to cmake works as intended - IPO detection is successful and the appropriate flags are added to all targets with the corresponding property set.Ruslan Baratovx@ruslo.devRuslan Baratovx@ruslo.devhttps://gitlab.kitware.com/cmake/cmake/-/issues/17609Getting error on building Cmake on Macintosh platform2018-01-08T11:49:02-05:00HowardGetting error on building Cmake on Macintosh platformI received the following error while installing Cmake on a Macintosh
```
Install the project...
-- Install configuration: ""
CMake Error at cmake_install.cmake:36 (file):
file cannot create directory: /usr/local/doc/cmake-3.10. Maybe...I received the following error while installing Cmake on a Macintosh
```
Install the project...
-- Install configuration: ""
CMake Error at cmake_install.cmake:36 (file):
file cannot create directory: /usr/local/doc/cmake-3.10. Maybe need
administrative privileges.
make: *** [install] Error 1
```
I then created /usr/local/doc/cmake-3.10. which was not there before and repeated the installation
```
macmatis:cmake-3.10.1 matis$ ls /usr/local/doc
cmake-3.10.
```
That did not fix the problem. I ran the installer using sudo.
How do I install cmake?https://gitlab.kitware.com/cmake/cmake/-/issues/17723CXX_STANDARD AND CMAKE_OSX_DEPLOYMENT target2018-09-13T11:28:29-04:00Tobias TaschnerCXX_STANDARD AND CMAKE_OSX_DEPLOYMENT targetWhile working in CMake files for wxWidgets (https://github.com/wxWidgets/wxWidgets/tree/master/build/cmake) I came across an issue that I think would make sense to address in CMake
When building with CXX_STANDARD 11 libc++ is required. ...While working in CMake files for wxWidgets (https://github.com/wxWidgets/wxWidgets/tree/master/build/cmake) I came across an issue that I think would make sense to address in CMake
When building with CXX_STANDARD 11 libc++ is required. When the deployment target is 10.9+ this is automatically selected. Lower deployment targets require explicit -stdlib=libc++ compile and link flags.
As setting CXX_STANDARD should automatically set required compiler flags it might make sense to automatically add this with deployment targets 10.7 - 10.8.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/8563CMake sometimes uses/detects wrong case in file paths2018-02-21T09:08:47-05:00Kitware RobotCMake sometimes uses/detects wrong case in file pathsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8563). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8563). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/17803Request: Add generator for Visual Studio 2017 Mac2018-03-27T10:41:43-04:00Robert BielikRequest: Add generator for Visual Studio 2017 MacI'm not sure if VS 2017 for Mac can read Xcode projects directly, but if not, a new generator for CMake is required.
https://www.visualstudio.com/vs/visual-studio-mac/I'm not sure if VS 2017 for Mac can read Xcode projects directly, but if not, a new generator for CMake is required.
https://www.visualstudio.com/vs/visual-studio-mac/https://gitlab.kitware.com/cmake/cmake/-/issues/17805How to let ios and macos targets in one project when generate Xcode2019-10-14T10:26:52-04:00ledaHow to let ios and macos targets in one project when generate XcodeXcode support this, but when cmake generate project every time, I have to choose ios or macos platform, can't both. is it impossible to make both in one project? How to do that. for I can't find solution in docs or google, so I came here.Xcode support this, but when cmake generate project every time, I have to choose ios or macos platform, can't both. is it impossible to make both in one project? How to do that. for I can't find solution in docs or google, so I came here.https://gitlab.kitware.com/cmake/cmake/-/issues/17847make install, also CPack, on MacOSX seem to reset a bundle directory's icon2018-03-29T17:38:32-04:00kmmake install, also CPack, on MacOSX seem to reset a bundle directory's iconI am using a command line utility (fileicon https://github.com/mklement0/fileicon) to set the image for a 'bundle' folder in MacOSX.
```
./fileicon set MyPlugin.vst image.png
```
It seems to add an Icon^M file to the root of the bund...I am using a command line utility (fileicon https://github.com/mklement0/fileicon) to set the image for a 'bundle' folder in MacOSX.
```
./fileicon set MyPlugin.vst image.png
```
It seems to add an Icon^M file to the root of the bundle with weird \r control character in it. Some kind of native MacOSX feature. Dont confuse this with "Bundle image" set in `Info.plist`, I have that set up and working if I rename the `bundle` to `MyPlugin.app`, but it's a VST Plugin for audio software, so it's named `MyPlugin.vst/` - so MacOSX doesn't use the Info.plist - so I have to resort to using an OS feature to set the image on the folder instead.
I can `cp -r` and `tar -zxvf` this bundle and the image stays on the new copy. But as soon as I `make install`, the new installed copy of the bundle no longer has the Icon set on it.
I can add post install stuff to rerun the `fileicon` command on the installed `bundle`. But then when CPack runs (DragNDrop, TGZ, or productbuild generators), it blows away the icon again.
Relevant lines from `CMakeLists.txt`:
```
# make
add_library(${PROJECT_NAME} MODULE ${SOURCES} ${RESOURCE_FILES})
set_target_properties(${PROJECT_NAME} PROPERTIES BUNDLE true BUNDLE_EXTENSION "vst")
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD
COMMAND fileicon set ${PROJECT_NAME}.vst image.png
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
COMMENT "..."
)
# make install
install(DIRECTORY "${PROJECT_NAME}.vst" DESTINATION "install" COMPONENT vstplugin)
install( SCRIPT "PostInstall.cmake" COMPONENT vstplugin)
# make package
set(CPACK_GENERATOR "DragNDrop;TGZ;productbuild")
```
Here is `PostInstall.cmake`, which is required or else `make install` will strip off the icon from the bundle folder.
```
execute_process( COMMAND fileicon set install/MyPlugin.vst image.png )
```
Running `make` generates `MyPlugin.vst` directory with the image on it, (the `add_custom_command` step sets it), looks perfect.
Running `make install` copies the bundle folder using `install( DIRECTORY`, which strips the image, so I compensate with the `PostInstall.cmake` which reruns `fileicon` script from `execute_process`. Looks Perfect. (NOTE that `install(TARGETS ${PROJECT_NAME} BUNDLE ` also strips the image from the folder, I tried that too.)
Running `make package`, the `CPack` packager generates the `.dmg`, the `.pkg`, and the `.tgz`, which strips the folder image again... But I have no way to post process this one... :-(
Any ideas why `CMake` `install` and `package` is stripping the image? (and how to get them to not do that?)
---
Attached files:
[CMakePackage.txt](/uploads/577288b84681abd8b2aeeeb98549726a/CMakePackage.txt)
[CMakeLists.txt](/uploads/c4bd7e9bb943fb95cfd6aa4f5829cfc6/CMakeLists.txt)
[CMakePostInstall.cmake](/uploads/ee59afeb4f56b46266dfa650316d5950/CMakePostInstall.cmake)
[fileicon](/uploads/c80ae4aad4531e9ce0abdb848c1052d4/fileicon)https://gitlab.kitware.com/cmake/cmake/-/issues/17877OSX "Argument list too long" error using Ninja generator2018-06-22T09:16:38-04:00Willem DeconinckOSX "Argument list too long" error using Ninja generatorOn OSX, I receive an "Argument list too long" error during a link target using Fortran and the Ninja generator.
Over 4000 object files need to be linked in one library.
When using the Unix Makefile generator on OSX, response files are cr...On OSX, I receive an "Argument list too long" error during a link target using Fortran and the Ninja generator.
Over 4000 object files need to be linked in one library.
When using the Unix Makefile generator on OSX, response files are created, which alleviates this problem. These files don't seem to be created using Ninja on OSX
Following two files show the truncated output of the linking step for Ninja and Make respectively.
[build-ninja.log](/uploads/6fd66f100ad2d46a1a73014009521369/build-ninja.log)
[build-make.log](/uploads/b7f8097e09140eaa28ff3b16dafad8df/build-make.log)
I tried `export CMAKE_NINJA_FORCE_RESPONSE_FILE=1` but then I got a CMake error that the Fortran compiler (gfortran) could not compile a simple program during the configure stage.
cmake version 3.11.0-rc2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/15820Generalize support for Apple Info.plist generation2021-05-30T05:17:59-04:00Kitware RobotGeneralize support for Apple Info.plist generationThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15820). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15820). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/11534PackageMaker install location customization is too restricted2018-04-28T09:16:22-04:00Kitware RobotPackageMaker install location customization is too restrictedThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11534). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11534). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/12423cmake -G"Unix Makefiles" .. : make causes linker-error when executed on netwo...2018-04-28T09:16:22-04:00Kitware Robotcmake -G"Unix Makefiles" .. : make causes linker-error when executed on network driveThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12423). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=12423). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/10342Mac OsX: Common symbols of c static librarties are not exported2018-04-28T09:16:23-04:00Kitware RobotMac OsX: Common symbols of c static librarties are not exportedThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=10342). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=10342). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/9845Segmentation fault when using hgfs2018-04-28T09:16:24-04:00Kitware RobotSegmentation fault when using hgfsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9845). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9845). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/8756CPack PackageMaker generator should use PackageMaker 3 syntax where possible2018-04-28T09:16:26-04:00Kitware RobotCPack PackageMaker generator should use PackageMaker 3 syntax where possibleThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8756). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8756). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/8272FindwxWidgets: doesn't support universal binaries properly2018-04-28T09:16:26-04:00Kitware RobotFindwxWidgets: doesn't support universal binaries properlyThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8272). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8272). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/7250CMAKE_SHARED_LINKER_FLAGS ignored when building Frameworks on MacOSX2018-04-28T09:16:27-04:00Kitware RobotCMAKE_SHARED_LINKER_FLAGS ignored when building Frameworks on MacOSXThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=7250). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=7250). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/7811Allow to set architectues of a target2018-04-28T09:16:27-04:00Kitware RobotAllow to set architectues of a targetThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=7811). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=7811). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/5139find_path seems to not work correctly on Mac OS X2018-04-28T09:16:27-04:00Kitware Robotfind_path seems to not work correctly on Mac OS XThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=5139). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=5139). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/6057Patch to make it easier to ignore the OpenGL framework on Mac OS X2018-04-28T09:16:27-04:00Kitware RobotPatch to make it easier to ignore the OpenGL framework on Mac OS XThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=6057). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=6057). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/18179[OS X] Using `INSTALL_RPATH` target property does not appear apply to target ...2018-11-30T12:57:34-05:00Sylvain Corlay[OS X] Using `INSTALL_RPATH` target property does not appear apply to target `CMAKE_INSTALL_RPATH` works as expectedThis forces us to do
```cmake
set_target_properties(${TARGET} PROPERTIES
MACOSX_RPATH ON
BUILD_WITH_INSTALL_RPATH 1
)
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib; ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}")
```
i...This forces us to do
```cmake
set_target_properties(${TARGET} PROPERTIES
MACOSX_RPATH ON
BUILD_WITH_INSTALL_RPATH 1
)
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib; ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}")
```
instead of
```cmake
set_target_properties(${TARGET} PROPERTIES
MACOSX_RPATH ON
BUILD_WITH_INSTALL_RPATH 1
INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib; ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}"
)
```
which would be cleaner.https://gitlab.kitware.com/cmake/cmake/-/issues/18201Productbuild generator makes empty final pkg file (no needed sections in dist...2023-01-19T13:16:00-05:00RuslanProductbuild generator makes empty final pkg file (no needed sections in distribution.dist file)Platform: macOS 10.13.2
CMake: 3.11.1Platform: macOS 10.13.2
CMake: 3.11.1https://gitlab.kitware.com/cmake/cmake/-/issues/18753Linking to OSX frameworks does not work2023-02-19T03:07:56-05:00Alexander GrundLinking to OSX frameworks does not workYou can do e.g. `find_library(SDL2LIB SDL2)` and it may return the framework (e.g. `/usr/lib/apple/SDKs/MacOSX10.11.sdk/Library/Frameworks/SDL2.framework`)
According to the docu:
> If the library found is a framework, then <VAR> wi...You can do e.g. `find_library(SDL2LIB SDL2)` and it may return the framework (e.g. `/usr/lib/apple/SDKs/MacOSX10.11.sdk/Library/Frameworks/SDL2.framework`)
According to the docu:
> If the library found is a framework, then <VAR> will be set to the full path to the framework <fullPath>/A.framework. When a full path to a framework is used as a library, CMake will use a -framework A, and a -F<fullPath> to link the framework to the target.
However this is not happening. I was just compiling a library linked against the above and it tries to link against that folder. No `-framework` is added.
Searching through the CMake code I could find some handling of that case but it doesn't work here. Using 3.13.2.https://gitlab.kitware.com/cmake/cmake/-/issues/19180macOS: update defaults not unwrap /usr/bin/{cc,c++} and not use -isysroot2023-05-25T10:56:39-04:00Brad KingmacOS: update defaults not unwrap /usr/bin/{cc,c++} and not use -isysrootOn macOS we currently resolve `/usr/bin/{cc,c++}` to whatever `xcrun` says they use underneath (see commit 1f085e11e40a20f8e8702da7920e950e47deb27c). The idea is that those real compiler paths remain stable even if `xcode-select` is use...On macOS we currently resolve `/usr/bin/{cc,c++}` to whatever `xcrun` says they use underneath (see commit 1f085e11e40a20f8e8702da7920e950e47deb27c). The idea is that those real compiler paths remain stable even if `xcode-select` is used to change the default. This has the effect of making `-isysroot` required for normal builds, which has not been problematic on its own because we've long required `CMAKE_OSX_SYSROOT` to be set anyway. At one time even `/usr/bin/{cc,c++}` required `-isysroot`, which is why `CMAKE_OSX_SYSROOT` is always used.
Discussion in issues #19120 and #19134 identified that using `-isysroot` causes paths under `/usr/local` to no longer be considered system directories. This differs from the normal behavior of `/usr/bin/{cc,c++}` when run by hand.
**Since `-isysroot` is no longer required by `/usr/bin/{cc,c++}` we should consider changing our defaults back to using those compilers directly and not using `-isysroot` unless `CMAKE_OSX_SYSROOT` is explicitly set by the user.**
Achieving this will also mean we can no longer resolve `/usr/bin/{cc,c++}` to the underlying compiler paths, meaning that we will require users to keep `DEVELOPER_DIR` stable across all uses of `/usr/bin/{cc,c++}` in a given build tree. Since our Makefile and Ninja generators require a stable environment anyway that is not a big deal.https://gitlab.kitware.com/cmake/cmake/-/issues/19315dyld: Library not loaded: libboost_filesystem.dylib Referenced from: ...Rea...2021-02-19T05:06:06-05:00Arthur Andersondyld: Library not loaded: libboost_filesystem.dylib Referenced from: ...Reason: image not foundWhen I build main with dynamic link to boost log. I get
````
dyld: Library not loaded: libboost_filesystem.dylib
Referenced from: /Users/arthuranderson/Documents/work/edx/algo/cmake-build-debug/algo_main
Reason: image not found.
``...When I build main with dynamic link to boost log. I get
````
dyld: Library not loaded: libboost_filesystem.dylib
Referenced from: /Users/arthuranderson/Documents/work/edx/algo/cmake-build-debug/algo_main
Reason: image not found.
````
I am expecting main to build and run.
Environment:
````
OS: OSX 10.14.2
XCode: 10.1
algo/
cmake/
CMakeList.Boost.txt.in
src/
main.cpp
test/
versionUnitTests.cpp
CMakeLists.txt
````
Boost is brought in using ExternalProject_add.
It downloads, extracts and builds all the libs needed. They show up correctly in the CMakeCache.txt.
The build and download happens in the CMAKE_CURRENT_BINARY_DIR
The libraries are located in CMAKE_CURRENT_BINARY_DIR/boost/lib
CMakelist.Boost.txt.in contents are...
````
cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
#---------------------------------------------------------------------------
# Get and build boost
include(ExternalProject)
message("----- building boost ----")
message( ${CMAKE_BUILD_TYPE})
ExternalProject_Add(Boost
URL https://dl.bintray.com/boostorg/release/1.70.0/source/boost_1_70_0.tar.bz2
URL_HASH SHA256=430ae8354789de4fd19ee52f3b1f739e1fba576f0aded0897c3c2bc00fb38778
PREFIX ${CMAKE_CURRENT_BINARY_DIR}/boost
UPDATE_COMMAND ""
LOG_DIR ${CMAKE_CURRENT_BINARY_DIR}/boost-log
DOWNLOAD_DIR ${CMAKE_CURRENT_BINARY_DIR}/boost-download
SOURCE_DIR ${CMAKE_CURRENT_BINARY_DIR}/boost-src
BUILD_IN_SOURCE 1
CONFIGURE_COMMAND ${CMAKE_CURRENT_BINARY_DIR}/boost-src/bootstrap.sh --prefix=${CMAKE_CURRENT_BINARY_DIR}/boost
BUILD_COMMAND ./b2 install variant=debug -j8 link=shared --with-filesystem --with-system --with-date_time --with-thread --with-regex --with-log
INSTALL_COMMAND ""
TEST_COMMAND ""
LOG_DOWNLOAD 1
LOG_CONFIGURE 1
LOG_BUILD 1
LOG_INSTALL 1
LOG_LOG_MERGED_STDOUTERR 1
)
````
The CMakeLists.txt that uses this in configure_file
````
cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
cmake_policy(SET CMP0048 NEW)
project(algo_main VERSION 0.1.1 )
set(CMAKE_CXX_STANDARD 14)
# Boost
set(Boost_DEBUG 1)
configure_file(cmake/CMakeList.Boost.txt.in boost-download/CMakeLists.txt)
execute_process(COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" .
RESULT_VARIABLE result
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/boost-download)
if (result)
message(FATAL_ERROR "CMake step for googletest failed: ${result}")
endif ()
execute_process(COMMAND ${CMAKE_COMMAND} --build .
RESULT_VARIABLE result
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/boost-download)
if (result)
message(FATAL_ERROR "Build step for boost failed: ${result}")
endif ()
set(BOOST_ROOT ${CMAKE_CURRENT_BINARY_DIR}/boost )
find_package(Boost 1.70.0 EXACT REQUIRED COMPONENTS filesystem system date_time thread regex log)
# VERSION
configure_file(src/version/version_defs.h.in generated/version_defs.h @ONLY)
add_executable(algo_main
src/main.cpp src/version/Version.cpp src/util/Logger.cpp src/util/Logger.h)
target_include_directories(algo_main
PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/generated )
if( Boost_FOUND )
target_include_directories(algo_main
PRIVATE ${Boost_INCLUDE_DIR})
target_link_libraries(algo_main ${Boost_LIBRARIES})
target_link_directories(algo_main
PRIVATE ${Boost_LIBRARY_DIR})
endif( Boost_FOUND )
````
I think this maybe related to another post, where they found that xcode could not find libraries that were not installed in the global location.
Any suggestions could help. I would rather stay away from installing in /usr/local/bin and keep the libraries local to the project.
Thanks
Arthurhttps://gitlab.kitware.com/cmake/cmake/-/issues/19410FindGDAL outputs the wrong case library name (MacOS)2023-08-24T16:33:53-04:00Federico FugaFindGDAL outputs the wrong case library name (MacOS)When running FindGDAL the wrong GDAL_LIBRARY is produced.
This affects both the 3.14 then previous versions too.
```
Version: 2.4.1
Headers: /Library/Frameworks/GDAL.framework/Headers
Library: /Library/Frameworks/gdal.framework
```
...When running FindGDAL the wrong GDAL_LIBRARY is produced.
This affects both the 3.14 then previous versions too.
```
Version: 2.4.1
Headers: /Library/Frameworks/GDAL.framework/Headers
Library: /Library/Frameworks/gdal.framework
```
the correct path should be `GDAL.framework`.
```
happycactus:TestGdalBugMacOS HappyCactus$ ls -ld /Library/Frameworks/[Gg][Dd]*
drwxrwxr-x 8 root admin 256 Jun 13 11:06 /Library/Frameworks/GDAL.framework
```
For this reason, even a simple project can't link:
```
[ 50%] Linking CXX executable TestGdalBugMacOS
"/Users/happycactus/Library/Application Support/JetBrains/Toolbox/apps/CLion/ch-0/191.7479.33/CLion.app/Contents/bin/cmake/mac/bin/cmake" -E cmake_link_script CMakeFiles/TestGdalBugMacOS.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/TestGdalBugMacOS.dir/main.cpp.o -o TestGdalBugMacOS /Library/Frameworks/gdal.framework
ld: can't map file, errno=22 file '/Library/Frameworks/gdal.framework' for architecture x86_64
```
This was tested with 3.14 (to support Imported targets) but it affects also 3.13 and 3.12 (though I'm unsure of the version). MACOS ONLY. It works fine on Linux.
[main.cpp](/uploads/ab317ca77aa106d50dcaba51d317a06d/main.cpp)[CMakeLists.txt](/uploads/9874c9cb0b2d92358ad6f21c684e747c/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/19442MACOSX_BUNDLE_INFO_PLIST regression?2019-09-19T14:41:38-04:00Sander StoksMACOSX_BUNDLE_INFO_PLIST regression?The MACOSX_BUNDLE_INFO_PLIST override doesn't seem to work anymore in CMake 3.14. I noticed that after upgrading my local CMake from 3.9.1 to 3.14, the Mac app I wrote using Qt suddenly had awful font rendering. This is solved by addin...The MACOSX_BUNDLE_INFO_PLIST override doesn't seem to work anymore in CMake 3.14. I noticed that after upgrading my local CMake from 3.9.1 to 3.14, the Mac app I wrote using Qt suddenly had awful font rendering. This is solved by adding
<key>NSPrincipalClass</key>
<string>NSApplication</string>
to the info.plist file. (see also https://stackoverflow.com/questions/34465506/retina-support-in-qt5-on-os-x).
However, info.plist is generated from MacOSXBundleInfo.plist.in, which I had already added to my own source archive and pointed MACOSX_BUNDLE_INFO_PLIST to it. This no longer works. I verified this by renaming the MacOSXBundleInfo.plist.in in /Applications/CMake.app/Contents/share/cmake-3.14/Modules/, after which I got the error that it could no longer be found.
I was able to work around the issue by editing the template directly in the CMake install location (since I'm admin on my own machine), but this is obviously not ideal.
I'm not sure in which version between 3.9.1 and 3.14 this functionality broke.https://gitlab.kitware.com/cmake/cmake/-/issues/19517CPack fails to detach volume on Macos.2022-10-31T21:04:06-04:00UkalninsCPack fails to detach volume on Macos.During creation of installation dmg it may fail to detach the dmg file. This happends randomly, but on some systems with up to 90% probabilty. Output:
```
CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Install pro...During creation of installation dmg it may fail to detach the dmg file. This happends randomly, but on some systems with up to 90% probabilty. Output:
```
CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Install project: TEST
CPack: Create package
CPack Error: Error executing: /usr/bin/hdiutil detach "/Volumes/Test"
CPack Error: Error detaching temporary disk image.
CPack Error: Problem compressing the directory
CPack Error: Error when generating package: Test
make: *** [package_buildpart_0] Error 1
```
Buy running Instrumentation during the build process it was detected that it will fail to detach if `iconserviceagent` accesses the drive at the last second (none of the successful runs contained `iconserviceagent` and all failed did contain). My hypothesis is that after the icon is set, the `iconserviceagent` swoops in to cache the icon at the same time as CPack tries to detach the volume.
It seems that the multiple tries of detach should be tried before giving up.https://gitlab.kitware.com/cmake/cmake/-/issues/19624macOS: MACOSX_PACKAGE_LOCATION source file property broken for '.obj' files2019-08-22T14:11:46-04:00moritzpetermacOS: MACOSX_PACKAGE_LOCATION source file property broken for '.obj' filesHey all,
I am on macOS 10.13.6 with cmake 3.15.2
I am trying to add resources to a osx app bundle with
`file(GLOB Res_Files "${Res_DIR}/*.*")`
`set_source_files_properties(${Res_Files} PROPERTIES MACOSX_PACKAGE_LOCATION Resources)`
...Hey all,
I am on macOS 10.13.6 with cmake 3.15.2
I am trying to add resources to a osx app bundle with
`file(GLOB Res_Files "${Res_DIR}/*.*")`
`set_source_files_properties(${Res_Files} PROPERTIES MACOSX_PACKAGE_LOCATION Resources)`
This works perfect with e.g. *.png files and others. But for example it does not work for *.obj (3D model) files.
Can anybody reproduce this?
Is this a bug or a feature?
Best regards
Moritzhttps://gitlab.kitware.com/cmake/cmake/-/issues/19666RunCMake.CommandLineTar: pax-zstd - FAILED2021-08-24T09:53:02-04:00Gregor JasnyRunCMake.CommandLineTar: pax-zstd - FAILEDHello,
the `RunCMake.CommandLineTar: pax-zstd` test fails on macOS 10.14 and 10.15 when built against local libarchive (3.3.3) and zstd (1.4.3):
```
brew install curl expat jsoncpp libarchive rhash libuv xz zstd
cmake .. -GNinja -DCMA...Hello,
the `RunCMake.CommandLineTar: pax-zstd` test fails on macOS 10.14 and 10.15 when built against local libarchive (3.3.3) and zstd (1.4.3):
```
brew install curl expat jsoncpp libarchive rhash libuv xz zstd
cmake .. -GNinja -DCMAKE_USE_SYSTEM_LIBRARIES=ON -DLibArchive_ROOT=$(brew --prefix libarchive)
ctest -V -R CommandLineTar
```
It fails with:
```
462: actual-err> CMake Error: archive_write_header: INTERNAL ERROR: Function 'archive_write_header' invoked with archive structure in state 'new', should be in state 'header/data'
462: actual-err> CMake Error: Problem creating tar: /Users/gregorj/Git/cmake/_build/Tests/RunCMake/CommandLineTar/pax-zstd-build/test.tar.zstd
462: actual-err> CMake Error at roundtrip.cmake:14 (message):
462: actual-err> tar failed with arguments
462: actual-err> [cvf;/Users/gregorj/Git/cmake/_build/Tests/RunCMake/CommandLineTar/pax-zstd-build/test.tar.zstd;--format=pax;--zstd;compress_dir]
462: actual-err> result [1]
462: actual-err> Call Stack (most recent call first):
462: actual-err> roundtrip.cmake:49 (run_tar)
462: actual-err> pax-zstd.cmake:8 (include)
462: actual-err> CMakeLists.txt:3 (include)
```
The same test works when CMake is built against bundled dependencies.https://gitlab.kitware.com/cmake/cmake/-/issues/19973CPack + productbuild + install_name_tool: no LC_RPATH load command with path2020-03-25T15:29:18-04:00RomanCPack + productbuild + install_name_tool: no LC_RPATH load command with pathWhen i try to package an app under macOS with productbuild I get the following error with CPack 3.15.4: "error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: no LC_RPATH load co...When i try to package an app under macOS with productbuild I get the following error with CPack 3.15.4: "error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: no LC_RPATH load command with path: /opt/Qt/5.11.3/clang_64/lib found in" "(for architecture x86_64), required for specified option "-delete_rpath /opt/Qt/5.11.3/clang_64/lib""
The path "/opt/Qt/5.11.3/clang_64/lib" exist
I already tried Xcode 10.3 and Xcode 11.2.1https://gitlab.kitware.com/cmake/cmake/-/issues/20461Swift: building macOS fails, unable to load standard library for target 'x86_...2020-03-30T16:12:39-04:00Adrian ZimmermannSwift: building macOS fails, unable to load standard library for target 'x86_64-apple-macosx10.14'When I try to build this project: [https://github.com/compnerd/swift-build-examples/tree/master/HelloMinimal-CMake](https://github.com/compnerd/swift-build-examples/tree/master/HelloMinimal-CMake)
the following errors occurs during the ...When I try to build this project: [https://github.com/compnerd/swift-build-examples/tree/master/HelloMinimal-CMake](https://github.com/compnerd/swift-build-examples/tree/master/HelloMinimal-CMake)
the following errors occurs during the compiler test:
```
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc -target x86_64-apple-macosx10.14 -output-file-map CMakeFiles/cmTC_a3200.dir/output-file-map.json -incremental -j 12 -emit-executable -o cmTC_a3200 -emit-module -emit-module-path cmTC_a3200.swiftmodule -emit-dependencies main.swift && :
<unknown>:0: error: unable to load standard library for target 'x86_64-apple-macosx10.14'`
```
After including `set(CMAKE_Swift_COMPILER_WORKS True)` before project()
and applying this fix (-sdk option): [https://gitlab.kitware.com/cmake/cmake/issues/19880](https://gitlab.kitware.com/cmake/cmake/issues/19880)
this is the output:
```
FAILED: libHiKit.a CMakeFiles/HiKit.dir/hikit.swift.o HiKit.swiftmodule
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -target x86_64-apple-macosx10.15 -output-file-map CMakeFiles/HiKit.dir/output-file-map.json -incremental -j 12 -emit-library -static -o libHiKit.a -module-name HiKit -module-link-name HiKit -emit-module -emit-module-path HiKit.swiftmodule -emit-dependencies -O -g ../hikit.swift && :
error: cannot parse the debug map for 'libHiKit.a': The file was not recognized as a valid object file
<unknown>:0: error: generate-dSYM command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
```
https://gitlab.kitware.com/cmake/cmake/-/issues/20462MacPorts can't build current CMake on PPC Mac OS X 10.5.82020-03-16T10:23:21-04:00Rolf Eike BeerMacPorts can't build current CMake on PPC Mac OS X 10.5.8I just happened to notice that this one exists: https://trac.macports.org/ticket/59832
For me it looks like their toolchain is somewhat screwed, but maybe someone here has the possibility to somewhat ease their pain.I just happened to notice that this one exists: https://trac.macports.org/ticket/59832
For me it looks like their toolchain is somewhat screwed, but maybe someone here has the possibility to somewhat ease their pain.https://gitlab.kitware.com/cmake/cmake/-/issues/20488Errors / imperfections in bundle Info.plist template (MacOSXBundleInfo.plist.in)2020-03-23T07:17:00-04:00Itai SeggevErrors / imperfections in bundle Info.plist template (MacOSXBundleInfo.plist.in)The template MacOSXBundleInfo.plist.in has one definite error and some questionable other fields in it
Error: It hard-codes CFBundlePackageType to APPL (application). However, since it is also used for loadable bundles (module librarie...The template MacOSXBundleInfo.plist.in has one definite error and some questionable other fields in it
Error: It hard-codes CFBundlePackageType to APPL (application). However, since it is also used for loadable bundles (module libraries with the BUNDLE property), that should be templated and be BNDL for those targets
Questionable 1: It hardcodes English for CFBundleDevelopmentRegion. This should pretty clearly be settable. Also, Apple has for quite some time recommended that you use ISO codes as as 'en' instead of 'English'.
Questionable 2: It has a field for CFBundleLongVersionString. This field is so obsolete it is not even documented on Apples old documentation, much less its current documentation, and it is not used by the system. Does it really need to be included?
Questionable 3: It includes both the obsolete CFBundleGetInfoString and its recommended replacement NSHumanReadableCopyright. Do we really still need to have both?https://gitlab.kitware.com/cmake/cmake/-/issues/20782On macOS setting VERSION and/or SOVERSION on MODULE library breaks build2021-02-18T16:04:59-05:00PaulOn macOS setting VERSION and/or SOVERSION on MODULE library breaks buildOn macOS `MODULE` library creates Mach-O binary of type `MH_BUNDLE` (by using `-bundle` linker options).
Also on macOS setting properties `VERSION` and `SOVERSION` on `MODULE` target adds linker flags `-current_version` and `-compatibili...On macOS `MODULE` library creates Mach-O binary of type `MH_BUNDLE` (by using `-bundle` linker options).
Also on macOS setting properties `VERSION` and `SOVERSION` on `MODULE` target adds linker flags `-current_version` and `-compatibility_version`. However, `-current_version` and `-compatibility_version` can be used only for `-dylib` binaries (i.e. CMake `SHARED` libraries). Thus, the following code fails to build:
```
add_library(foo MODULE)
set_property(TARGET foo PROPERTY VERSION 1.0)
set_property(TARGET foo PROPERTY SOVERSION 1.0)
```
CMake should not try to set `-current_version` and/or `-compatibility_version` for `MODULE` target when user sets `VERSION` and/or `SOVERSION` properties on it.https://gitlab.kitware.com/cmake/cmake/-/issues/20871Different framework linking behaviors2023-06-02T06:27:52-04:00alcroitoDifferent framework linking behaviorsThere seems to be some differences and minor inconveniences in how mac framework linking happens.
Here's a sample project to demonstrate them:
```cmake
cmake_minimum_required(VERSION 3.15.0)
project(cmake_macos_framework_linkage LANGUA...There seems to be some differences and minor inconveniences in how mac framework linking happens.
Here's a sample project to demonstrate them:
```cmake
cmake_minimum_required(VERSION 3.15.0)
project(cmake_macos_framework_linkage LANGUAGES CXX)
find_library(FWAppKit NAMES AppKit)
find_library(FWAVFoundation NAMES AVFoundation)
find_library(FWCoreFoundation NAMES CoreFoundation)
find_library(FWCoreText NAMES CoreText)
message(">>>> find_library(AppKit): ${FWAppkit}")
message(">>>> find_library(AVFoundation): ${FWAVFoundation}")
message(">>>> find_library(CoreFoundation): ${FWCoreFoundation}")
message(">>>> find_library(CoreText): ${FWCoreText}")
add_library(AppKit::AppKit SHARED IMPORTED)
set_target_properties(AppKit::AppKit PROPERTIES
IMPORTED_LOCATION "${FWAppKit}/AppKit.tbd") # How do i know it should have a .tbd suffix?
#set_target_properties(AppKit::AppKit PROPERTIES
# IMPORTED_LOCATION "${FWAppKit}") # Not actual file, won't work.
add_library(AVFoundation::AVFoundation INTERFACE IMPORTED)
set_target_properties(AVFoundation::AVFoundation PROPERTIES
INTERFACE_LINK_LIBRARIES "${FWAVFoundation}")
set(source_path "${CMAKE_CURRENT_BINARY_DIR}/main.cpp")
file(GENERATE OUTPUT "${source_path}" CONTENT "int main(int argc, char**argv) {return 0;}")
add_executable(app "${source_path}")
target_link_libraries(app PRIVATE AVFoundation::AVFoundation)
target_link_libraries(app PRIVATE AppKit::AppKit)
target_link_libraries(app PRIVATE "${FWCoreFoundation}")
target_link_libraries(app PRIVATE "${FWCoreText}/CoreText.tbd")
```
```
$ cmake .. -GNinja
>>>> find_library(AppKit): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/AppKit.framework
>>>> find_library(AVFoundation): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/AVFoundation.framework
>>>> find_library(CoreFoundation): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework
>>>> find_library(CoreText): /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreText.framework
-- Configuring done
-- Generating done
$ ninja clean && ninja -v
# ...
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
-Wl,-search_paths_first
-Wl,-headerpad_max_install_names
CMakeFiles/app.dir/main.cpp.o -o app
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/AppKit.framework/AppKit.tbd
-framework CoreFoundation
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreText.framework/CoreText.tbd
-framework AVFoundation
```
The above project finds 4 frameworks, and uses them:
- via an imported target with `IMPORTED_LOCATION`
- via an imported target with `INTERFACE_LINK_LIBRARIES`,
- directly links the result of `find_library` with `target_link_libraries` with full framework path
- directly links the result of `find_library` with `target_link_libraries` with full library path within framework
The observed behaviour is that `INTERFACE_LINK_LIBRARIES` and `target_link_libraries` with a framework path end up using a `-framework` flag, and the others directly link to a file by absolute path.
Afaik these differences are not documented anywhere.
One inconvenience is that using `IMPORTED_LOCATION` with a full library path can't generally be known because the file might be a true mach-o library, or have a `.tbd` suffix. You have to do a manual `if(EXISTS "Foo.tbd")`, and populate the `IMPORTED_LOCATION` property accordingly.
Another inconvenience is that if a Find module creates an imported target that uses `IMPORTED_LOCATION` instead of `INTERFACE_LINK_LIBRARIES`, it's not possible to link via a `-framework flag` instead of the absolute file path (an example of this is the CMake `FindGL.cmake` find module). It would be nice if this were somehow configurable.https://gitlab.kitware.com/cmake/cmake/-/issues/20896macOS: Installation of app bundles should be smarter than install(DIRECTORY)2020-07-01T10:08:00-04:00Ben BoeckelmacOS: Installation of app bundles should be smarter than install(DIRECTORY)Currently, installing an application bundle boils down to an `install(DIRECTORY)`. This may copy build-tree-specific files which need to be in the bundle for build-tree usage. Instead, CMake should install only the application itself and...Currently, installing an application bundle boils down to an `install(DIRECTORY)`. This may copy build-tree-specific files which need to be in the bundle for build-tree usage. Instead, CMake should install only the application itself and the `Info.plist` file.
This causes problems because attempts to overwrite the build-tree bundle copy of a file may be thwarted by commit 4e514a5e0009823a07ad9db0552c7b424b0a6 (tags/v2.6.0~583, see #3349). In addition, any binaries which may be in there for other reasons are not updated for install name dirs or install rpaths.
This likely requires a policy in case anyone was relying on the existing bundle installation to copy these files around.
Cc: @kyle.edwards @brad.kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21189macOS: CMAKE_SHARED_MODULE_SUFFIX .so versus .dylib2021-06-20T11:39:41-04:00Marcus JohnsonmacOS: CMAKE_SHARED_MODULE_SUFFIX .so versus .dylibit should be .dylib, but it's .so like all other unix oses.
I'm on 3.18.2it should be .dylib, but it's .so like all other unix oses.
I'm on 3.18.2https://gitlab.kitware.com/cmake/cmake/-/issues/21436Issues with Swift CMAKE_TRY_COMPILE for Mac Catalyst targets2021-01-14T18:28:27-05:00Chris BallingerIssues with Swift CMAKE_TRY_COMPILE for Mac Catalyst targetsRelated issue: https://gitlab.kitware.com/cmake/cmake/-/issues/20132
The issue here is that the second `-target x86_64-apple-macos10.12` flag (coming from somewhere unknown) is overriding the `-target x86_64-apple-ios13.0-macabi` we are...Related issue: https://gitlab.kitware.com/cmake/cmake/-/issues/20132
The issue here is that the second `-target x86_64-apple-macos10.12` flag (coming from somewhere unknown) is overriding the `-target x86_64-apple-ios13.0-macabi` we are passing in `CMAKE_Swift_FLAGS` (which translates to `OTHER_SWIFT_FLAGS` in Xcode).
See in log below:
```
CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (in target 'cmTC_15e27' from project 'CMAKE_TRY_COMPILE')
cd /Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp
export DEVELOPER_DIR\=/Applications/Xcode-12.1.1.app/Contents/Developer
export SDKROOT\=/Applications/Xcode-12.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
/Applications/Xcode-12.1.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc -incremental -module-name cmTC_15e27 -O -enable-batch-mode -enforce-exclusivity\=checked @/Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/Objects-normal/x86_64/cmTC_15e27.SwiftFileList -target x86_64-apple-ios13.0-macabi -sdk /Applications/Xcode-12.1.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -target x86_64-apple-macos10.12 -g -module-cache-path /Users/chrisbal/Library/Developer/Xcode/DerivedData/ModuleCache.noindex -Xfrontend -serialize-debugging-options -swift-version 4 -I /Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/Debug -F /Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/Debug -c -j12 -output-file-map /Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/Objects-normal/x86_64/cmTC_15e27-OutputFileMap.json -parseable-output -serialize-diagnostics -emit-dependencies -emit-module -emit-module-path /Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/Objects-normal/x86_64/cmTC_15e27.swiftmodule -Xcc -I/Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/swift-overrides.hmap -Xcc -I/Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/Debug/include -Xcc -I/Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/DerivedSources-normal/x86_64 -Xcc -I/Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/DerivedSources/x86_64 -Xcc -I/Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/DerivedSources -Xcc -DCMAKE_INTDIR\=\"Debug\" -emit-objc-header -emit-objc-header-path /Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp/CMAKE_TRY_COMPILE.build/Debug/cmTC_15e27.build/Objects-normal/x86_64/cmTC_15e27-Swift.h -working-directory /Users/chrisbal/Documents/opencv-build/build/build-x86_64-catalyst/modules/objc/framework_build/CMakeFiles/CMakeTmp
```
What is possibly a related issue, is that it's not valid to make command line tools for iOS-style targets (like Catalyst), which is what this `CMAKE_TRY_COMPILE` project is doing.
I even tried forcing the target destination to `platform=macOS,arch=x86_64,variant=Mac Catalyst`, but it didn't have any effect:
```
$ xcodebuild -project CMAKE_TRY_COMPILE.xcodeproj/ -destination 'platform=macOS,arch=x86_64,variant=Mac Catalyst' build
```
I've attached the `CMAKE_TRY_COMPILE.xcodeproj` as CMakeTmp.zip below, which may help diagnosing this issue.
[CMakeError.log](/uploads/1f0d66248466d0d93264909138e030f0/CMakeError.log)
[CMakeOutput.log](/uploads/11261f3a26fdb5d84bf2192deaa268dd/CMakeOutput.log)
[CMakeTmp.zip](/uploads/1b2467e514f975ceafdb40d02495784e/CMakeTmp.zip)
You can reproduce with the following (see [WIP PR here](https://github.com/Rightpoint/opencv/pull/3)):
```
$ git clone https://github.com/Rightpoint/opencv.git
$ cd opencv
$ git checkout feature/chrisballinger/build-catalyst-xcframework
$ python3 platforms/osx/build_framework.py --catalyst_archs x86_64 --build-only-specified-archs ../opencv-build/
```
In the meantime I am going to try working around the issue by not overriding `CMAKE_EXE_LINKER_FLAGS` (which includes passing `-target x86_64-apple-ios13.0-macabi` to `LDFLAGS`) and injecting that manually via the `xcodebuild` command after CMake has finished project generation.https://gitlab.kitware.com/cmake/cmake/-/issues/21454FortranCInterface: Detection fails on macOS 11 with Homebrew GCC 102021-06-21T07:59:30-04:00Ron RahamanFortranCInterface: Detection fails on macOS 11 with Homebrew GCC 10A follow-up from [Discourse](https://discourse.cmake.org/t/verifying-fortran-c-compiler-fails/2183). I've attached a tarball of the `CMakeLists/` for a tiny project that demonstrates the problem: [CMakeFiles.tar.gz](/uploads/38171d0f...A follow-up from [Discourse](https://discourse.cmake.org/t/verifying-fortran-c-compiler-fails/2183). I've attached a tarball of the `CMakeLists/` for a tiny project that demonstrates the problem: [CMakeFiles.tar.gz](/uploads/38171d0f5b6f22a3f4afc125bc1b0a69/CMakeFiles.tar.gz)
`FortranCInterface_VERIFY` isn’t working on my Mac after an OS and compiler updates. I’m running on macOS 11 with gcc-10 from Homebrew and cmake 3.18. Here are some of the relevant errors from stdout:
```
-- Detecting Fortran/C Interface
Failed to compile
-- Verifying Fortran/C Compiler Compatibility
Failed to compile
CMake Warning (dev) at /usr/local/Cellar/cmake/3.18.4/share/cmake/Modules/FortranCInterface.cmake:309 (message):
No FortranCInterface mangling known for VerifyFortran
Call Stack (most recent call first):
/usr/local/Cellar/cmake/3.18.4/share/cmake/Modules/FortranCInterface/Verify/CMakeLists.txt:16 (FortranCInterface_HEADER)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Verifying Fortran/C Compiler Compatibility - Failed
CMake Error at /usr/local/Cellar/cmake/3.18.4/share/cmake/Modules/FortranCInterface.cmake:383 (message):
The Fortran compiler:
/usr/local/bin/gfortran-10
and the C compiler:
/usr/local/bin/gcc-10
failed to compile a simple test project using both languages. The output
was:
****** A BUNCH OF STUFF ****
/usr/local/bin/gcc-10 -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/VerifyFortranC.dir/main.c.o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o -o VerifyFortranC libVerifyFortran.a -lgfortran -lquadmath -lm
ld: warning: ignoring file libVerifyFortran.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture x86_64:
"_VerifyFortran", referenced from:
_main in main.c.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
```
I did some detective work as saw that the name-mangling was indeed wrong.
```
$ nm CMakeFiles/FortranCInterface/VerifyC/libVerifyFortran.a
VerifyFortran.f.o:
00000000000000d0 r EH_frame1
U __gfortran_st_write
U __gfortran_st_write_done
U __gfortran_transfer_character_write
0000000000000000 T _verifyfortran_
0000000000000058 r lC0
00000000000000c8 r lC1
00000000000000b8 r lC2
$ nm CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortranC.dir/main.c.o
0000000000000018 r EH_frame1
U _VerifyC
U _VerifyFortran
0000000000000000 T _main
$ cat ./CMakeFiles/FortranCInterface/VerifyC/VerifyFortran.h
#ifndef FortranCInterface_HEADER_INCLUDED
#define FortranCInterface_HEADER_INCLUDED
/*--------------------------------------------------------------------------*/
/* Mangle some symbols automatically. */
#endif
```https://gitlab.kitware.com/cmake/cmake/-/issues/21568CPack/DragNDrop: automatically collect dependencies, sign, notorize, and staple2020-12-16T19:24:28-05:00Be IngCPack/DragNDrop: automatically collect dependencies, sign, notorize, and stapleHaving to call `fixup_bundle` from BundleUtilities with `install(CODE` or `install(SCRIPT` with the DragNDrop generator for macOS bundles is clumsy. It took me [a week of frustration](https://discourse.cmake.org/t/lost-with-getting-cpack...Having to call `fixup_bundle` from BundleUtilities with `install(CODE` or `install(SCRIPT` with the DragNDrop generator for macOS bundles is clumsy. It took me [a week of frustration](https://discourse.cmake.org/t/lost-with-getting-cpack-to-make-a-macos-bundle/2102/8) to figure out how to do it. The documentation was not very helpful, but I don't understand why this is even required. Building a macOS package could be greatly simplified if the DragNDrop generator automatically ran `fixup_bundle`. The libraries and directories parameters to `fixup_bundle` could be provided to the generator as variables (the generator should already know where the application bundle is for the first `fixup_bundle` parameter).
Furthermore, DragNDrop should be able to code sign and notorize bundles automatically after running `fixup_bundle` when provided with required credentials and the entitlements file path. Currently, signing bundles requires a custom `install(CODE` script which first calls `fixup_bundle`. This must be done by CMake and getting the required variables into an `install(CODE` script is cumbersome. If CMake does not do this, the user would have to mount the DMG, copy the application bundle out of it, then code sign the bundle and create a new DMG. After CMake has created the DMG, it should be signed and notorized (signing the app bundle inside is not the same as signing the DMG).https://gitlab.kitware.com/cmake/cmake/-/issues/21657RFE: provide regexes to ignore "magic" DLLs on Windows/system libraries on macOS2021-01-04T10:29:55-05:00Ben BoeckelRFE: provide regexes to ignore "magic" DLLs on Windows/system libraries on macOSOn Windows, there are DLL entries for "API sets" which are Microsoft's method for ABI compatibility in the future. We should provide a module which contains lists of these regexes.
On macOS, `libSystem.dylib` should never be packaged, s...On Windows, there are DLL entries for "API sets" which are Microsoft's method for ABI compatibility in the future. We should provide a module which contains lists of these regexes.
On macOS, `libSystem.dylib` should never be packaged, so exclusions for that platform also make sense to provide.
See [this Discourse comment](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/7).
Cc: @kyle.edwards @ben.boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/21719macOS: Optionally exclude weak dependencies from file(GET_RUNTIME_DEPENDENCIES)2021-03-31T12:02:52-04:00Brad KingmacOS: Optionally exclude weak dependencies from file(GET_RUNTIME_DEPENDENCIES)Discussion in https://gitlab.kitware.com/cmake/cmake/-/issues/21684#note_886225 concluded that we should add an option to `file(GET_RUNTIME_DEPENDENCIES)` and perhaps `BundleUtilities` to exclude "weak" dependencies on macOS.Discussion in https://gitlab.kitware.com/cmake/cmake/-/issues/21684#note_886225 concluded that we should add an option to `file(GET_RUNTIME_DEPENDENCIES)` and perhaps `BundleUtilities` to exclude "weak" dependencies on macOS.https://gitlab.kitware.com/cmake/cmake/-/issues/21734Add CPackProductbuild support for the hostArchitectures option in Distributio...2024-03-11T03:05:29-04:00Harry MallonAdd CPackProductbuild support for the hostArchitectures option in Distribution.xmlThe Distribution XML file contains a line called `options`. Current CMake choices are [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.3/Modules/Internal/CPack/CPack.distribution.dist.in).
```xml
<options allow-external-script...The Distribution XML file contains a line called `options`. Current CMake choices are [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.3/Modules/Internal/CPack/CPack.distribution.dist.in).
```xml
<options allow-external-scripts="no" customize="allow" rootVolumeOnly="false"></options>
```
However when building for Apple Silicon / x86_64 universal we want to set a sub-option in there `hostArchitectures` to `arm64,x86_64`. Referenced [here (but not updated for Apple Silicon)](https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html). Installers build with `arm64,x86_64` should not force Rosetta 2 installation on Apple Silicon macs.
`man productbuild` says that on 11.0 (Big Sur) the default is set to `arm64,x86_64` rather than Intel only and has other useful context.
Maybe we want the option to set it manually as arm64 installers will want `arm64` only, intel only will want `x86_64` and universal 2 will want `arm64,x86_64`?https://gitlab.kitware.com/cmake/cmake/-/issues/21768macOS: App Bundle "Resouces" directory structure2021-02-04T09:18:38-05:00Ghost UsermacOS: App Bundle "Resouces" directory structureI literally spent 2 days on this already. Is simplest copy_directory is a way to do this?
What I mean I have a project structure
```
assets/subfolders + files
src/main.cpp
CMakeList.txt
```
CMakeList.txt
```
add_executable(hello src/mai...I literally spent 2 days on this already. Is simplest copy_directory is a way to do this?
What I mean I have a project structure
```
assets/subfolders + files
src/main.cpp
CMakeList.txt
```
CMakeList.txt
```
add_executable(hello src/main.cpp)
set_target_properties(hello PROPERTIES
MACOSX_BUNDLE TRUE
RESOURCE "??? folders / files ??? ")
```
Also I can't understand how to use it, what I mean such target properties generates hello.app, but "Resources" not shows up!
```
file(GLOB_RECURSE RES_SOURCES "${PROJECT_SOURCE_DIR}/assets/*")
add_executable(hello MACOSX_BUNDLE src/main.cpp ${RES_SOURCES}) #
SET_SOURCE_FILES_PROPERTIES(${RES_SOURCES} MACOSX_PACKAGE_LOCATION "Resources")
```
It does copy all res sources to "Resources" folder, but hierarchy is being lost!
Hope I can find some help here, thanks!https://gitlab.kitware.com/cmake/cmake/-/issues/21845Xcode: POST_BUILD runs before signing, breaks builds on ARM Mac2024-03-02T16:35:04-05:00Brad KingXcode: POST_BUILD runs before signing, breaks builds on ARM MacWith the Xcode generator on macOS arm64, the pattern
```cmake
add_executable(myexe myexe.c)
add_custom_command(TARGET myexe POST_BUILD COMMAND myexe)
```
fails to build. The `POST_BUILD` command generates a "Run Script" build phase wi...With the Xcode generator on macOS arm64, the pattern
```cmake
add_executable(myexe myexe.c)
add_custom_command(TARGET myexe POST_BUILD COMMAND myexe)
```
fails to build. The `POST_BUILD` command generates a "Run Script" build phase with a script that runs `myexe`, but Xcode's build system tries to run that phase before singing the executable.
The build fails with output:
```
Killed: 9 "/path/to/myexe"
Command PhaseScriptExecution failed with a nonzero exit code
```https://gitlab.kitware.com/cmake/cmake/-/issues/21854Xcode: Install-time editing with install_name_tool breaks signatures2022-01-04T16:10:30-05:00Brad KingXcode: Install-time editing with install_name_tool breaks signaturesWhen using the Xcode generator, install-time editing operations with `install_name_tool` warn:
```
install_name_tool: warning: changes being made to the file will invalidate the code signature in: ...
```
and break the signatures of bi...When using the Xcode generator, install-time editing operations with `install_name_tool` warn:
```
install_name_tool: warning: changes being made to the file will invalidate the code signature in: ...
```
and break the signatures of binaries. This occurs when editing binaries to change `LC_LOAD_DYLIB` names for dependencies, e.g. to switch to `@executable_path/...`.
This is particularly prevalent on macOS arm64 machines, where all tooling signs binaries (even if a local ad-hoc signature) and macOS requires all binaries to be signed before running.https://gitlab.kitware.com/cmake/cmake/-/issues/21885macOS: CMAKE_CROSSCOMPILING not set when building arm64 binaries on a x86_642021-03-24T10:04:49-04:00Maxime LeblancmacOS: CMAKE_CROSSCOMPILING not set when building arm64 binaries on a x86_64When trying to build `arm64` only binaries on a `x86_64` machine, the `CMAKE_CROSSCOMPILING` is not set to `TRUE`.
Therefore, checking if we are crosscompiling to avoid running macros such as `check_c_source_runs` will not work resultin...When trying to build `arm64` only binaries on a `x86_64` machine, the `CMAKE_CROSSCOMPILING` is not set to `TRUE`.
Therefore, checking if we are crosscompiling to avoid running macros such as `check_c_source_runs` will not work resulting in not setting some variables.
For me, `CMakeDetermineSystem.cmake` should, on macOS, check current arch as well as if `CMAKE_OSX_ARCHITECTURES` is set and determine wether we are cross-compiling or not.https://gitlab.kitware.com/cmake/cmake/-/issues/21923Set CMAKE_(HOST_)?SYSTEM_NAME to macOS/iOS instead of Darwin2022-01-09T12:32:22-05:00Kyle EdwardsSet CMAKE_(HOST_)?SYSTEM_NAME to macOS/iOS instead of DarwinWhen applicable, `CMAKE_HOST_SYSTEM_NAME` and `CMAKE_SYSTEM_NAME` should be set to `macOS` or `iOS` as appropriate, instead of `Darwin`. We will need a policy for this.When applicable, `CMAKE_HOST_SYSTEM_NAME` and `CMAKE_SYSTEM_NAME` should be set to `macOS` or `iOS` as appropriate, instead of `Darwin`. We will need a policy for this.https://gitlab.kitware.com/cmake/cmake/-/issues/21962Objective C/C++: macOS architecture depends on language initialization order2021-03-24T10:04:37-04:00Tim BlechmannObjective C/C++: macOS architecture depends on language initialization order```
cmake_minimum_required(VERSION 3.19)
project(foo LANGUAGES C CXX OBJC OBJCXX)
add_executable(main a.m b.c c.mm d.cpp)
```
when configuring with `CMAKE_OSX_ARCHITECTURES=arm64` the ninja projects will not pass the `-arch` compiler fl...```
cmake_minimum_required(VERSION 3.19)
project(foo LANGUAGES C CXX OBJC OBJCXX)
add_executable(main a.m b.c c.mm d.cpp)
```
when configuring with `CMAKE_OSX_ARCHITECTURES=arm64` the ninja projects will not pass the `-arch` compiler flag to objc sources:
```
[1/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/b.c.o -MF CMakeFiles/main.dir/b.c.o.d -o CMakeFiles/main.dir/b.c.o -c ../b.c
[2/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -x objective-c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -std=gnu++98 -MD -MT CMakeFiles/main.dir/c.mm.o -MF CMakeFiles/main.dir/c.mm.o.d -o CMakeFiles/main.dir/c.mm.o -c ../c.mm
[3/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -std=gnu11 -MD -MT CMakeFiles/main.dir/a.m.o -MF CMakeFiles/main.dir/a.m.o.d -o CMakeFiles/main.dir/a.m.o -c ../a.m
[4/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/d.cpp.o -MF CMakeFiles/main.dir/d.cpp.o.d -o CMakeFiles/main.dir/d.cpp.o -c ../d.cpp
```
observation: `a.m` is compiled without `-arch=arm64`.
---
if the `OBJC` language is not initialised, the source file is identified as `c` and the `-arch` flag is passed correctly.
---
funny observation: if the `OBJC` language is initialised **after** `C`, the `-arch` flag is passed correctly:
```
cmake_minimum_required(VERSION 3.19)
#project(foo LANGUAGES C CXX OBJC OBJCXX)
project(foo LANGUAGES OBJC OBJCXX C CXX)
add_executable(main a.m b.c c.mm d.cpp)
```
```
[1/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/a.m.o -MF CMakeFiles/main.dir/a.m.o.d -o CMakeFiles/main.dir/a.m.o -c ../a.m
[2/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/b.c.o -MF CMakeFiles/main.dir/b.c.o.d -o CMakeFiles/main.dir/b.c.o -c ../b.c
[3/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -x objective-c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -std=gnu++98 -MD -MT CMakeFiles/main.dir/c.mm.o -MF CMakeFiles/main.dir/c.mm.o.d -o CMakeFiles/main.dir/c.mm.o -c ../c.mm
[4/5] /Applications/Xcode12.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -arch arm64 -isysroot /Applications/Xcode12.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -MD -MT CMakeFiles/main.dir/d.cpp.o -MF CMakeFiles/main.dir/d.cpp.o.d -o CMakeFiles/main.dir/d.cpp.o -c ../d.cpp
```https://gitlab.kitware.com/cmake/cmake/-/issues/22184Xcode: OSX_DEPLOYMENT_TARGET should depend on target architecture2022-09-03T09:53:06-04:00EikeAtOTXcode: OSX_DEPLOYMENT_TARGET should depend on target architectureWhen building a CMake project for multiple architectures (x86_64 and arm64) on Mac it should be possible to set the minimum macOS version depending on the architecture.
Reasoning:
The first macOS version ever supporting the Apple Silico...When building a CMake project for multiple architectures (x86_64 and arm64) on Mac it should be possible to set the minimum macOS version depending on the architecture.
Reasoning:
The first macOS version ever supporting the Apple Silicon (ARM) architecture was macOS 11.0. Accordingly all sources compiled for Apple Silicon need to be compiled with `'-target arm64-apple-macos11.0'`. However, the x86_64 variant in the universal binary should be able to support macOS versions down to 12.0. Currently the OSX_DEPLOYMENT_TARGET is set unconditionally, which either:
- leads to compilation errors when building for arm64 against the 11.0 or higher SDKs
- prevents x86_64 code to run on a version older than 11.0
It should therefore be possible to specify the macOS target version based on the target architecture.https://gitlab.kitware.com/cmake/cmake/-/issues/22372macOS: Linker-signed libraries signed at install-time crash with hardened run...2022-01-04T18:35:38-05:00Ryan FostermacOS: Linker-signed libraries signed at install-time crash with hardened runtimeWhen using hardened runtime for an application, macOS will enforce termination of a process that tries to load libraries that failed library validation checks. Among those tests is a comparison between the file modification timestamp and...When using hardened runtime for an application, macOS will enforce termination of a process that tries to load libraries that failed library validation checks. Among those tests is a comparison between the file modification timestamp and its code-signing timestamp.
On modern macOS systems, maybe due to APFS, this leads to a situation where a library created with an ad-hoc code-signature (e.g., to be loaded/run from the build tree on Apple Silicon Macs), which is then `install`-ed into its final destination (i.e., inside an app bundle), has its `rpath`-entries fixed up, and gets finally code-signed with the actual developer ID, results in crashing the loading application because the second code-signing leads to a "tampered" library.
There is a radar filed for this behavior (https://openradar.appspot.com/FB8914243), but in informal talks with Apple this was confirmed as not a bug, but intended behavior: a code-signed library cannot be code-signed again at a later date and used in hardened runtime environments.
Apple suggested using `ditto` to copy the library before fixing it up and code-signing it to ensure that macOS will treat it as a separate file.
As such it would be desirable if CMake itself could ensure that for file copy operations or `install` targets actual clones are created to avoid this issue.
Noticeably, macOS will terminate the application on launch and even though the fixed library has been put _into_ the application bundle, the crash log points to the same library in the build tree as the library that failed validation.https://gitlab.kitware.com/cmake/cmake/-/issues/22669macOS: CMake uses -Wl,-rpath for Mac OS X 10.4 Tiger despite not being supported2024-02-14T09:07:01-05:00Thomas Siracktsirack@protonmail.commacOS: CMake uses -Wl,-rpath for Mac OS X 10.4 Tiger despite not being supportedThis issue stemmed from a build failure in another software project; see [https://github.com/minetest/minetest/issues/11647](https://github.com/minetest/minetest/issues/11647) for more information. Essentially, no matter what I tried aft...This issue stemmed from a build failure in another software project; see [https://github.com/minetest/minetest/issues/11647](https://github.com/minetest/minetest/issues/11647) for more information. Essentially, no matter what I tried after the fact, CMake was still trying to use `-Wl,-rpath` to link a test program for a library.
This included setting `CMAKE_OSX_DEPLOYMENT_TARGET` to `10.4`, `CMAKE_SKIP_RPATH` to `TRUE` and `CMAKE_MACOSX_RPATH` to `FALSE`, but again, nothing changed.
Looking at the CMake file for Darwin (macOS), I found this:
```cmake
if(NOT "${_CURRENT_OSX_VERSION}" VERSION_LESS "10.5")
set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,")
endif()
```
From the looks of it, this should only be enabling `-rpath` if the macOS version is _not less_ (i.e. greater than or equal to) 10.5. It appears, however, to be completely ignored.
In desperation, I forcibly modified this file to set `CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG` to an empty string. While this did get zstd in the project to be detected, it still did not complete successfully.
```
Thomass-iMac:build thomas$ cmake .. -DCMAKE_OSX_DEPLOYMENT_TARGET="10.4" -DCMAKE_SKIP_RPATH=TRUE -DCMAKE_SKIP_BUILD_RPATH=TRUE -DCMAKE_MACOSX_RPATH=FALSE -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4u.sdk/ -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/opt/irrlichtmt/ppc -DCMAKE_TOOLCHAIN_FILE=/Users/thomas/Documents/minetest/ppctoolchain.cmake -DCMAKE_INSTALL_PREFIX=/Users/thomas/Documents/minetest-built -DZSTD_INCLUDE_DIR=/opt/zstd/ppc/include -DZSTD_LIBRARY=/opt/zstd/ppc/lib/libzstd.dylib -DBUILD_UNITTESTS=FALSE -DENABLE_CURL=OFF -DENABLE_CURSES=OFF -DENABLE_FREETYPE=OFF -DENABLE_GETTEXT=OFF -DENABLE_LEVELDB=OFF -DENABLE_POSTGRESQL=OFF -DENABLE_REDIS=OFF -DENABLE_SPATIAL=OFF -DENABLE_SOUND=OFF -DENABLE_LUAJIT=OFF -DVERSION_EXTRA="powerpc"
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /opt/gcc/ppc/11/bin/powerpc-apple-darwin8-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /opt/gcc/ppc/11/bin/powerpc-apple-darwin8-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- *** Will build version 5.5.0-powerpc ***
-- Found IrrlichtMt 1.9.0
-- Using GMP provided by system.
-- Found GMP: /opt/gmp/ppc/lib/libgmp.dylib
-- Using JsonCpp provided by system.
-- Found Json: /opt/jsoncpp/ppc/lib/libjsoncpp.dylib
-- LuaJIT detection disabled! (ENABLE_LUAJIT=0)
-- LuaJIT not found, using bundled Lua.
CMake Warning at src/CMakeLists.txt:53 (message):
cURL is required to load the server list
-- GetText disabled.
-- Found OpenGL: /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenGL.framework
-- Found SQLite3: /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libsqlite3.dylib
-- Prometheus client disabled.
-- Found ZLIB: /opt/zlib/ppc/lib/libz.dylib (found version "1.2.11")
-- Looking for ZSTD_initCStream
-- Looking for ZSTD_initCStream - found
-- Found Zstd: /opt/zstd/ppc/lib/libzstd.dylib
-- Looking for include file endian.h
-- Looking for include file endian.h - not found
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring done
CMake Error at /opt/irrlichtmt/ppc/lib/cmake/IrrlichtMt/IrrlichtMtTargets.cmake:54 (add_library):
Attempting to use @rpath without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being
set. This could be because you are using a Mac OS X version less than 10.5
or because CMake's platform configuration is corrupt.
Call Stack (most recent call first):
/opt/irrlichtmt/ppc/lib/cmake/IrrlichtMt/IrrlichtMtConfig.cmake:11 (include)
CMakeLists.txt:88 (find_package)
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
```