[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cmake
Subject:    Re: [CMake] Cmake Frameworks and Bitcode
From:       Cameron Palmer <cameron () promon ! no>
Date:       2018-03-26 8:24:56
Message-ID: B6F8857E-1E7E-413F-A4F5-43493BA7690E () promon ! no
[Download RAW message or body]

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@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

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: \
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at \
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake


[prev in list] [next in list] [prev in thread] [next in thread]