MXE with Qt5.11.1 and missing map

[Stefan Fuchs]

Hallo Dirk,

did you successfully manage to update your MXE to Qt5.11.1 as well?
I tried to do this a few days ago but I now see a issue with map not
displayed. Instead I do see the "QML module QtLocation and
QtPositioning" error. But as far as I can see DLLs are there in version
5.11.1

In the shell I have this error:
qrc:/qml/MapWidget.qml:4:1: plugin cannot be loaded for module
"QtPositioning": Die Bibliothek C:\Program Files
(x86)\Subsurface\qml\QtPositioning\declarative_positioning.dll kann
nicht geladen werden: Das angegebene Modul wurde nicht gefunden.
QUrl("qrc:/qml/MapWidget.qml") failed to load with status:
QQuickWidget::Status(Error)


Viele GrÌße
Stefan

Qt 5.11 adds useful warnings when code attempts to use anchors within
Layouts and even tells you how to fix things.
* Bug fix
* Functional change
* New feature
* Code cleanup
* Build system change
* Documentation change
* Language translation
It seems weird to add this so late in the cycle - but I finally had
enough bandwidth to update my development machine to Qt5.11
This does seem to fix an actual bug that was just silently ignored before.
not user visible
@janiversen <https://github.com/janiversen> @mfbernardes
<https://github.com/tcanabrava> - I'd love a sanity check from people
who have played with QML :-)
------------------------------------------------------------------------
  https://github.com/Subsurface-divelog/subsurface/pull/1426
Commit Summary
* QML UI: don't use anchors within Layouts
File Changes
* *M* mobile-widgets/qml/CloudCredentials.qml
<https://github.com/Subsurface-divelog/subsurface/pull/1426/files#diff-0>
(10)
* *M* mobile-widgets/qml/DownloadFromDiveComputer.qml
<https://github.com/Subsurface-divelog/subsurface/pull/1426/files#diff-1>
(24)
* https://github.com/Subsurface-divelog/subsurface/pull/1426.patch
* https://github.com/Subsurface-divelog/subsurface/pull/1426.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/Subsurface-divelog/subsurface/pull/1426>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AYJK0tXUCT3zMxsmjM8alyoRCXaxi4Adks5uAKQogaJpZM4U1v2s>.

[Dirk Hohndel]

Post by Stefan Fuchs
did you successfully manage to update your MXE to Qt5.11.1 as well?

No, given some of the problems we found with 5.11 and given how close to our planned release 5.11.1 came out I decided not to try to update the build environments for Windows, Mac, iOS, Android, and the AppImage to Qt 5.11.1 - whenever we switch to a new Qt release that's a massive amount of work for me (and at times I end up not being able to have all the OSs on the same Qt version which also causes additional pain). So this is on my todo list for after the 4.8/2.1 release.

Post by Stefan Fuchs
I tried to do this a few days ago but I now see a issue with map not displayed. Instead I do see the "QML module QtLocation and QtPositioning" error. But as far as I can see DLLs are there in version 5.11.1

I saw similar feedback from people building with 5.11 on some Linux flavors. I upgraded my Arch Linux yesterday and the map worked there - but as I said, I haven't played with this for MXE. My guess would be that it's not the DLLs but the qml modules that are missing.

Post by Stefan Fuchs
qrc:/qml/MapWidget.qml:4:1: plugin cannot be loaded for module "QtPositioning": Die Bibliothek C:\Program Files (x86)\Subsurface\qml\QtPositioning\declarative_positioning.dll kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden.
QUrl("qrc:/qml/MapWidget.qml") failed to load with status: QQuickWidget::Status(Error)

I take it back, it clearly is looking for a DLL. And when you look at the installed version, the library is right where Subsurface is looking for it? Or is it missing from the installer?

/D

[Stefan Fuchs]

Hallo Dirk,

Refreshing your memory regarding QtPositioning plus finally answering your question below...

