Qt4 PortGroup: MacStrop vs MacPorts compatibility

[barracuda156]

@RJVB I am raising the issue here, since it is perhaps important, and important to figure out earlier rather than later (well, for me). We have briefly touched on this: I had my QMPlay2 build unexpectedly broken due to a switch to MacStrop Qt4 PGs, which leg to a different value for qt_plugins_dir. The error is trivial and easily fixable, but it is likely to pop up again elsewhere.

Ideally, it is desirable to have Qt4 both improved over what MacPorts has (at least for KDE4) and compatible with conventional MacPorts installs. That may or may not be possible, and if I were to choose only one, better functionality is preferred to compatibility. However, if this is the way to go, I need to know what to adjust locally, in a consistent manner, so that I can get reproducible builds, with binaries which can be then installed elsewhere (under assumption that all relevant ports are used from my tree). And the inverse: I need to know what not to change accidentally with my ports in MacPorts master.

qt_plugins_dir difference stems from here:

MacPorts qt4 1.0:

set qt_dir              ${prefix}/libexec/qt4
. . .
set qt_share_dir        ${qt_dir}/share
. . .
# standard Qt plugins directory
global qt_plugins_dir
if {${qt_dir} ne ${prefix}} {
    set qt_plugins_dir      ${qt_share_dir}/plugins
} else {
    set qt_plugins_dir      ${qt_share_dir}/${qt_name}/plugins
}

So here I get /opt/local/libexec/qt4/share/plugins, which is what my QMPlay2 port assumed.

MacStrop qt4 1.0 PG has this:

if {[info exists qt4_is_concurrent]} {
    set qt_dir              ${prefix}/libexec/${qt_name}
. . .
    set qt_plugins_dir      ${prefix}/share/${qt_name}/plugins
. . .
} else {
    set qt_dir              ${prefix}
. . .
    set qt_plugins_dir      ${qt_dir}/share/${qt_name}/plugins

So here I got /opt/local/share/qt4/plugins.

Given that current MacPorts setup has known problems with some Qt4 plugins, I certainly do not mean we should follow that pattern :) I just need to know what to adjust so that I get deterministic outcomes with my builds.

[RJVB]

On Monday August 12 2024 03:32:08 Sergey Fedorov wrote:

Given that current MacPorts setup has known problems with some Qt4 plugins, I certainly do not mean we should follow that pattern :) I just need to know what to adjust so that I get deterministic outcomes with my builds.

Easy really: if you never install from binary packages and plan to use (some) of my Qt4-based ports you install my port:qt4-mac and rebuild any Qt4-based ports you built before.

If you don't want to do the rebuild or want to be able to install binary packages of Qt4 ports the easiest solution should be to install symlinks in the missing directories under $prefix/libexec/qt4 that point to the actual locations where I install them. IIRC I do the same with my Qt5 port, apparently I never needed to do this for Qt4 (or never thought of testing binary compatibility).

Those symlinks shouldn't break anything.

Let me know which symlinks are required, and I'll have them created by my Qt4 port.

[barracuda156]

@RJVB Since apparently non-devel version is not maintained here https://github.com/RJVB/macstrop/blob/d5458bf6a10cdb450036c984b85e12d4580ccf67/aqua/qt4-mac-devel/Portfile#L14-L21 it makes sense to either adjust PG here to accommodate mainstream qt4-mac as well, or adjust qt4-mac to work with the PR (this I can do locally). Or is there any reason to have two ports? Maybe replace qt4-mac with the devel version, and then it is simple.

[RJVB]

On Saturday December 28 2024 23:23:25 Sergey Fedorov wrote:

Or is there any reason to have two ports? Maybe replace qt4-mac with the devel version, and then it is simple.

See #c94dc271f4694b21f96dc5f9310ecad13de53067 . I'll see if I can give this issue some attention this week but true compatibility will not be easy to achieve. (Replying by email so I don't have the full history at hand.)

[barracuda156]

To be explicit, my concern is not strict compatibility with whatever upstream MacPorts has (I am not gonna install pre-built apps for Qt4), I just need to avoid a situation which I faced earlier, when I locally build something with qt4-mac-devel, it works fine, then if I activate qt4-mac instead, the app is broken due to different dirs defaults. And likewise, if myself I build with qt4-mac-devel, then whoever installs apps via my PPCPorts should not have a broken package (by default non-devel ports will be installed).

[RJVB]

OK, that's a situation that I address in part in my Qt5 ports, by installing symlinks that expose "my" component directories via the paths where "their" install schema would put them. IOW, you can install my port as a drop-in replacement for the mainstream Qt5 port, and run prebuilt port images against it.

