Mac deployment problem

[marksutton]

I have a QT application written primarily in Windows that I'm trying to make a Mac conversion of (compiling with QtCreator on as OSX 10.6 machine). It uses QT 4.7.3, and VTK (Visualisation Toolkit) 5.6 (NOT using the QVTK widget). VTK compiled statically.

Program runs fine through creator, and also runs fine if I run the executable from the command line with 'open'. If I try to run the .app bundle though it crashes with an unhelpful segmentation fault message.

I suspect this must be something to do with libraries/frameworks, BUT I get the same crash whether or not I have run macdeployqt on the package. otool -L reports (before macdeployqt)

/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
QtXml.framework/Versions/4/QtXml (compatibility version 4.7.0, current version 4.7.3)
QtCore.framework/Versions/4/QtCore (compatibility version 4.7.0, current version 4.7.3)
QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.7.0, current version 4.7.3)
QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current version 4.7.3)
QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.7.0, current version 4.7.3)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

and after macdeployqt

/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
@executable_path/../Frameworks/QtXml.framework/Versions/4/QtXml (compatibility version 4.7.0, current version 4.7.3)
@executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.7.0, current version 4.7.3)
@executable_path/../Frameworks/QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.7.0, current version 4.7.3)
@executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current version 4.7.3)
@executable_path/../Frameworks/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.7.0, current version 4.7.3)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 830.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)

Two other programs using the same version of QT (but not VTK, zlib, or quite as many QT libraries) work fine... app bundle runs without a hitch. I have tried removing all zlib references from program in case it was that, but same problem. Have previously compiled an older version of the same problematic program a few years back with QT 4.5 and VTK 5.4, without running into this issue.

Does anyone have any idea at all what I can try next... have wasted hours on this and am no closer to a solution! Even suggestions as to how to continue investigating would be appreciated.

Thanks in advance!

Mark

[nosleduc]

macdeployqt runs only on your executable (Foo.app/Contents/MacOS/foo). It doesn't change the install-names of your librairies.

You can check this with otool -L applied to your VTK library located at YourApp.app/Contents/Frameworks if it was copied there.
You will find some wrong install_names I assume.

[goetz]

Do you have any plugins or other libraries in use?

If it is possible for you (legally for instance), can you put the app bundle somewhere on a public server? I would have a look then.

[marksutton]

Volker - thanks, link to app bundle below:

https://fileexchange.imperial.ac.uk/int/d6e79bacf29/SPIERSview2.zip

This after running macdeployqt I think - I don't have the Mac in front of me, had to rely on a very non-computer literate colleage to send me the file, asking him to check the details of the package a bad idea!

No plugins or dependencies as far as I know except VTK, QT, zlib - VTK linked statically so no framework library to otool...

Thanks! Hope you can solve this!

M.

[goetz]

Thanks for the link, just downloading it. I'll have a look into it later on - please stay tuned.

[goetz]

Just checked it. It's really weird. If I call the application with the full path to the executable (eg. /Users/me/SPIERSview2.app/Contents/MacOS/SPIERSview2) it works without a crash (a terminal window is opened then). If I open the application bundle (open /Users/me/SPIERSview2.app), it crashes. I cannot see any odd settings in the bundle and it's not cleare when it actually crashes.

In your case, I would put a lot of QMessageBox::info() into the code, to see at what location the application crashes. As it is a segmentation fault, I would guess for some oddly or not initialised pointer or something that depends on a environment variable or the like.

[marksutton]

Glad you think it's weird too. It crashes pretty early - not much code before that dialog pops up. I'd tried lacing it with debug prints and if memory serves had found that it didn't even get the first line in main out before crashing (hence me thinking it was a library problem). But as all else is pretty much eliminated, I'd better try this again...

Thanks for trying. Will let you know what problem was if I ever solve it!

M.

[goetz]

In that situation, I would go back almost all steps: Create a really simple hello world application and look if that runs with macdeployqt processing it. Then add one feature (include a Qt module library like QtXml) after another and always rebuild everything. You may add the statically linked libs first. At some point it should stop working again.

[marksutton]

Yes, I guess I'll have to. Might take all day though :(

[goetz]

Yes, unfortunately it's almost always these "little" problems that cost you more time than the actual application development :-/