OSX Slicer Qt5 packaging error

Having trouble packaging a slicer build on my mac OSX high sierra machine. I installed Qt 5.9.2 using the prebuilt binary installed using the Qt open-source download from the Qt website. I successfully built the latest commit of slicer and slicer works great. Now I want to package this build into a dmg install file, but I am having some trouble. The build target steps work fine. Then when it goes to the cpack steps it starts to complain repeatedly about finding Qt using the rpath. Here is an example output:

warning: target ‘@rpath/Frameworks/QtCore.framework/Versions/5/QtCore’ is not absolute
warning: target ‘’@rpath/Frameworks/QtCore.framework/Versions/5/QtCore’ does not exist
@rpath/Frameworks/QtCore.framework/Versions/5/QtCore’: No such file or directory

Since these are just warnings cpack continues, but then at the end the pack fails and says error converting to UDCO dmg for adding SLA. hdiutil: convert failed - Resource temporarily unavailable. Anyone else experience these issues and know how to remedy it?

1 Like

Regarding the hdiutil error, you may have incorrectly unmounted the disk image during a previous run. Just google the message, see e.g.

As far as the RPATH warnings, if they do cause the packaged application to fail to start, the quick fix is to manually add the appropriate RPATH to the slicer binary using otool or install_name_tool. For a general fix you’ll need to read up on RPATHs and how to tell CMake and CPack to set and use RPATH in the Slicer binary. Grep for fixup to see the existing logic.

Thanks for the advice. I tried the suggestions for hdiutil and I still can’t get it to run. I manually attached the temp.dmg file then detached it and reran the hdiutil convert command and it still says resource temporarily unavailable. Plus, if I rerun make package then it will clear out the temp.dmg and remake it. So I still can’t get it to package…

Well, if you post the full build log maybe someone will see an issue (gist.github.com, pastebin, etc.). Generally speaking, Qt5 is still an experimental configuration, so probably some aspects of packaging remain to be addressed.

Some pointers for others that are having these same issues. You must install Qt using homebrew because that build has the rpath turned off. Using that build gets rid of all of the complaints about the rpath. Then came the complaints about finding libqcocoa. I manually resolved this by copying it from qt/5.9.2/plugins/platforms/libqcocoa.dylib to Slicer-build/_CPack_Packages/macosx-amd64/DragNDrop/Slicer-4.9.0-2017-11-16-macosx-amd64/Slicer.app/Contents/lib/Slicer-4.9/ after that folder is created during packaging.

That solved those problems. Now onto the hdiutil error. When cpack runs the command to convert temp.dmg to UDZO format creating the filename temp-udzo.dmg hdiutil fails everytime saying Resource temporarily unavailable. I have tried attaching the temp.dmg and then detaching it but it doesn’t remedy the problem. What works is if I rename temp.dmg to temp2.dmg and then copy temp2.dmg to temp.dmg and then run the hdiutil convert it works perfectly.

The problem I have is I do not know what the next steps are after that. If I rerun make package then it just starts over from the beginning clearing out the _CPack_Packages. Where do I find what the next steps are for packaging so I can manually perform them?

1 Like

Not sure if you got further along here, but I ran in to some issues while packaging Homebrew (qt4) and have submitted a few fixes:

Just to follow up here – after these fixes I got a package built, but the resulting Slicer would not start on another computer because of missing dependencies. Later I found some comments in the homebrew github saying they very explicitly do not support this separate re-packaging use-case (they do support linking Qt as a dependency when building/distributing an app via homebrew, of course). IIRC one issue is they don’t build with RPATH at all, and there was also an issue with the version of SSL they link against. I think both issues were not technically infeasible to overcome, but don’t seem worth the time to fix compared to just building Qt from scratch.