[cmake-developers] fix-OSX-bundle-rpaths-and-Qt5 topic

[Brad King]

Hi Folks,

Picking up from the end of an earlier thread:

[PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focus=11016

Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to
'next' for testing? Clinton, have your comments been addressed?

Thanks,
-Brad

[Clinton Stimpson]

Post by Brad King
Hi Folks,
[PATCH] stage/fix-OSX-bundle-rpaths-and-Qt5
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10781/focu
s=11016
Is the fix-OSX-bundle-rpaths-and-Qt5 topic ready to be merged to
'next' for testing? Clinton, have your comments been addressed?
Thanks,
-Brad

My concerns of breaking backward compatibility were already addressed.

However, I do wish there is a test for this. Although the commits target OS
X, I would like to see some proof that the API changes in GetPrerequisites for
supporting rpaths will work on other platforms such as Linux.

A test for both OS X and Linux will help justify the API changes.

Clint

[Adam Strzelecki]

Post by Clinton Stimpson
A test for both OS X and Linux will help justify the API changes.

Well. All I can say that failing tests were already addressed in latest version of this branch. Also it does not break existing functions signature or behavior. All new parameters are optional.

I have no other means to prove that everything is OK.

--Adam

[Brad King]

Post by Adam Strzelecki
I have no other means to prove that everything is OK.

Please merge the topic to 'next' for testing when you're ready.
We can at least see if the dashboard stays clean with it.

Thanks,
-Brad

[Adam Strzelecki]

Post by Brad King
Please merge the topic to 'next' for testing when you're ready.
We can at least see if the dashboard stays clean with it.

Done.

--Adam

[Brad King]

Post by Brad King
Please merge the topic to 'next' for testing when you're ready.
We can at least see if the dashboard stays clean with it.

Done.

Since this was merged the dashboard has reported several failing
instances of the BundleUtilities test. They have errors like:

/usr/bin/find: invalid mode '+0111'
CMake Error at .../Modules/BundleUtilities.cmake:395 (string):
string sub-command REPLACE requires at least four arguments.

Please extend the topic with a fix. Also use quoting like:

- string(REPLACE "\n" ";" file_list ${file_list})
+ string(REPLACE "\n" ";" file_list "${file_list}")

to make sure the command runs when the file list is empty.
After extending the topic please merge to 'next' again and
check if it fixes the dashboard.

Thanks,
-Brad

[Adam Strzelecki]

Brad,

I've applied your suggestions about quoting and used portable (POSIX compliant) find call that should work now on any system.

Fixup pushed to next.

Thank you for your support!

--Adam

[Adam Strzelecki]

Correct me if I am wrong but it seems CDash reports no further problems with my changes.

Cheers,

--Adam

[Brad King]

Post by Adam Strzelecki
I've applied your suggestions about quoting and used portable
(POSIX compliant) find call that should work now on any system.

Thanks.

Post by Adam Strzelecki
Correct me if I am wrong but it seems CDash reports no
further problems with my changes.

It's better, but the BundleUtilities test fails on OS X 10.5:

http://open.cdash.org/testDetails.php?test=285651145&build=3517533

-- 6/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input
-- 7/10: fixing up '.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so'
install_name_tool: more than one input file specified (.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input

[c***@elemtech.com]

----- Original Message -----

Post by Brad King

Post by Adam Strzelecki
I've applied your suggestions about quoting and used portable
(POSIX compliant) find call that should work now on any system.

Thanks.

Post by Adam Strzelecki
Correct me if I am wrong but it seems CDash reports no
further problems with my changes.

http://open.cdash.org/testDetails.php?test=285651145&build=3517533
-- 6/10: fixing up
'.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
install_name_tool: more than one input file specified
(.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input
-- 7/10: fixing up
'.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/module1.so'
install_name_tool: more than one input file specified
(.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input

[Adam Strzelecki]

Sure, I think it would be good to require 10.6.
We also have uses of the -delete_rpath/-add_rpath parameters in cmInstallTargetGenerator.cxx, and the test of that already requires 10.6 or greater.

Moreover I believe nobody nowadays builds for 10.5 on 10.5. Since 10.6 with Xcode 3 supports 10.5 PPC and Apple allows virtualization of 10.6 Server, so if anyone still targets PPC on 10.5 or earlier then 10.6 is natural choice.

--Adam

[Brad King]

Post by Adam Strzelecki

Sure, I think it would be good to require 10.6.

Moreover I believe nobody nowadays builds for 10.5 on 10.5.

Perhaps no one has to build that way for deployment but there could
still be people just building for their own host as the only computer
they have. The fact that our dashboard reported this problem means
we are testing that case.

Clinton, I don't have a 10.5 machine anymore and the test is failing
on yours. Please take whatever action you feel is appropriate to
resolve the test failure on that machine. This could mean either

Post by Adam Strzelecki
+ foreach(rpath ${${ikey}_RPATHS})
+ set(changes ${changes} -delete_rpath "${rpath}")
+ endforeach()

to warn and skip removal when hosted on 10.5. Or another option you
find.

This needs to be resolved in the next day or two or the topic won't
be in CMake 3.1.

Thanks,
-Brad

[c***@elemtech.com]

----- Original Message -----

Post by Brad King

Post by Adam Strzelecki

Sure, I think it would be good to require 10.6.

Moreover I believe nobody nowadays builds for 10.5 on 10.5.

Perhaps no one has to build that way for deployment but there could
still be people just building for their own host as the only computer
they have. The fact that our dashboard reported this problem means
we are testing that case.
Clinton, I don't have a 10.5 machine anymore and the test is failing
on yours. Please take whatever action you feel is appropriate to
resolve the test failure on that machine. This could mean either

Post by Adam Strzelecki
+ foreach(rpath ${${ikey}_RPATHS})
+ set(changes ${changes} -delete_rpath "${rpath}")
+ endforeach()

to warn and skip removal when hosted on 10.5. Or another option you
find.
This needs to be resolved in the next day or two or the topic won't
be in CMake 3.1.
Thanks,
-Brad

I don't have a 10.5 machine, but I've put in a commit which I hope solves the problem.
36c509b9 OSX: Only enable @rpath support on OS X 10.6 or greater.

Clint

[Brad King]

Post by Brad King
I don't have a 10.5 machine

Oops, I must have mixed up my browser tabs on that one.

Post by Brad King
but I've put in a commit which I hope solves the problem.

Thanks!

-Brad

[c***@elemtech.com]

----- Original Message -----

Post by c***@elemtech.com
----- Original Message -----

Post by Brad King

Post by Adam Strzelecki

Sure, I think it would be good to require 10.6.

Moreover I believe nobody nowadays builds for 10.5 on 10.5.

Perhaps no one has to build that way for deployment but there could
still be people just building for their own host as the only computer
they have. The fact that our dashboard reported this problem means
we are testing that case.
Clinton, I don't have a 10.5 machine anymore and the test is failing
on yours. Please take whatever action you feel is appropriate to
resolve the test failure on that machine. This could mean either

Post by Adam Strzelecki
+ foreach(rpath ${${ikey}_RPATHS})
+ set(changes ${changes} -delete_rpath "${rpath}")
+ endforeach()

to warn and skip removal when hosted on 10.5. Or another option you
find.
This needs to be resolved in the next day or two or the topic won't
be in CMake 3.1.
Thanks,
-Brad

I don't have a 10.5 machine, but I've put in a commit which I hope solves the problem.

I pushed more fixes for this. Instead of requiring 10.6, I took the other path of warning when rpaths need changed at install time and skip it.
This should also fix the CMP0042 test which started failing.

By the way, Brad, your change to require 10.6 for the BundleUtilities test is no longer required on the rpath-osx-10_6 topic.

However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic.

Clint

[Brad King]

Post by c***@elemtech.com
I pushed more fixes for this. Instead of requiring 10.6,
I took the other path of warning when rpaths need changed
at install time and skip it.
This should also fix the CMP0042 test which started failing.
+ msg << "WARNING: Target \"" << this->Target->GetName()
+ << "\" has runtime paths which cannot be changed during install. "
+ << "To change runtime paths, OS X version 10.6 or newer is required. "
+ << "Therefore, runtime paths will not be changed when installing.";
+ cmSystemTools::Message(msg.str().c_str(), "Warning");

Can that be changed to an IssueMessage, possibly on a cmMakefile
for at least a little context? Also it should suggest using
CMAKE_BUILD_WITH_INSTALL_RPATH.

Post by c***@elemtech.com
By the way, Brad, your change to require 10.6 for the
BundleUtilities test is no longer required on the rpath-osx-10_6 topic.

I thought it was a missing piece of your original change.
Since you've reverted that I've now reverted mine so we'll
see how testing goes.

Post by c***@elemtech.com
However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic.

I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to
make local testing of both together easier. Please base the
above-requested fixes on:

OSX: Warn when attempting to change runtime paths on OS X 10.5
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55

Thanks,
-Brad

[Clinton Stimpson]

Post by Brad King

Post by c***@elemtech.com
I pushed more fixes for this. Instead of requiring 10.6,
I took the other path of warning when rpaths need changed
at install time and skip it.
This should also fix the CMP0042 test which started failing.
+ msg << "WARNING: Target \"" << this->Target->GetName()
+ << "\" has runtime paths which cannot be changed during install.
" + << "To change runtime paths, OS X version 10.6 or newer is
required. " + << "Therefore, runtime paths will not be changed
when installing."; + cmSystemTools::Message(msg.str().c_str(),
"Warning");

Can that be changed to an IssueMessage, possibly on a cmMakefile
for at least a little context? Also it should suggest using
CMAKE_BUILD_WITH_INSTALL_RPATH.

Fixed.

Post by Brad King

Post by c***@elemtech.com
By the way, Brad, your change to require 10.6 for the
BundleUtilities test is no longer required on the rpath-osx-10_6 topic.

I thought it was a missing piece of your original change.
Since you've reverted that I've now reverted mine so we'll
see how testing goes.

Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with
@rpath on OS X 10.5. Perhaps it'll recognize there is no need to change
rpaths.

Clint

[Brad King]

Adam,

Post by Clinton Stimpson
Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with
@rpath on OS X 10.5. Perhaps it'll recognize there is no need to change
rpaths.

The BundleUtilities test still fails on OS X 10.5:

http://open.cdash.org/testDetails.php?test=285651145&build=3522021
-- 6/10: fixing up '/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
install_name_tool: more than one input file specified (/.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input

Clinton's changes in his rpath-osx-10_6 extension topic to yours teach
other uses of -delete_rpath to warn on OS X 10.5 and skip deletion.
I think something similar will be needed here. Please investigate.

Meanwhile, on my local OS X 10.9 machine I added this patch:

diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index eedab44..80e5d3b 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs)
#
if(changes)
execute_process(COMMAND install_name_tool ${changes} "${resolved_embedded_item}")
+ message(STATUS "CHANGE install_name_tool ${changes} \"${resolved_embedded_item}\"")
endif()
endfunction()

[c***@elemtech.com]

----- Original Message -----

Post by Brad King
Adam,

Post by Clinton Stimpson
Yeah. I'm curious if changes to BundleUtilities.cmake in fix-OSX-bundle-
rpaths-and-Qt5 will gracefully handle the BundleUtilities test case with
@rpath on OS X 10.5. Perhaps it'll recognize there is no need to change
rpaths.

http://open.cdash.org/testDetails.php?test=285651145&build=3522021
-- 6/10: fixing up
'/.../Tests/BundleUtilities/testdir1/testbundleutils1.app/Contents/MacOS/testbundleutils1'
install_name_tool: more than one input file specified
(/.../Tests/BundleUtilities/testdir1 and -delete_rpath)
Usage: install_name_tool [-change old new] ... [-id name] input
Clinton's changes in his rpath-osx-10_6 extension topic to yours teach
other uses of -delete_rpath to warn on OS X 10.5 and skip deletion.
I think something similar will be needed here. Please investigate.
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index eedab44..80e5d3b 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtilities.cmake
@@ -755,6 +755,7 @@ function(fixup_bundle_item resolved_embedded_item exepath dirs)
#
if(changes)
execute_process(COMMAND install_name_tool ${changes}
"${resolved_embedded_item}")
+ message(STATUS "CHANGE install_name_tool ${changes}
\"${resolved_embedded_item}\"")
endif()
endfunction()

[Brad King]

When I do the same message(), I don't see deletion of rpaths which do not exist.

I see them for libshared and libshared2 which have SKIP_BUILD_RPATH.

But, I'm wondering if INSTALL_RPATH should only be effective on OS X
if MACOSX_RPATH is set.
its id, which can result in rpaths for a consumer.
In other words, whether a target has rpaths is determined by the
What do you think about the case of INSTALL_RPATH?

If any dependencies have @rpath then the RPATH of a target is
meaningful, and INSTALL_RPATH is how the actual search paths
listed in the RPATH are to be set. INSTALL_RPATH is orthogonal
to MACOSX_RPATH. The affect different fields of their target.

-Brad

[Clinton Stimpson]

Post by Brad King

When I do the same message(), I don't see deletion of rpaths which do not exist.

I see them for libshared and libshared2 which have SKIP_BUILD_RPATH.

But, I'm wondering if INSTALL_RPATH should only be effective on OS X
if MACOSX_RPATH is set.
its id, which can result in rpaths for a consumer.
In other words, whether a target has rpaths is determined by the
What do you think about the case of INSTALL_RPATH?

meaningful, and INSTALL_RPATH is how the actual search paths
listed in the RPATH are to be set. INSTALL_RPATH is orthogonal
to MACOSX_RPATH. The affect different fields of their target.

Another justification for that is if a target does not link to any libraries
with an @rpath id, it is still useful to have an rpath to support
dlopen("@rpath/somelib").

Thanks,
Clint

[Adam Strzelecki]

FYI pushed e646a14f61 BundleUtilities: Check install_name_tool has -delete_rpath which is safest way to check if we can use -delete_rpath as it was introduced somewhere in 10.6 SDK, but there's no guarantee what SDK user has even it runs more recent OSX.

--Adam

[Brad King]

Post by Adam Strzelecki
FYI pushed e646a14f61 BundleUtilities: Check install_name_tool
has -delete_rpath which is safest way to check if we can use

Thanks. I moved the commit over on top of the rpath-osx-10_6
topic and then removed that topic. For now
fix-OSX-bundle-rpaths-and-Qt5 will contain all these related
changes. I merged it for testing in 'next'.

Thanks,
-Brad

[Brad King]

Post by Brad King
I merged it for testing in 'next'.

Everything tested cleanly! Adam, Clinton, thanks for your help
bringing this topic to maturity. It was the last non-regression
topic I'm planning to take for 3.1. I squashed the fixes and
revised commit messages slightly. Then I merged to 'master':

Merge topic 'fix-OSX-bundle-rpaths-and-Qt5'
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e

-Brad

[Brad King]

Post by Brad King
Everything tested cleanly! Adam, Clinton, thanks for your help
bringing this topic to maturity. It was the last non-regression
topic I'm planning to take for 3.1. I squashed the fixes and
Merge topic 'fix-OSX-bundle-rpaths-and-Qt5'
http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26bffa6e

We've been having problems getting the 3.1.0-rc1 release binaries
to work on machines other than those that built them. Ever since
this topic was merged for testing on 2014-09-30, the nightly
binaries on OS X have not worked:

$ /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
(works)

$ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your application bundle.

The .nib is present in the right place, but the binary does not see
them. Comparing the working and broken versions:

$ diff -r /Volumes/cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents \
/Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents |
diffstat
cmake-3.0.20140929-g5748a-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Resources |only
cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/4/Resources |only
cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtCore.framework/Versions/Current |only
cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/4/Resources |only
cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/Frameworks/QtGui.framework/Versions/Current |only
...
cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/BundleUtilities.cmake | 135 ++++++++--
cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/share/cmake-3.0/Modules/GetPrerequisites.cmake | 29 +-
16 files changed, 137 insertions(+), 36 deletions(-)

we can see that something in the frameworks is different and that
one of the only other changes is the BundleUtilities module.

Adam, Clinton, please take a look at this. If it cannot be resolved
in the next couple days I will have to revert this topic and drop it
from the 3.1 release.

Thanks,
-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Adam Strzelecki]

Post by Brad King
$ /Volumes/cmake-3.0.20140930-g37776-Darwin64-universal/CMake.app/Contents/bin/cmake-gui
Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your application bundle.

Did you build against Qt4 SDK taken from official installer? Can you put these both binaries somewhere (zipped) in the cloud?

BTW. Any reason to not use Qt5?

-- Adam
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Brad King]

Post by Adam Strzelecki
Did you build against Qt4 SDK taken from official installer?

It's a qt 4.8.0 installed from source.

configure --prefix=... -opensource -confirm-license \
-nomake demos -nomake examples -cocoa -shared -release \
-arch x86 x86_64

We also tried one with just "-arch x86_64" as part of trying to package
only that architecture, but it has the same problem.

Post by Adam Strzelecki
Can you put these both binaries somewhere (zipped) in the cloud?

Nightly binaries are always published here:

http://www.cmake.org/files/dev/

Specifically:

http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg
http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg

Post by Adam Strzelecki
BTW. Any reason to not use Qt5?

We already have the infrastructure set up to use Qt4 and it has
worked well for years. Prior to your patch the Qt5 package did
not work for redistribution due to the plugin problem 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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Robert Maynard]

