qt5 portgroup picks incompatible version of qt for Mac OS X 10.6 and earlier

[ryandesign (Ryan Carsten Schmidt)]

The qt5 portgroup​ picks qt55 as the version for Mac OS X 10.6 and earlier:

    if { ${os.major} <= 7 } {
        #
        # Qt 5 does not support ppc
        # see http://doc.qt.io/qt-5/osx-requirements.html
        #
        return qt55
        #
    } elseif { ${os.major} <= 9 } {
        #
        # Mac OS X Tiger (10.4)
        # Mac OS X Leopard (10.5)
        #
        # never supported by Qt 5
        #
        return qt55
        #
    } elseif { ${os.major} == 10 } {
        #
        # Mac OS X Snow Leopard (10.6)
        #
        #     Qt 5.3: Deployment only
        # Qt 5.0-5.2: Occasionally tested
        #
        return qt55
        #

qt55​ says it requires Mac OS X 10.7 or later:

if { ${os.major} < 11 } {
    pre-fetch {
        ui_error "${subport} requires OS X 10.7 or later"
        return -code error "incompatible OS version"
    }
}

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I suppose it would be possible for qt5.get_default_name to return an invalid Qt version for older systems.
However, that would complicate the later code (e.g. if ${qt5.name} ne "" ...).
I would prefer to avoid that if possible.

Currently, if a user tried to install a port which depends on Qt 5 on an older system, the port fails during pre-fetch of qt55-qtbase.
Is there a better place to fail?

[kencu (Ken)]

I have had some luck getting qt5 to work on some older systems:

$ port -v installed qt53-qtbase
The following ports are currently installed:
  qt53-qtbase @5.3.2_0+openssl (active) platform='darwin 10' archs='x86_64' date='2019-04-15T20:00:58-0700'

The linkages seem to be functional, and the binaries do work.

I have to work on the modules now -- but I think I have the hang of it, perhaps.

I think it is possible that with some modest patching, qt54 could possibly also be installable, but I know Marcus ran into some issues with that a while back when he tried.

[ryandesign (Ryan Carsten Schmidt)]

Marcus, I don't understand your comment at all. I thought the whole idea was that ports that want to use qt5 should include the qt5 portgroup, and the portgroup will pick the right version of qt5 to use for the user's OS version. On 10.6 and earlier, the qt5 portgroup currently picks a version of qt5 that is not compatible with the OS version. How can that possibly be considered to be correct/desirable/useful to anyone? Or are you saying that there is no version of qt5 that will work on 10.6 or earlier? I see that the comments say that is the case for 10.5 and earlier, but for 10.6 it suggests that 5.0-5.3 might work. Why doesn't the portgroup pick one of those versions for 10.6?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to ryandesign:

Marcus, I don't understand your comment at all. I thought the whole idea was that ports that want to use qt5 should include the qt5 portgroup, and the portgroup will pick the right version of qt5 to use for the user's OS version. On 10.6 and earlier, the qt5 portgroup currently picks a version of qt5 that is not compatible with the OS version. How can that possibly be considered to be correct/desirable/useful to anyone? Or are you saying that there is no version of qt5 that will work on 10.6 or earlier? I see that the comments say that is the case for 10.5 and earlier, but for 10.6 it suggests that 5.0-5.3 might work. Why doesn't the portgroup pick one of those versions for 10.6?

Forgive me if I have been unclear.
Currently, there is no version of Qt in MacPorts that works with macOS 10.6 or earlier.

macOS 10.3 and earlier cannot be supported because Qt 5 never supported PPC.
macOS 10.4 and macOS 10.5 were never supported by Qt 5, so it is unlikely we could get it to work on them.

Some time back, I tried to get Qt 5.3 working on macOS 10.6, but I ran into several problems.
Unfortunately, I cannot remember which modules failed off the top of my head.
Qt 5.3 listed macOS 10.6 as "Deployment only," so building Qt 5.3 on macOS 10.6 was never officially supported.
Even Qt 5.0-5.2 were only "Occasionally tested" on macOS 10.6.

We also start to run into the problem that at some point, older versions of Qt 5 stop being supported, so the effort of getting an unsupported version of Qt 5 on older systems might not be worth it.

From the previous comment, Ken seems to have made some progress, which is great.

It is somewhat unlikely this situation will be fixed any time soon (at least by me).
I worry that this ticket it destined to stay open for years with no resolution.
Currently, I think things fail as elegantly as they can on macOS 10.6 and earlier, so I am not sure what can be done, at least in the short term.

[kencu (Ken)]

I'm learning. I seem to dive in on the hardest things. I have qt53 building through now with the stock 10.6 SDK, no modifications needed. I had it use the c++11 build, and stayed with the c++11 PG and used clang-5.0 and cctools for the support. I think it looks do-able.

I may need some help sorting out the modules -- but we'll see.

[kencu (Ken)]

getting there:

$ port -v installed | grep qt53
  qt53-qtbase @5.3.2_0+openssl (active) platform='darwin 10' archs='x86_64' date='2019-04-18T18:46:51-0700'
  qt53-qtconnectivity @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T09:35:12-0700'
  qt53-qtdeclarative @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T00:07:55-0700'
  qt53-qtenginio @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T09:41:32-0700'
  qt53-qtgraphicaleffects @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T09:49:06-0700'
  qt53-qtimageformats @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T09:15:41-0700'
  qt53-qtlocation @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T10:02:53-0700'
  qt53-qtmacextras @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T10:10:51-0700'
  qt53-qtmultimedia @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T10:07:58-0700'
  qt53-qtquick1 @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T12:14:53-0700'
  qt53-qtquickcontrols @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T09:59:30-0700'
  qt53-qtscript @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T10:16:45-0700'
  qt53-qtsensors @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T09:55:59-0700'
  qt53-qtserialport @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-18T23:28:02-0700'
  qt53-qtsvg @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-18T23:14:10-0700'
  qt53-qttools @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T08:27:31-0700'
  qt53-qttranslations @5.3.2_0 (active) platform='darwin 10' archs='noarch' date='2019-04-19T09:52:07-0700'
  qt53-qtwebkit @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T11:59:03-0700'
  qt53-qtwebsockets @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T10:21:18-0700'
  qt53-qtxmlpatterns @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-18T23:22:12-0700'
  qt53-sqlite-plugin @5.3.2_0 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T09:10:27-0700'

Just have to sort out some kind of error building the documentation -- or disable the documentation.

[kencu (Ken)]

and, in then end, success. The qt5 version of wireshark2 builds and installs on 10.6.8.

$ port -v installed wireshark2
The following ports are currently installed:
  wireshark2 @2.6.8_0+cares+geoip+gnutls+kerberos5+libgcrypt+libsmi+portaudio+qt5+zlib (active) platform='darwin 10' archs='x86_64' date='2019-04-19T13:27:09-0700'

And runs, although not as snappy as all the included qt5.3 applications do, for some reason...

[kencu (Ken)]

Lyx +qt5 appears to work perfectly on 10.6.8, and is very fast and snappy.

$ port -v installed Lyx
The following ports are currently installed:
  LyX @2.3.2_0+python27+qt5 (active) platform='darwin 10' archs='x86_64' date='2019-04-19T14:17:53-0700'

It appears this is functional enough to consider working towards a PR for it.

[kencu (Ken)]

In 31eb5ecd575632a016a7119a1a3784e3ee587bea/macports-ports (master):

qt53: new port

adds qt5.3 support, primarily of use only to 10.6.8 at present

see: #58322

[kencu (Ken)]

Thamks, Marcus. As you saw, the only changes I left in the mkspecs for qt53 were:

1. the standard library spec. Without that, builds on non-libc++ systems were breaking.
2. allow deployment target 10.6 for libc++

I wanted to say that your qt5 support is elegantly designed, and without that structure, qt53 would have been nearly impossible. Thanks!,