qwt61 does not build for variant +qt5

[BSeppke (Benjamin Seppke)]

Following Ticket #49143, which seems to have already been fixed, I encountered another problem for the qwt port. The build and installation pass for the +qt5 variant, but result in wrongly linked dylibs. This forces macports to rebuild qwt61 three times before giving up.

I pinned the errors down to the librarys for qwt and the designer plugin. Here, the prefix path is missing for both, the lib itself and the linked lib (for the designer plugin). If I install the qwt61 manually from source using /opt/local/libexec/qt5/bin/qmake after setting:

QWT_INSTALL_PREFIX = QT_INSTALL_PREFIX and
QWT_CONFIG += QwtFramework 

in qwtconfig.pri I get the same wrongly linked binaries, which I am able to fix using sudo of:

#Patch qwt lib (inside framework)
install_name_tool -id /opt/local/libexec/qt5/lib/qwt.framework/Versions/6/qwt /opt/local/libexec/qt5/lib/qwt.framework/Versions/6/qwt

#Patch designer plugin
install_name_tool -id /opt/local/libexec/qt5/plugins/designer/libqwt_designer_plugin.dylib /opt/local/libexec/qt5/plugins/designer/libqwt_designer_plugin.dylib
install_name_tool -change qwt.framework/Versions/6/qwt /opt/local/libexec/qt5/lib/qwt.framework/Versions/6/qwt /opt/local/libexec/qt5/plugins/designer/libqwt_designer_plugin.dylib 

This should probably done in the Portfile, too. Another point is, that the qwt-Port currently promotes header and libs to the "global" /opt/local/include and /opt/local/lib directories. I think, we should disable this behaviour and always install qwt as a framework inside the corresponding qt4/5 directory. This will make it possible to have qwt61 installed for qt4 and qt5 in parallel without conflicts. All we would need for this is to promote the headers inside the corresponding qt installations. For qt5 e.g.:

#Promote headers
ln -s /opt/local/libexec/qt5/lib/qwt.framework/Versions/6/Headers /opt/local/libexec/qt5/include/qwt

Maybe this defect is a good opportunity to think about not just fixing qwt, but really improving it.

[BSeppke (Benjamin Seppke)]

Sorry, there is a typo in the settings above. I actually used:

QWT_INSTALL_PREFIX = $$[QT_INSTALL_PREFIX]

in the qwtconfig.pro file.

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers qwt61), if any.

[RJVB (René Bertin)]

I'll have a look at this too (also as a test-case for my proposed alternative qt5-kde port ... and because it'll expose any issues with building against 5.6.0).

In the meantime, may I suggest you compare with qca, which didn't pose any particular problems as far as coinstalling for Qt4 and Qt5 was concerned, as far as I can remember? Cf. ​https://github.com/RJVB/macstrop/tree/master/devel/qca for my implementation of a qca-qt5 subport.

[RJVB (René Bertin)]

Without any hacking, I'm only getting things installed under ${prefix}/share. I did notice a qmake remark about a missing target.path specification leading to things not being installed, I wonder if that's related.

In addition: why does this port not use the qmake PortGroup (qmake5, for Qt5)?

EDIT: Adding QwtFramework to QWT_CONFIG doesn't change anything in what gets installed. That's the first time I'm seeing this kind of behaviour with a qmake-based project. It looks that I do get a correct build against Qt4 (with the frameworks in Qt's Frameworks directory), but only when I use the qmake PortGroup. Without that, qmake-qt4 complains about the --prefix argument; I'm not sure why that wouldn't happen with the official Qt4 port and PortGroup.

In any case, I'd say that qwtconfig.pri should contain QWT_INSTALL_PREFIX, QWT_INSTALL_HEADERS etc. definitions that are set following the qt_dir, qt_includes_dir variables from the Qt PortGroup.

EDIT2: With Qt5, in order for the frameworks to be installed, one has to use QT_INSTALL_LIBS (with my Qt5 build but also with the official 5.4 install I still have around):

> /opt/local/libexec/qt5/qmake -query QT_INSTALL_FRAMEWORKS
**Unknown**
Exit 101

Doing this will put the frameworks under ${prefix}/libexec/qt5/, as one would hope. Of course this means different qwtconfig patchfiles are required for Qt4 and Qt5, or a else a reinplace of QT_INSTAL_FRAMEWORKS for Qt5.

That does *not* change the issue with the incomplete id in the generated frameworks. I'll look into that, I think there's a module one can include (or config to add) to store an absolute rpath, so that post-destroot magic isn't required.

[RJVB (René Bertin)]

I've attached a patch that tackles part of the problem. I haven't yet managed to get the proper "sonames" to be stored; neither the absolute_library_soname config nor setting QMAKE_INSTALL_SONAME in qwt.pro have the intended effect. Still, it shouldn't be necessary to invoke install_name_tool ...

[RJVB (René Bertin)]

Cc Me!

[info@…]

Could someone fix this please ? I need qwt with qt5 working

[mkae (Marko Käning)]

Cc Me!

[dmarteau (David Marteau)]

Is there somebody working on it ?

Thx

[dmarteau (David Marteau)]

Cc Me!

[BSeppke (Benjamin Seppke)]

Hi,

to keep a long story short, I switched to the new QtCharts framework for my projects. The framework comes with Qt 5.7. However, since MacPorts only supports Qt 5.6, I needed to install them manually.

Best wishes Benjamin

[RJVB (René Bertin)]

Benjamin: do you mean you got QtCharts to build against Qt 5.6? It's been on my list to upgrade my qt5-kde-devel port to 5.7, but I keep getting side-tracked (and I like the idea of a LTS release a bit too much...)

Either way, what are the remaining issus with qwt61 after applying my patch? My remarks above (comment 5) are still valid, though I see I could have been more specific. The real issue is that the rpath isn't stored in the frameworks.

[BSeppke (Benjamin Seppke)]

OT: I downloaded qtcharts from GitHub and compiled it against 5.6, yes.

I didn't see any problems with the patch, but are the sonames fixed with it, too? Otherwise, I would suggest putting the commands of my initial posting (install_name_tool....) in a qt5-depending post-install section.

[RJVB (René Bertin)]

No, your install_name_tool commands or similar are still required. There must be a better way to do that though, one where all dependents built by the port itself (the Designer plugin, the examples) use the correct rpath.

FWIW, building on Linux has the same issue; the build system is designed with the idea in mind that the libraries are installed somewhere where the dynamic loader (dyld, ld.so on Linux) can find them.

[RJVB (René Bertin)]

I think I've nailed it - possibly thanks in part by an upgrade to the latest qwt 6.1(.3).

Works for me now, no install_name_tool magic required.

[slarew]

Replying to RJVB:

I think I've nailed it - possibly thanks in part by an upgrade to the latest qwt 6.1(.3).

Works for me now, no install_name_tool magic required.

Your qwt61.diff patch worked for me. Thanks!

[michaelld (Michael Dickens)]

Looks like this issue was fixed in ​https://github.com/macports/macports-ports/commit/821897a06b932011c3edcb30c719ecc8bd882f60 . Thus I'm closing this ticket.