Also as follow up the same Qt build is used for all Darwin64 releases and
nightlies. As far as I am aware this Qt build has been producing valid
deployable frameworks since before CMake 2.8.8

Post by Brad King

Post by Adam Strzelecki
Did you build against Qt4 SDK taken from official installer?

It's a qt 4.8.0 installed from source.
configure --prefix=... -opensource -confirm-license \
-nomake demos -nomake examples -cocoa -shared -release \
-arch x86 x86_64
We also tried one with just "-arch x86_64" as part of trying to package
only that architecture, but it has the same problem.

Post by Adam Strzelecki
Can you put these both binaries somewhere (zipped) in the cloud?

http://www.cmake.org/files/dev/
http://www.cmake.org/files/dev/cmake-3.0.20140929-g5748a-Darwin64-universal.dmg
http://www.cmake.org/files/dev/cmake-3.0.20140930-g37776-Darwin64-universal.dmg

Post by Adam Strzelecki
BTW. Any reason to not use Qt5?

We already have the infrastructure set up to use Qt4 and it has
worked well for years. Prior to your patch the Qt5 package did
not work for redistribution due to the plugin problem anyway.
-Brad

[Adam Strzelecki]

Please hold your breath, and don't yet revert my patches because you will end up with bundle that you cannot code-sign anyway for 10.10 and >=10.9.5 and it will be bad release that will be rejected by Gatekeeper upon launch.

