Hi Rene,

Thought I'd report progress. Short answer - it's not working so far.

Installed Qt 5.4.2 on a 10.11 machine into the /opt/local/libexec/qt directory, 
then tarballed it and installed it onto a 10.6 machine in the same directory.

The big apps (QTDesigner, etc) don't run on 10.6 due to some missing 
functionality, to no great surprise:
Dyld Error Message:
 Symbol not found: _NSPreferredScrollerStyleDidChangeNotification
 Referenced from: 
 Expected in: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit

In the new installed qt directory on the 10.6 machine, I can find the examples, 
for example in "/opt/local/libexec/qt/Examples/Qt-5.4/gui", and after editing 
the qmake.conf in 


I can qmake the .pro file (have to specify the right qmake now, of course)

so frome the gui sample directory

sudo /opt/local/libexec/qt/5.4/clang_64/bin/qmake -spec macx-clang

does generate a makefile and a .qmake.stash file

the .qmake.stash file has to be edited to change the compiler to macports 
clang, and after the initial try failed, I also removed the SDK spec to use 
system roots (as per the troubles with 10.6 with libcxx and qt4-mac)

QMAKE_MAC_SDK.macosx.path = /
QMAKE_MAC_SDK.macosx.version = 10.6
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CC = clang
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CXX = clang++
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_FIX_RPATH = \
   /Developer/usr/bin/install_name_tool \
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_AR = \
   /Developer/usr/bin/ar \
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_RANLIB = \
   /Developer/usr/bin/ranlib \
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK = clang++
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK_SHLIB = clang++
QMAKE_MAC_SDK.macosx.platform_name = macosx

and with all this, the build actually successfully proceeds through to 
completion and generates binaries for the gui examples.

Ultimately, though, running the example application hits an abort() trap in the 
QT core code

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib                   0x00007fff8988f0b6 __kill + 10
1   libSystem.B.dylib                   0x00007fff8992f9f6 abort + 83
2   org.qt-project.QtCore               0x00000001005df119 
qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&) + 9
3   org.qt-project.QtCore               0x00000001005e05d1 
QMessageLogger::fatal(char const*, ...) const + 161
4   org.qt-project.QtGui                0x000000010002a247 
QGuiApplicationPrivate::createPlatformIntegration() + 6359
5   org.qt-project.QtGui                0x000000010002a26b 
QGuiApplicationPrivate::createEventDispatcher() + 27
6   org.qt-project.QtCore               0x00000001007fa901 
QCoreApplication::init() + 113
7   org.qt-project.QtCore               0x00000001007fa877 
QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) + 39
8   org.qt-project.QtGui                0x0000000100027694 
QGuiApplication::QGuiApplication(int&, char**, int) + 228
9   com.medicalrounds.analogclock       0x0000000100003e24 main + 36
10  com.medicalrounds.analogclock       0x00000001000032a4 start + 52

so it looks like QT itself stops the run for some reason.

That's as far as I got with this so far. I know you got 5.4.x running on 10.6, 
so perhaps there's some further wrinkle I need to ponder ...

I think 5.3.2 might install on 10.6 (it does for homebrew, I understand). But I 
assume if we/I could get 5.4.x running instead then more qt5 apps might make it 
to 10.6 someday.

Anyway, thanks for your help.


On 2016-09-15, at 7:09 AM, René J.V. Bertin wrote:

> On Thursday September 15 2016 06:00:44 Ken Cunningham wrote:
>> have been using exactly the install prefix you suggest, as it turns out... 
>> well I put qt5 on the end, but otherwise the same.
> I'd have avoided /opt/local/libexec/qt5 in order to be able to put symlinks 
> in that directory, pointing into the real Qt install directory. Qt's 
> installer adopts a different layout, and it'll be easier to map that onto the 
> one expected by MacPorts (as defined in the Qt5 PortGroup) if 
> /opt/local/libexec/qt5 is still empty.
>> Been reading your posts to the qt5 interest mailing list for a few clues. I 
>> don't have your skills, but I do have some time, so I'll if I can make 
>> headway.
> What I have in mind is a Qt5 port that fetches a pre-configured tarball 
> somewhere that contains the install directory prepared by Qt's installer, and 
> then sets up symlinks in /opt/local/libexec/qt5. I think that stands a 
> reasonable chance of giving a functional Qt install AND port that could even 
> be a drop-in replacement for the other Qt5 port(s).
> Alternatively you could set up a very simple "shim" Qt5 port (with subports) 
> that each install just a single placeholder file, like my qt5-kde port does 
> in order to provide subports for the individual Qt components. Those ports 
> will only exist to satisfy dependencies; you'll have to compose your own 
> qt5-1.0.tcl PortGroup file to inform qt5-dependent ports where to find the 
> various Qt resources. For local use that should do just fine; you'll have to 
> put the shim port in a personal port repository; the PortGroup will go there 
> too but will have to be copied into the global PortGroup directory (and 
> copied again after each selfupdate).
> CC'ing macports-users as this may be of interest to others, too.
> R.

macports-users mailing list

Reply via email to