After doing the exact same thing on a Windows machine I was able to compare all Makefiles. I noticed that the main Makefile on OSX was lacking all Qt' modules (SUBTARGETS was empty). So I started to find out why this happend. After a while I noticed that the .gitmodules file was in a different location comparing to the Windows setup. After moving it into the src/ dir the make command finally started to work.
I'm not sure why it moved but maybe it is a bug in Keka so it doesn't handle dot prefixed files correctly.
I'm pretty sure that macdeployqt isn't working correctly for code that's protected. It appears that the @rpath items in the executable are not being allowed for this code. You can use @loader_path instead. But fixing that would require not only fixing the paths in the executable itself, but also in the Framework libraries.
I'll file a bug report for this, though I'm really not familiar with OSX it appears this is the way things are supposed to work.
BTW I'm STILL seeing the crash in the plugin--unfortunately I'm not getting any useful crash report. It looks like what happened earlier; the code is failing in createPlatformIntegration. I see these messages in the Console log:
8/18/16 3:14:17.054 PM com.apple.xpc.launchd: (com.apple.WebKit.Plugin.64.E77BAC61-F958-4FF7-9D28-01F88EAF0E5C) Service exited due to signal: Abort trap: 6
8/18/16 3:14:18.154 PM com.apple.WebKit.Plugin.64: Failed to connect (colorGridView) outlet from (NSApplication) to (NSColorPickerGridView): missing setter or instance variable
8/18/16 3:14:18.154 PM com.apple.WebKit.Plugin.64: Failed to connect (view) outlet from (NSApplication) to (NSColorPickerGridView): missing setter or instance variable
8/18/16 3:14:18.000 PM kernel: Process crashed: com.apple.WebKit. Too many corpses being created.
I'm not sure what happened with the code, but now it's finally giving me an error signal. The error and error string are QMediaPlayer::FormatError "Failed to load media"
The media I'm attempting to load uses the file ending ".mp4". I finally thought of opening the media in Quicktime and, lo and behold, it won't open the file. It appears I'm dealing with a "Not a real operating system" error.
EDIT: It appears that what happened was that I was trying to open a 0 byte file. Opening an .mp4 file with actual content still causes the MediaPlayer to get stuck in the LoadingMedia status.
Dear @peniwize, I am not aware of direct entry of special symbols in QLineEdit in MAC but in WINDOWS OS we can do with the help of ALT key and the symbol code. Basically go to Character Map and select the special symbol then you will be able to see the corresponding Key code to that special character. Just hold ALT symbol and enter the code from num pad by enabling NUM LOCK. Then release the ALT key. That special symbol will automatically appear in the QLineEdit in Windows. May be something similar you can try in MAC OS too.
Yes, Qt is kind of braindead :-) before QApplication a(argc, argv); not many things work; it tries to load the libqcocoa.dylib when you specify that Fusion setting line, and because you did it before the QApplication constructor, Qt hasn't found and read in qt.conf file (written by macdeployqt, it tells Qt where to find libqcocoa.dylib). That's why moving the Fusion setting after makes Qt much happier.
P.S. Actually you can get around this error in another way than by moving the Fusion setting line: by copying the PlugIns folder (created by macdeployqt in example.app) and place it together with the .exe/ELF file (MacOs/example). Because then Qt can load the Cocoa plugin without having read any qt.conf file.
Above, I describe a small stub setup that downloads a larger payload. However, if your payload is large from the server, you're going to be looking at the screen stuck at the "Running package scripts..." notice and a jammed progress bar while it continues to download over Curl your larger payload. One solution to that in your preinstall Bash script is to do this:
osascript -e 'tell application "System Events" to set visible of process "Installer" to false'
That super neat trick hides the installer so that you can show something else. That way, the customer doesn't think your installer just jammed.
Then, build yourself a simplistic ObjectiveC application that looks just like that Installer but shows a more active progress bar (use a timer) and then displays a few messages like "Downloading..." and "Finishing download..." and stuff like that. Of course, you can do it in Qt, but even the most minimum Mac-based Qt widget app (not statically compiled) is 8.9MB zipped, whereas in ObjectiveC you can make an app that does the same thing in a mere 32K (unzipped). (Oh, and for you QML die-hards out there, a widget-based app has you topped on file size. I was seeing 12.1MB zipped for something comparable in QML.)
Once that Curl has finished, it can then kill the ObjectiveC process and reverse the osascript to get the installer to show you the Finish page.
If deploying a large commercial application, and especially if you need to hook up special high-permission items and require script control, then you may not want to use either the .pkg or .dmg formats at all. This is because, psychologically, customers are not likely to want to download a huge honking 200MB+ DMG or PKG file. Instead, they would be more likely to download a smaller file, run it, and then when it says Installing, it does the rest of the download steps. (I know it's the same wait time, but psychology is important in product marketing.) Take a look at Norton's Antivirus for the Mac. (There's a free trial on their website.) They basically made an ObjectiveC / Cocoa application and then zipped it. However, it's a stub setup that's very small. When you run it, it then shows the typical EULA and then starts downloading components from the web, and putting things into the appropriate places.
As you mentioned, it seems that DYLD_* variables have been disabled (they are ignored) since El Capitan because of a new feature called System Integrity Protection (SIP). According to Apple Developer website, debugging can be happily performed only by Xcode (although I haven't tried it yet). What about Qt? Will 5.5.1 or 5.6 allow debugging on El Cap with SIP?
I read on another page SIP can be disabled in Recovery mode. Anyway, I am not keen at hacking my own system... the alternative is to wait for the next version of Qt and hope for a solution. Unsure what to do for now, in the meanwhile I am stuck! Grrr
UPDATE: I ended up disabling SIP following the following step:
Enter Recovery mode (Cmd+R on startup)
csrutil disable; reboot
Now debugging went back to normality!
My only doubt is that when i do csrutil status, I receive the following message:
Thank you very much, I used the work-around they proposed
(storing a copy of the certificate in the local resources of the app & adding that to the default CACertificate list before opening the socket)
I'm afraid this won't be a clean long term solution though (the certificate will stay valid for a while, but eventually expires I guess).
If anyone has any idea's for a more clean/permanent solution I'm very much open to suggestions.
In the mean time this will have to do.
Thanks again, I appreciate the comment
Yes, indeed I can show website over https with WebEngine, even though it still show those warning messages. As documented here, Web Kit will be deprecated in Qt version 5.5+, so I'll switch to use WebEngine then.
For those who feel annoyed with the warning messages, you could suppress them by calling following method in your main()