First of all this is in fact Qt bug, please follow discussion at:

http://lists.qt-project.org/pipermail/development/2014-September/018505.html

The patches I provided, especially 55707fd5, were intended to workaround that so app will code-sign with >=10.9.5, especially for Qt case where their frameworks had incorrect layout causing code sign fail for whole bundle:

$ codesign -v --deep -s 'Developer ID' CMake.app
CMake.app: bundle format unrecognized, invalid, or unsuitable
In subcomponent: /private/tmp/CMake.app/Contents/Frameworks/QtCore.framework

As I used Qt5 for my own CMake build there is no problem with Qt5 here. But indeed I haven't try to build CMake against last stable Qt 4.8 (that is known to have incorrect layout).

Moreover Qt4 seeks hardly for Resources/ folder in framework root, which is not there anymore as it is not obligatory to have Resource/ symlinks. Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is as simple as:

(1) extra symlink Resources/ -> Version/Current/Resources/ (for sake of Qt SDK)
(2) ensure Info.plist in Version/4/Resources/

I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs.

Cheers,
--
Adam
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Brad King]

Post by Adam Strzelecki
http://lists.qt-project.org/pipermail/development/2014-September/018505.html
The patches I provided, especially 55707fd5, were intended to workaround that

[snip]

Post by Adam Strzelecki
I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs.

