[CMake] Cmake Frameworks and Bitcode

[Cameron Palmer]

Quite possible I’m misunderstanding something, but…

As you said, I really don’t care much at this point about the RPATH.

However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn’t change anything as far as I can tell. The target is still linked with -headerpad_max_install_names and the linker still complains. Also, looking at policy 68 and working with the INSTALL_NAME, which is the one thing you do care about, you cannot set the directory to @rpath which seems silly. Most frameworks I’m familiar with have the install name set to @rpath/My.framwork/my. I use add_custom_command to correctly set it, but still seems like this is broken.

The library I’ve been testing is iperf, it is relatively straightforward, so it makes a good test case. I’ve added CMake and it is at https://github.com/palmerc/iperf. 

Cameron.


> On 19 Mar 2018, at 12:54, Brad King <brad.king at kitware.com> wrote:
> 
> On 03/12/2018 10:36 AM, Cameron Palmer wrote:
>> So after a bit of hacking it seems that Cmake should provide something like:
>> 
>> CMAKE_OSX_BITCODE_ENABLE
> 
> For reference, this refers to a previous post:
> 
>    Bitcode and CMake
>    https://cmake.org/pipermail/cmake/2018-March/067191.html
> 
> with the goal of using `-fembed-bitcode` while avoiding a warning:
> 
>    ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)
> 
>> Which would pass -fembed-bitcode to the compiler and linker and remove
>> the option in Darwin.cmake for -Wl,-headerpad_max_install_names in
>> CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS.
> 
> One may avoid the `-headerpad_max_install_names` option with this:
> 
>    https://cmake.org/cmake/help/v3.11/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html
> 
> There is no reason to build with any rpath set for the build tree
> when one cannot run the binaries on the macOS host anyway.
> 
> -Brad