Hi Hannah, I was working for a long time today with getting Qt to build in craft on my Mac and getting everything required for KStars to build properly on top of that since you told me I shouldn’t be using ~/Qt/5.11.1. The issue really comes down to one thing: @rpath. I am not as familiar with @rpath linking because In our build script that we have used for 2 years for building kstars on Mac, we typically used absolute paths when building and linking everything and then when we went to make a dmg that could be transferred elsewhere, we had a separate script that ran macdeployqt, then automatically went through all the libraries and executable files kstars needed, copied them into the app, and ran otool and install name tool on them to get them all pointing to the right places. When we bundled it all up, we used @loader_path, not @rpath. So probably some of my issues are related to my inexperience with @rpath. There are several issues I was having.
1. Several already existing blueprints for libraries have issues with @rpath and building based on QT when they are dependencies of another library or application. When I was doing this with the external QT in ~/Qt/5.11.1, this was not an issue for most of these, but for some reason it is when building them based on craft built qt. For example, if I try the command “craft -vvv -i kstars”, many dependencies must be built. Several of them fail, saying something like this: "dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore” (or other QT libraries) but then if you look, the file really is located in craft’s lib directory. If you try the package that failed again by itself, for example like this: "craft -vvv -I kconfig” it succeeds. Then you can continue until the next one fails. I’m not sure if there is some issue with setting the rpath for these dependencies or something with the way Qt was installed, but for some reason it fails when you try to install it as a dependency but then succeeds later when you install it individually. Here is the list of what I had to do instead of just saying "craft -vvv -I kstars” due to the failures: craft -vvv -i kconfig craft -vvv -i kdoctools craft -vvv -i breeze-icons craft -vvv -i kcoreaddons craft -vvv -i kservice craft -vvv -i sonnet craft -vvv -i libjpeg-turbo craft -vvv -I kstars 2. Some executables don’t have their rpath list set correctly. This makes the program not able to resolve anything linked with rpath. This may be more my problem than yours but I’m not sure what I need to do. I fixed this problem on my system for kstars by running : install_name_tool -add_rpath /Users/rlancaste/AstroRoot/kstars-craft/lib /Users/rlancaste/AstroRoot/kstars-craft/Applications/KDE/kstars.app/Contents/MacOS/kstars. Once I did this, anything that used @rpath in the linking to kstars could be found. But I’m not sure if something just needs to be corrected in my blueprint or if this is supposed to happen automatically. Or if I messed something up. 3. Some libraries have their install names set incorrectly. I have been having an issue for awhile with libraw, libnova, and libjasper in particular. If they have the wrong install name, then during the linking step they will not be linked properly. I’m not sure if it is just these or if there are any others, but they are the ones that have given me the most headaches. For example, for libraw, instead of having an install name of "@rpath/libraw.15.dylib" or "/Users/rlancaste/AstroRoot/kstars-craft/lib/libraw.15.dylib", it just had "libraw.15.dylib” which meant that kstars could not find it at all. I have solved this problem a couple of different ways, but I don’t think they are the correct solutions. Here is an example of a way that I have fixed this before linking: install_name_tool -id @rpath/libjasper.dylib libjasper.dylib Here is an example of how I have fixed this after linking: Install_name_tool -change libraw.15.dylib @rpath/libraw.15.dylib kstars Both fixes work, but the second one would have to be redone every time kstars is built. I am wondering whether there is something in the blueprint that makes cfitsio work correctly, but makes libnova or libraw fail. One thing I tried is changing the blueprint to make libraw and libnova build with auto tools without the patches applied. This did in fact work, although it also produced an absolute linking path instead of an rpath. So I am assuming this is something in the patches or something with the cmake build system? 4. I’m not sure if this is a problem or not, but there are some inconsistencies about how things are linked. Some are linked using @rpath, some are linked using absolute paths, and as I mentioned above, some aren’t linked correctly at all. For our kstars build script, the different linking strategies did not matter since it changed them anyway. I’m not sure about the craft methods of deployment though. Does it matter if some of the libraries are linked with absolute paths and some with rpaths? Thank you for your help! Rob