Regardless of where the bug lies, your changes took a packaging
case that worked and made it not work. That is a regression.
Working around it for the packaging machine of CMake itself is
not a solution because it could happen to any project built this
way.

Please extend your changes to restore successful packaging with
no special help by adding whatever workarounds are needed. If
the result is not signable when the workarounds are in place that
is okay because we couldn't sign before either.

Thanks,
-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Adam Strzelecki]

Post by Brad King
Regardless of where the bug lies, your changes took a packaging
case that worked and made it not work. That is a regression.

I am sorry, but 55707fd5 in fact does it CORRECT WAY as it is expressed in:

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html

and expected by code-sign.

Resources/ folder needs to lie in VERSION folder, so in out case QtGui.framework/Versions/4/Resources/

Previous CMake was checking and copying QtGui.framework/Resources/ which is WRONG as this is wrong place, and it may just be symlink to CORRECT place. But such symlink is not obligatory in final bundle.

It WAS working because Qt was looking in WRONG place for .nib file that was copied. Also before 10.9.5 it was code signing well because Apple put some heuristics to allow lousy bundles. But these were removed in 10.9.5 for code signed bundles.

But assuming we restore Resources/ optional symlink we can circumvent that. And I am working on the patch, just give me few minutes.

Post by Brad King
Working around it for the packaging machine of CMake itself is
not a solution because it could happen to any project built this
way.