The reverse, activating the mainstream port and then expecting that anything built against my port will still work is much harder to achieve, if not impossible with Qt5 where I introduce a number of custom classes. I cannot recall that I do that with Qt4 but I'd still have to maintain a copy of the mainstream qt4-mac port to add the equivalent symlinks to it.

[barracuda156]

BTW another example of things not working in sync: lazarus does not find qt4pas (it worked with the standard qt4-mac).

(9001) Assembling (pipe) ../units/powerpc-darwin/qt/main.s
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_lazarus/lazarus/work/lazarus/ide/lazarus.pp(79,5) Hint: (5023) Unit "FPCUnitTestRunner" not used in Lazarus
(9001) Assembling (pipe) ../units/powerpc-darwin/qt/lazarus.s
(9022) Compiling resource ../units/powerpc-darwin/qt/lazarus.or
(9015) Linking ../lazarus
ld: framework not found Qt4Pas
An error occurred while linking 
Error: (9013) Error while linking
Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
make[2]: *** [lazarus] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_lazarus/lazarus/work/lazarus/ide'
make[1]: *** [bigide] Error 2
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_lazarus/lazarus/work/lazarus/ide'
make: *** [idebig] Error 2

qt4pas got installed with qt4-mac-devel like this:

Sergey-Fedorovs-Mac:~ svacchanda\$ port contents qt4pas
Port qt4pas @2.5_0 contains:
  /opt/local/libexec/qt4/lib/Qt4Pas.framework/Contents/Info.plist
  /opt/local/libexec/qt4/lib/Qt4Pas.framework/Qt4Pas
  /opt/local/libexec/qt4/lib/Qt4Pas.framework/Versions/5/Qt4Pas
  /opt/local/libexec/qt4/lib/Qt4Pas.framework/Versions/Current
  /opt/local/share/doc/qt4pas/COPYING.TXT
  /opt/local/share/doc/qt4pas/README.TXT

So that is not found.

P. S. Or maybe the PG does not handle installing it into where qt4-mac-devel expects.

@kamischi Could you please say how to let lazarus know of qt4pas location? I remember it was not trivial or at least not obvious.

[RJVB]

On Sunday December 29 2024 06:59:02 Sergey Fedorov wrote:

qt4pas got installed with qt4-mac-devel` like this:

/opt/local/libexec/qt4/lib/Qt4Pas.framework/

Does that port hardcode an install location? Still not at my Mac but it looks like the wrong path for Qt4 frameworks?

[kamischi]

I am following, but have no direct solution at hand. I really should have a go at it. The framework should be found through /opt/local/etc/fpc.cfg:

-Ff/opt/local/libexec/qt4/lib

[RJVB]

On Sunday December 29 2024 06:59:02 Sergey Fedorov wrote:

So that is not found.

The only other port I know of that installs a framework into $qt_dir/lib is port:qt-assistant, but that framework is used only by the Qt Assistant.

Either port:qt4pas will have to be fixed to install the framework to $qt_frameworks_dir (a variable that exists for a reason) - I assume the directory exists with a mainstream Qt4 build so creating a symlink in the destroot should be fine. Or else port:lazarus has to be patched so it looks for frameworks in $qt_libs_dir too.

[kamischi]

Minor clarification: The path to the framework is not set in the port lazarus, but in fpc through the file $PREFIX$/etc/fpc.cfg. So, it needs to be fixed there as well. Otherwise lazarus won't find it. Changing to $qt_frameworks_dir should not be a major problem.

[kamischi]

On Sunday December 29 2024 06:59:02 Sergey Fedorov wrote: qt4pas got installed with qt4-mac-devel` like this: /opt/local/libexec/qt4/lib/Qt4Pas.framework/ Does that port hardcode an install location? Still not at my Mac but it looks like the wrong path for Qt4 frameworks?

Not in the Portfile, I have to check the sources.

[RJVB]

On Sunday December 29 2024 14:30:15 Karl-Michael Schindler wrote:

Does that port hardcode an install location? Still not at my Mac but it looks like the wrong path for Qt4 frameworks?

Yes, I noticed that, and I got the same wrong install location when I built the port.

What really surprises me here is that my and the mainstream install schemas have the same qt_frameworks_dir and qt_libs_dir which is all that should be required to be linker-compatible. Supposing of course that the mainstream build actually puts the frameworks into $qt_frameworks_dir ...

[kamischi]

Yes, I noticed that, and I got the same wrong install location when I built the port. What really surprises me here is that my and the mainstream install schemas have the same qt_frameworks_dir and qt_libs_dir which is all that should be required to be linker-compatible. Supposing of course that the mainstream build actually puts the frameworks into $qt_frameworks_dir ...

