Also use $QT_ROOT_DIR

[probonopd]

Also use the environment variable $QT_ROOT_DIR

#300 (comment)

[github-actions]

Build for testing:
artifacts
Use at your own risk.

[probonopd]

@AlbrechtL does this improve the #300 situation for you when you, in other words, does it work without explicitly setting $QTDIR with this build? Thanks.

[AlbrechtL]

Yes, it is working! See https://github.com/AlbrechtL/welle.io/actions/runs/10688777042

Corresponding commit: AlbrechtL/welle.io@bb40872

[github-actions]

Build for testing:
artifacts
Use at your own risk.

[AlbrechtL]

I my case the new version 843 works like the previous 841 one.
10_Create AppImage.txt

[probonopd]

Let's see whether @kevle can confirm that this improves the issue he experienced, too - then I think it's ready for being merged.
Thanks a lot!

[kevle]

I just tested the build artifacts and it seems to abort correctly now:

2024/09/10 10:02:34 libPath: /toolchain/exports/x64-linux/installed/x64-linux-dynamic/lib/libQt6Core.so.6
ERROR Could not find offset for qt_prfxpath=: no qt_prfxpath= token in binary

In my own build I tried just skipping patching libQt6Core, and Qt manages to load the platform plugins just fine:

diff --git a/src/appimagetool/appdirtool.go b/src/appimagetool/appdirtool.go
index 842704d..2d35306 100644
--- a/src/appimagetool/appdirtool.go
+++ b/src/appimagetool/appdirtool.go
@@ -511,7 +511,12 @@ func patchQtPrfxpath(appdir helpers.AppDir, lib string, libraryLocationsInAppDir
        f.Seek(0, 0)
        // Search from the beginning of the file
        search := []byte("qt_prfxpath=")
-       offset := ScanFile(f, search) + int64(len(search))
+       prfxpathPos := ScanFile(f, search)
+       if prfxpathPos < 0 {
+               helpers.PrintError("Could not find offset for " + string(search), errors.New("no " + string(search) + " token in binary"))
+               return
+       }
+       offset := prfxpathPos + int64(len(search))
        log.Println("Offset of qt_prfxpath:", offset)
        /*
                What does qt_prfxpath=. actually mean on a Linux system? Where is "."?

In my environment, Qt is being built by vcpkg. Judging from what I understand from the design of go-appimage, it probably is out of scope to support libraries being built this way, since it expects to use system libraries.

If this is true, then aborting is probably the right thing to do to avoid scope creep.
If not, then checking for qt_prfxpath and only patching it when it was found is probably the way to go.

EDIT:

I just dug a little deeper into this, and it appears that since Qt 5.14, Qt can be build as "relocatable". Those builds do not need to be patched.

The windeployqt tool conveniently shares the build configuration of the Qt library files, so it has hardcoded knowledge about whether to patch the shared library files.

[probonopd]

@kevle could you send a pull request that only does the patching if qt_prfxpath exists and is set? Would highly appreciate it. Thank you very much for your investigation!

[kevle]

@probonopd I'll give it a go!

[probonopd]

Thanks @kevle. There is now a build for testing in #306, and it would be great if someone could give it a through test. Thank you!

[probonopd]

I lost track of this a bit, do you think it should still be merged or should we wait on #306 to be ready for primetime?

Thanks.

[kevle]

I think this should be merged.
#306 can still be applied on top when we manage to work out a more reliable detection mechanism.

[probonopd]

Thanks @kevle