I used wrong word, this was not workaround, but introduction of correct behavior. But I will add extra change that will restore Resources/ symlinks as well.

Post by Brad King
Please extend your changes to restore successful packaging with
no special help by adding whatever workarounds are needed.

If I remove all workarounds and do it ONLY correct way as Apple specified then apps using currently release Qt SDKs will not work :>

Please note this has been fixes in Qt 5.4 beta, so we could remove workarounds, but then only most recent Qt SDK would work fine.

If you need more information ping me on IRC.

--Adam
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Clinton Stimpson]

Post by Adam Strzelecki

Post by Brad King
Regardless of where the bug lies, your changes took a packaging
case that worked and made it not work. That is a regression.

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BP
Fr ameworks/Concepts/FrameworkAnatomy.html
and expected by code-sign.
Resources/ folder needs to lie in VERSION folder, so in out case
QtGui.framework/Versions/4/Resources/
Previous CMake was checking and copying QtGui.framework/Resources/ which
is
WRONG as this is wrong place, and it may just be symlink to CORRECT place.
But such symlink is not obligatory in final bundle.
It WAS working because Qt was looking in WRONG place for .nib file that
was
copied. Also before 10.9.5 it was code signing well because Apple put some
heuristics to allow lousy bundles. But these were removed in 10.9.5 for
code signed bundles.
But assuming we restore Resources/ optional symlink we can circumvent
that.
And I am working on the patch, just give me few minutes.