It is not in the original sources, but then shows up in the Makefile, which I assume is created by qmake.:

snippet:

install_target: first FORCE
	@$(CHK_DIR_EXISTS) $(INSTALL_ROOT)/opt/local/libexec/qt4/lib/ || $(MKDIR) $(INSTALL_ROOT)/opt/local/libexec/qt4/lib/ 
	$(DEL_FILE) -r "$(INSTALL_ROOT)/opt/local/libexec/qt4/lib/Qt4Pas.framework"
	
	-$(INSTALL_DIR) "Qt4Pas.framework" "$(INSTALL_ROOT)/opt/local/libexec/qt4/lib/Qt4Pas.framework"

[barracuda156]

I might have used mainstream qmake PG, but given that @RJVB got the identical result, it should not have mattered.

[eirnym]

@barracuda156 out of curiosity, why to link with QT4, and not with QT6+? Recent QMplay2 officially supports QT5 and QT6

[barracuda156]

@eirnym If you want to help with fixing Qt6 for macOS 10.6 (i386 is fine, I can handle ppc then), please, a lot of people will be grateful. As of now, Qt4 is all we got.

[eirnym]

@barracuda156 I see. Now you've mentioned this and I understand your requirements better

[kamischi]

@eirnym In order to use Qt6 with lazarus or fpc, someone needs to translate the headers to Pascal.

[eirnym]

@kamischi there's already headers for Lazarus for QT6: https://wiki.lazarus.freepascal.org/Qt6_Interface

[barracuda156]

@eirnym By the way, re Qt6: if you know of anyone having fixed X11 backend for any macOS version, that may be helpful for fixing it for legacy OS. Cocoa will be surely broken for older macOS beyond repair. However, X11 backend in Qt6 is currently broken for the latest macOS either. If at least that is fixed, we have something to start from.

[kamischi]

@kamischi there's already headers for Lazarus for QT6: wiki.lazarus.freepascal.org/Qt6_Interface

Oops. I wasn't aware of that.

[barracuda156]

@kamischi Off topic, but btw:

[RJVB]

On Sunday December 29 2024 17:11:11 Karl-Michael Schindler wrote:

It is not in the original sources, but then shows up in the Makefile, which I assume is created by qmake.:

It is.

On Sunday December 29 2024 23:45:46 Sergey Fedorov wrote:

I might have used mainstream qmake PG, but given that @RJVB got the identical result, it should not have mattered.

I don't have a specific qmake PG for Qt4 because it shouldn't be necessary.

What exactly is in this fpc.cfg file, generic search paths or the paths to every individual known library?

[barracuda156]

Relevant to qt4pas is this:

# searchpath for qt4pas framework
#IFDEF Darwin
-Ff/opt/local/libexec/qt4/lib
#ENDIF

Which is set by this patch:

+# searchpath for qt4pas framework
+#IFDEF Darwin
+-FfPREFIX/libexec/qt4/lib
+#ENDIF

[RJVB]

On Monday December 30 2024 05:31:57 Sergey Fedorov wrote:

Relevant to qt4pas is this:

# searchpath for qt4pas framework
#IFDEF Darwin
-Ff/opt/local/libexec/qt4/lib
#ENDIF

If the build is hardwired to look in that location and the framework is installed there, how come it fails?

[RJVB]

ld: framework not found Qt4Pas

Doh moment: is that how the framework directory name is spelled and are you using a case-sensitive filesystem?

[barracuda156]

Nah, the system is not case-sensitive, so it should not matter. But it is certainly possible that this particular error is caused by something completely unrelated to Qt4 or qmake PG. I will need to try building lazarus +qt4 on the system where it has built earlier but with qt4-mac-devel and your portgroups. If that works, then the issue is local and unrelated.

BTW, does it matter if Qt4 is build with Cocoa as opposed to Carbon?

[RJVB]

No, the linker error is specific enough that it's unlikely to be a Cocoa vs. Carbon issue. But you'd have to get the build to produce more verbose output so we can see the exact invocation and hopefully other messages to put the error in context.

I see that the on-disk spelling is correct anyway so case can't be the issue here. Bummer.

[barracuda156]

No, the linker error is specific enough that it's unlikely to be a Cocoa vs. Carbon issue

On a more general note, will a port built with Qt4 +cocoa work on a system with Qt4 +carbon and vice versa?

[RJVB]

On Monday December 30 2024 06:49:12 Sergey Fedorov wrote:

On a more general note, will a port built with Qt4 +cocoa work on a system with Qt4 +carbon and vice versa?

That's going to depend on how well the backend is hidden. I've never tried so can't tell.