CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-03-01T07:52:43-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/22738macOS: find_library should maybe consider library architecture2022-03-01T07:52:43-05:00Sean McBridemacOS: find_library should maybe consider library architectureI run several macOS buildbots that build several open source projects. Yesterday I installed [MacPorts](https://www.macports.org/) on them and installed a few ports (notably `subversion`). This tool places files in `/opt/local/lib` and ...I run several macOS buildbots that build several open source projects. Yesterday I installed [MacPorts](https://www.macports.org/) on them and installed a few ports (notably `subversion`). This tool places files in `/opt/local/lib` and `/opt/local/include`. In particular, it so happened to install `/opt/local/lib/libmagic.dylib`.
One project I build nightly is [GDCM](http://gdcm.sourceforge.net/wiki/index.php/Main_Page) and it was building yesterday but [failed today](https://open.cdash.org/viewBuildError.php?buildid=7501364) with:
```
[CTest: warning matched] ld: warning: ignoring file /opt/local/lib/libmagic.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
Undefined symbols for architecture arm64:
"_magic_close", referenced from:
_main in EncapsulateFileInRawData.cxx.o
"_magic_file", referenced from:
_main in EncapsulateFileInRawData.cxx.o
"_magic_open", referenced from:
_main in EncapsulateFileInRawData.cxx.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
This build of GDCM specifies `CMAKE_OSX_ARCHITECTURES=x86_64;arm64` (i.e. a Universal Binary). MacPorts installed x86_64-only on this Intel Mac. `find_library` found the existence of a file at `/opt/local/lib/libmagic.dylib` but it seems it doesn't check what architectures the found file contains, and whether they align with what my build specifies in `CMAKE_OSX_ARCHITECTURES`. libmagic is optional for GDCM, so yesterday it found nothing, and built fine. Today it found an Intel-only version from MacPorts and the universal build is broken.
Perhaps `find_library` should use `file` or `otool` to preflight the libs it finds?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/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/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/22997Add @executable_path/../Frameworks to install RPATH of macOS app targets2021-12-09T22:42:34-05:00Craig ScottAdd @executable_path/../Frameworks to install RPATH of macOS app targetsIt's a bit of a nuisance that for every macOS executable target that is an app bundle, we always end up having to add `@executable_path/../Frameworks` to the install RPATH (and often to the build RPATH as well). I'd like to proposed that...It's a bit of a nuisance that for every macOS executable target that is an app bundle, we always end up having to add `@executable_path/../Frameworks` to the install RPATH (and often to the build RPATH as well). I'd like to proposed that we add it automatically for macOS app executable targets, at least to the `INSTALL_RPATH` target property. I'd be open to automatically adding it to the `BUILD_RPATH` property as well. This would mean one less bit of boilerplate projects would have to add for a common case.
For apps that don't embed any frameworks, having `@executable_path/../Frameworks` added to the install or build RPATH anyway shouldn't do any harm. It won't be used in that case, but it won't break anything or change behavior.
I don't know if we'd need a policy for this. While it would be an observable change, I'd question whether it is a change that could make a practical difference to existing projects. We could look at the final RPATH at generation time and only add `@executable_path/../Frameworks` if it isn't already present. If we do add it, then we can add it to the end of the resolved RPATH. That way, we shouldn't create any danger of changing what gets found due to any pre-existing `INSTALL_RPATH` contents. An app bundle shouldn't be looking outside of the bundle itself for anything other than in system locations. But if we want to be ultra-conservative, I wouldn't push back on using a policy.
For iOS app bundles, potentially we might want to do something similar. I think the equivalent path would be just `@executable_path` in that case, but I don't have a lot of experience with shared frameworks on iOS to know if there would be any undesirable side effects from doing that.https://gitlab.kitware.com/cmake/cmake/-/issues/22760macOS: INTERFACE_SOURCES and bundling resources in consumers2021-10-14T10:58:52-04:00ChristophemacOS: INTERFACE_SOURCES and bundling resources in consumersHi,
I've an `INTERFACE` library that needs to copy files into a macOS bundle executable **before** Xcode codesigning step (POST_BUILD custom command is not an option). I believe the correct way to handle this is to set the `INTERFACE_SO...Hi,
I've an `INTERFACE` library that needs to copy files into a macOS bundle executable **before** Xcode codesigning step (POST_BUILD custom command is not an option). I believe the correct way to handle this is to set the `INTERFACE_SOURCES` target property and set the source property `MACOSX_PACKAGE_LOCATION` for the files I want to be copied into the bundle during Xcode build copy step (which happens before code signing).
Unfortunately set_source_files_properties is scope limited. Also the new `DIRECTORY` option is not solving the issue as the interface library has no way of knowing all the folders it will be used in (the library is consumed by other targets).
As an example, consider the following:
```cmake
cmake_minimum_required(VERSION 3.19)
project(test LANGUAGES CXX VERSION 1.0.0.1)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
# Include definition for an interface library
add_subdirectory(interfaceLib)
## Main app consuming the interface library (possibly in a sub folder)
add_executable(app MACOSX_BUNDLE app.cpp)
target_link_libraries(app PRIVATE interfaceLibrary)
```
and the interface library script:
```cmake
## Interface lib
set(INT_FILE_PATH "${CMAKE_CURRENT_LIST_DIR}/myFile.txt")
set_source_files_properties(${INT_FILE_PATH} PROPERTIES MACOSX_PACKAGE_LOCATION MyDataFolder)
add_library(interfaceLibrary INTERFACE IMPORTED GLOBAL)
set_target_properties(interfaceLibrary PROPERTIES INTERFACE_SOURCES "${INT_FILE_PATH}")
```
Possible fixes:
- add a `PARENT_SCOPE` keyword to set_source_files_properties that will define the source properties to the parent as well (and forward down the tree afterwards)
- add a `TARGET_SCOPE` keyword to set_source_files_properties that will define the source properties everywhere the target using this source file is consumed
- automatically globally set source properties when they are linked to a target property (maybe it's just MACOSX_PACKAGE_LOCATION that requires this)
Any other possibility?
Thankshttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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).