+1 for a symlink. Handling of framework resources in BundleUtilities.cmake
was originally based on the buggy Qt behavior. I think Adam's suggested fix
here is good.

And for the Qt internal error:

" Qt internal error: qt_menu.nib could not be loaded. The .nib file should be
placed in QtGui.framework/Versions/Current/Resources/ or in the resources
directory of your application bundle."

The message is incorrect. Qt is actually looking for the resource in
QtGui.framework/Resources/

Clint
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Brad King]

Post by Adam Strzelecki
But assuming we restore Resources/ optional symlink we can circumvent
that. And I am working on the patch, just give me few minutes.

Great, thanks!

-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Adam Strzelecki]

Done. Tested with Qt5 & Qt4, pushed as f9fcea6803f636adfc9f5755d9c92c802cdc2fb6 to stage/fix-OSX-bundle-rpaths-and-Qt5 (last commit to this branch).

@Brad: Shall I make it as separate branch and merge for staging, or you can simply cherry-pick it?

--Adam

commit f9fcea6803f636adfc9f5755d9c92c802cdc2fb6
Author: Adam Strzelecki <***@java.pl>
Date: Tue Oct 21 16:42:33 2014 +0200

Ensure framework symlinks and Info.plist exist

This restores Qt SDK 4.8 and >= 10.6.5 codesign compatibility improving
embedding frameworks using correct bundle layout described at:

https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html

1. If Versions/VERSION/Resources/Info.plist is missing, well known incorrect
locations are checked for Info.plist and Info.plist is copied from there,
otherwise codesign will fail.

2. Root framework symlinks to binary and Resources are restored to point inside
Versions/Current, otherwise Qt 4.8 looking for Resources/ in framework root
will fail.
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Brad King]

Post by Adam Strzelecki
@Brad: Shall I make it as separate branch and merge for staging,
or you can simply cherry-pick it?

I cherry-picked it over on top of the revised/squashed copy of
the topic that was merged to 'master':

BundleUtilities: Ensure framework symlinks and Info.plist exist
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2

I've merged it for testing in 'next'. Thanks for taking care
of this so quickly!

-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Brad King]

Post by Brad King
I cherry-picked it over on top of the revised/squashed copy of
BundleUtilities: Ensure framework symlinks and Info.plist exist
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41564ff2

The nightly binary works again. The first working version after
this gap is now:

http://www.cmake.org/files/dev/cmake-3.1.20141021-gffa1-Darwin64-universal.dmg

Thanks!
-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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Adam Strzelecki]

Post by Brad King
The nightly binary works again. The first working version after

Great! Now, do you plan code signing the CMake.app? Do you guys have Mac Developer ID?

--Adam
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Sean McBride]

Post by Adam Strzelecki

Post by Brad King
The nightly binary works again. The first working version after

Great! Now, do you plan code signing the CMake.app? Do you guys have Mac Developer ID?

The bug for that is here BTW, created over 2 years ago now...
<http://public.kitware.com/Bug/view.php?id=13532>

Cheers,
--
____________________________________________________________
Sean McBride, B. Eng ***@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Robert Maynard]

We have never symlinked Resources/ to Version/Current/Resources since we
place icons on other images under the Resources/ folder.

The Info.plist has always been placed in the root of Contents, and is still
there after the changes.

Post by Adam Strzelecki
Please hold your breath, and don't yet revert my patches because you will
end up with bundle that you cannot code-sign anyway for 10.10 and >=10.9.5
and it will be bad release that will be rejected by Gatekeeper upon launch.
http://lists.qt-project.org/pipermail/development/2014-September/018505.html
The patches I provided, especially 55707fd5, were intended to workaround
that so app will code-sign with >=10.9.5, especially for Qt case where
their frameworks had incorrect layout causing code sign fail for whole
$ codesign -v --deep -s 'Developer ID' CMake.app
CMake.app: bundle format unrecognized, invalid, or unsuitable
/private/tmp/CMake.app/Contents/Frameworks/QtCore.framework
As I used Qt5 for my own CMake build there is no problem with Qt5 here.
But indeed I haven't try to build CMake against last stable Qt 4.8 (that is
known to have incorrect layout).
Moreover Qt4 seeks hardly for Resources/ folder in framework root, which
is not there anymore as it is not obligatory to have Resource/ symlinks.
Also QtGui.framework misses Info.plist in Version/4/Resources/. So fix is
(1) extra symlink Resources/ -> Version/Current/Resources/ (for sake of Qt SDK)
(2) ensure Info.plist in Version/4/Resources/
I'll try build Qt4 SDK myself as you do and checkout what's the bundle layout of theirs.
Cheers,
--
Adam