Post by Dirk Hohndel

Post by Stefan Fuchs
I tried to do this a few days ago but I now see a issue with map not displayed. Instead I do see the "QML module QtLocation and QtPositioning" error. But as far as I can see DLLs are there in version 5.11.1

I saw similar feedback from people building with 5.11 on some Linux flavors. I upgraded my Arch Linux yesterday and the map worked there - but as I said, I haven't played with this for MXE. My guess would be that it's not the DLLs but the qml modules that are missing.

Post by Stefan Fuchs
qrc:/qml/MapWidget.qml:4:1: plugin cannot be loaded for module "QtPositioning": Die Bibliothek C:\Program Files (x86)\Subsurface\qml\QtPositioning\declarative_positioning.dll kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden.
QUrl("qrc:/qml/MapWidget.qml") failed to load with status: QQuickWidget::Status(Error)

I take it back, it clearly is looking for a DLL. And when you look at the installed version, the library is right where Subsurface is looking for it? Or is it missing from the installer?

The new 5.11.1 library file was there in the right position. No clue why Qt complained.

[Dirk Hohndel]

Post by Stefan Fuchs
Hallo Dirk,
Refreshing your memory regarding QtPositioning plus finally answering your question below...

Post by Dirk Hohndel

Post by Stefan Fuchs
I tried to do this a few days ago but I now see a issue with map not displayed. Instead I do see the "QML module QtLocation and QtPositioning" error. But as far as I can see DLLs are there in version 5.11.1

I saw similar feedback from people building with 5.11 on some Linux flavors. I upgraded my Arch Linux yesterday and the map worked there - but as I said, I haven't played with this for MXE. My guess would be that it's not the DLLs but the qml modules that are missing.

Post by Stefan Fuchs
qrc:/qml/MapWidget.qml:4:1: plugin cannot be loaded for module "QtPositioning": Die Bibliothek C:\Program Files (x86)\Subsurface\qml\QtPositioning\declarative_positioning.dll kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden.
QUrl("qrc:/qml/MapWidget.qml") failed to load with status: QQuickWidget::Status(Error)

I take it back, it clearly is looking for a DLL. And when you look at the installed version, the library is right where Subsurface is looking for it? Or is it missing from the installer?

The new 5.11.1 library file was there in the right position. No clue why Qt complained.

I ran into this on Mac - the error message makes no sense, but it was fixed by making sure QtPositioningQuick was included in the bundle. Maybe it's something similar on MXE?
Look at this commit: https://github.com/Subsurface-divelog/subsurface/commit/4595ccb9f993160eee25f242feb092566dfe3061 <https://github.com/Subsurface-divelog/subsurface/commit/4595ccb9f993160eee25f242feb092566dfe3061>

/D

[Dirk Hohndel]

Post by Dirk Hohndel

Post by Stefan Fuchs
Hallo Dirk,
Refreshing your memory regarding QtPositioning plus finally answering your question below...

Post by Dirk Hohndel

Post by Stefan Fuchs
I tried to do this a few days ago but I now see a issue with map not displayed. Instead I do see the "QML module QtLocation and QtPositioning" error. But as far as I can see DLLs are there in version 5.11.1

I saw similar feedback from people building with 5.11 on some Linux flavors. I upgraded my Arch Linux yesterday and the map worked there - but as I said, I haven't played with this for MXE. My guess would be that it's not the DLLs but the qml modules that are missing.

Post by Stefan Fuchs
qrc:/qml/MapWidget.qml:4:1: plugin cannot be loaded for module "QtPositioning": Die Bibliothek C:\Program Files (x86)\Subsurface\qml\QtPositioning\declarative_positioning.dll kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden.
QUrl("qrc:/qml/MapWidget.qml") failed to load with status: QQuickWidget::Status(Error)

I take it back, it clearly is looking for a DLL. And when you look at the installed version, the library is right where Subsurface is looking for it? Or is it missing from the installer?

