Cmake Frameworks and Bitcode

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Cmake Frameworks and Bitcode

Cameron Palmer
So after a bit of hacking it seems that Cmake should provide something like:

CMAKE_OSX_BITCODE_ENABLE

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.

Does this sound like something that should be submitted as a patch?
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Cmake Frameworks and Bitcode

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Cmake Frameworks and Bitcode

Brad King
On 03/26/2018 04:24 AM, Cameron Palmer wrote:
> 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.

Oops, I mixed up functionality with other platforms.  On platforms
that do not have `-headerpad_max_install_names` we generate bogus
rpath content in the build tree to pad out enough space to replace
it in the installed binary in the install tree.  That behavior is
turned off by BUILD_WITH_INSTALL_RPATH.  On Apple platforms with
`-headerpad_max_install_names` the flag is simply hard-coded.
CMake would indeed need a new abstraction for `-fembed-bitcode`.

Also, CMP0068 means the BUILD_WITH_INSTALL_NAME_DIR should be used
instead of BUILD_WITH_INSTALL_RPATH.

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

Sure we can.  CMP0068 is only about the names of the CMake properties
that influence the behavior.  The INSTALL_NAME_DIR property can be
set to "@rpath".

-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