[Adam Strzelecki]

We have never symlinked Resources/ to Version/Current/Resources since we place icons on other images under the Resources/ folder.
The Info.plist has always been placed in the root of Contents, and is still there after the changes.

Sorry, maybe I it wasn't clear enough but I am talking about Framework's root and bundled Frameworks layout not app bundle layout here.

--Adam
--
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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Stephen Kelly]

Post by Clinton Stimpson
Another justification for that is if a target does not link to any

Picking a message randomly, to respond to - Can someone tell me what this
comment is referring to?

# FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly
# Qt5 Mac support is missing there.

Thanks,

Steve.

[Adam Strzelecki]

Post by Stephen Kelly
Picking a message randomly, to respond to - Can someone tell me what this
comment is referring to?
# FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly
# Qt5 Mac support is missing there.

AFAIR it is about installing correct app bundle PlugIns. Qt provides half-baked CMake support, but some of necessary things still has to be done by user manually, such as installing cocoa platform plugin.

--Adam

[Stephen Kelly]

Post by Adam Strzelecki

Post by Stephen Kelly
Picking a message randomly, to respond to - Can someone tell me what this
comment is referring to?
# FIXME: This should be part of Qt5 CMake scripts, but unfortunatelly
# Qt5 Mac support is missing there.

AFAIR it is about installing correct app bundle PlugIns. Qt provides
half-baked CMake support, but some of necessary things still has to be
done by user manually, such as installing cocoa platform plugin.

If you can be more specific or explain why the Qt5 CMake files should
install a plugin for you, or whatever it should should do, feel free to file
bug reports or patches.

Thanks,

Steve.

[Brad King]

Post by Adam Strzelecki
Qt provides half-baked CMake support

Side note: this is not a fair characterization of Qt's support for CMake.
Qt5 is an outstanding example of how an upstream can make it easy to use
a project with CMake even when the upstream itself does not use CMake.
Qt5 provides package configuration files for find_package(), and once
loaded they provide imported targets with usage requirements. Building
a CMake-based project against Qt5 couldn't be much easier IMO.

Furthermore, all the CMake-related files come with Qt5 and are maintained
there rather than in CMake. This is much easier than Qt4, where FindQt4
in CMake has needed maintenance with every new upstream version.

-Brad

[Adam Strzelecki]

Post by Brad King
Side note: this is not a fair characterization of Qt's support for CMake.
(…)
Furthermore, all the CMake-related files come with Qt5 and are maintained
there rather than in CMake. This is much easier than Qt4, where FindQt4
in CMake has needed maintenance with every new upstream version.

Of course it is great that THEY provide official CMake support. Maybe "half-baked" is a bit harsh, but everything goes smooth until you try to run your freshly compiled Qt5 app in on the any other machine that the one it was compiled on.

First you realize you miss some Qt libraries you were linking to. Fine, fixup_bundle should do the job, but it doesn't.

----
$ hello.app/Contents/MacOS/hello
This application failed to start because it could not find or load the Qt platform plugin "cocoa".

Available platform plugins are: cocoa, minimal, offscreen.

Reinstalling the application may fix this problem.
----

The message isn't really helpful.

Finally after seeking googling for an answer you find out that there are "platform plugins" and there is no function or module that will help you to bundle them and create proper qt.conf. So all apps that are willing to use Qt5 (not Qt4 legacy version) need to have that manually.

This is why I call it half-baked.

But to be fair, Qt team is really welcoming and open for improvements, I am sure complete support will arrive sooner or later.

FYI I was working hard on relocatable Qt SDK for OSX for a while, it is almost complete. We were to release it for 5.4 but due some fancy testing suite problems probably this will be delayed. This was one of the reasons of my rpath support here. Otherwise once Qt SDK uses rpath it will immediately break CMake compatibility.

--Adam

[Stephen Kelly]

Post by Adam Strzelecki
But to be fair, Qt team is really welcoming and open for improvements, I
am sure complete support will arrive sooner or later.