The new 5.11.1 library file was there in the right position. No clue why Qt complained.

I ran into this on Mac - the error message makes no sense, but it was fixed by making sure QtPositioningQuick was included in the bundle. Maybe it's something similar on MXE?
Look at this commit: https://github.com/Subsurface-divelog/subsurface/commit/4595ccb9f993160eee25f242feb092566dfe3061 <https://github.com/Subsurface-divelog/subsurface/commit/4595ccb9f993160eee25f242feb092566dfe3061>

And the same thing is preventing the Qt 5.11 based Android app from working. There is some other component or library that we need to select in cmake - but I can't figure out what the right keyword might be.
On Android it's lib declarative_positioning.so that isn't packaged and that one isn't packaged because its dependency libQt5PositioningQuick.so is missing.

That sound awfully familiar, doesn't it?

/D

[Thiago Macieira]

Post by Dirk Hohndel
And the same thing is preventing the Qt 5.11 based Android app from working.
There is some other component or library that we need to select in cmake -
but I can't figure out what the right keyword might be. On Android it's lib
declarative_positioning.so that isn't packaged and that one isn't packaged
because its dependency libQt5PositioningQuick.so is missing.
That sound awfully familiar, doesn't it?

Yeah.

My guess is that the deploy applications actually all share the same history
and have the same bug. They work like this (my theory):
1) check which libraries the application links to
2) adds regular (non-QML) plugins associated with that library
3) check what QML imports (including plugins) are needed

But they don't recheck after #3 if any plugins require libraries the
application doesn't link to. This could be worked around by explicitly linking
to the new library -- except that library has no public symbols to require, so
many linkers will just drop it as unnecessary.

[Dirk Hohndel]

Post by Thiago Macieira

Post by Dirk Hohndel
And the same thing is preventing the Qt 5.11 based Android app from working.
There is some other component or library that we need to select in cmake -
but I can't figure out what the right keyword might be. On Android it's lib
declarative_positioning.so that isn't packaged and that one isn't packaged
because its dependency libQt5PositioningQuick.so is missing.
That sound awfully familiar, doesn't it?

Yeah.
My guess is that the deploy applications actually all share the same history
1) check which libraries the application links to
2) adds regular (non-QML) plugins associated with that library
3) check what QML imports (including plugins) are needed
But they don't recheck after #3 if any plugins require libraries the
application doesn't link to. This could be worked around by explicitly linking
to the new library -- except that library has no public symbols to require, so
many linkers will just drop it as unnecessary.

So the problem becomes... how do we work around that. Just force the library
to be part of the package... is that the way to go? It's what I did for macOS and
I think I know how to do that win Windows (but haven't tried, yet). With Android
I still haven't figured out how to do that... :-(

/D

[Thiago Macieira]

Post by Dirk Hohndel

Post by Thiago Macieira
But they don't recheck after #3 if any plugins require libraries the
application doesn't link to. This could be worked around by explicitly
linking to the new library -- except that library has no public symbols
to require, so many linkers will just drop it as unnecessary.

So the problem becomes... how do we work around that. Just force the library
to be part of the package... is that the way to go? It's what I did for
macOS and I think I know how to do that win Windows (but haven't tried,
yet). With Android I still haven't figured out how to do that...

That sounds like a decent workaround, until the deploy tools get fixed.

I haven't looked at he macdeployqt tool in a few years, but it shouldn't be
too difficult to fix it. Assuming the other two have copy/pasted code, the fix
should be ported easily too.

[Thiago Macieira]

Post by Thiago Macieira
I haven't looked at he macdeployqt tool in a few years, but it shouldn't be
too difficult to fix it. Assuming the other two have copy/pasted code, the
fix should be ported easily too.

Quick inspection of the source code shows that it *meant* to deploy the
plugins' dependencies. I'm going to try and create a simple testcase to see
what happens.