As the person who wrote what Qt ships, I can say that it won't be 'complete'
sooner or later unless someone with enough interest communicates/contributes
what is missing. I don't have the requisite mac experience.

I also think there might be a generic solution (or partial solution) to
implement in CMake first (an interface for determining the package
dependencies perhaps, etc).

What makes this a Qt issue instead of a generic issue?

Thanks,

Steve.

[Adam Strzelecki]

Post by Stephen Kelly
As the person who wrote what Qt ships, I can say that it won't be 'complete'
sooner or later unless someone with enough interest communicates/contributes
what is missing. I don't have the requisite mac experience.

Sure, I believe someone will sooner or later submit patches to Qt.

Post by Stephen Kelly
I also think there might be a generic solution (or partial solution) to
implement in CMake first (an interface for determining the package
dependencies perhaps, etc).

CMake has everything necessary there install(...) & fixup_bundle(...).

Post by Stephen Kelly
What makes this a Qt issue instead of a generic issue?

$ git show 9b98fd52

install_qt5_plugin writing qt.conf and launching fixup_bundle should be part of Qt5 CMake support not part of app specific CMakeLists.txt (in this case CMake.app), e.g. single function install_qt5_bundle that does it all, selects default platform plugins and it is clearly documented somewhere.

Also on Qt SDK side there are couple of things to be done: QTBUG-14150 QTBUG-31814

--Adam

[Stephen Kelly]

Post by Adam Strzelecki

Post by Stephen Kelly
What makes this a Qt issue instead of a generic issue?

$ git show 9b98fd52

[Ignoring the qt.conf part]

Again, what is Qt-specific about bundling a plugin with an application? What
is non-generic about that?

Why can't CMake targets communicate what needs to be bundled with them? Why
can't some CMake interface consume such information?

Why would a install_qt5_bundle function bundle only the platform plugin, but
not other plugins?

Thanks,

Steve.

[c***@elemtech.com]

----- Original Message -----

Post by Brad King

Post by c***@elemtech.com
I pushed more fixes for this. Instead of requiring 10.6,
I took the other path of warning when rpaths need changed
at install time and skip it.
This should also fix the CMP0042 test which started failing.
+ msg << "WARNING: Target \"" << this->Target->GetName()
+ << "\" has runtime paths which cannot be changed during install.
"
+ << "To change runtime paths, OS X version 10.6 or newer is required. "
+ << "Therefore, runtime paths will not be changed when installing.";
+ cmSystemTools::Message(msg.str().c_str(), "Warning");

Can that be changed to an IssueMessage, possibly on a cmMakefile
for at least a little context? Also it should suggest using
CMAKE_BUILD_WITH_INSTALL_RPATH.

Post by c***@elemtech.com
By the way, Brad, your change to require 10.6 for the
BundleUtilities test is no longer required on the rpath-osx-10_6 topic.

I thought it was a missing piece of your original change.
Since you've reverted that I've now reverted mine so we'll
see how testing goes.

Post by c***@elemtech.com
However, it may still be required for the fix-OSX-bundle-rpaths-and-Qt5 topic.

I rebased rpath-osx-10_6 on fix-OSX-bundle-rpaths-and-Qt5 to
make local testing of both together easier. Please base the
OSX: Warn when attempting to change runtime paths on OS X 10.5
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a6e58f55

Adam,

I was looking at the BundleUtilities failure after the above fixes, and I noticed it unconditionally removes rpaths.
Is there a reason for that?

If the user does
set_target_properties(testbundleutils1 module1 PROPERTIES
INSTALL_RPATH "${CMAKE_CURRENT_BINARY_DIR}/testdir1"
BUILD_WITH_INSTALL_RPATH 1)

The new BundleUtilities.cmake will strip that rpath.
The attempt to strip those rpaths fails on OS X 10.5, because install_name_tool does not recognize the -delete_rpath.
The test fails because the -id and -change portion of the install_name_tool command is prevented by the error from the use of -delete_rpath.

Perhaps we can separate the -delete_rpath part into its own call to install_name_tool. If it fails, the failure can be ignored (as it previously ignored install_name_tool failures). Or maybe there is another idea.

Clint

[Adam Strzelecki]

I was looking at the BundleUtilities failure after the above fixes, and I noticed it unconditionally removes paths.

It does that because all bundles frameworks/libraries are referenced by @executable/loader_path and all @rpath references will be replaced, so there no point to have LC_RPATH in executables that will likely point to absolute old library locations.

Please note that this is just an extension to existing BundleUtilities behavior. I intentionally didn't want to support or add an option to bundle framework using @path + LC_PATH.

--Adam