Bug 446490

Summary:	Crashes on launch when built from source
Product:	[Applications] Haruna	Reporter:	Nate Graham <nate>
Component:	generic	Assignee:	george fb <georgefb899>
Status:	RESOLVED WORKSFORME
Severity:	crash
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Nate Graham 2021-12-04 19:28:28 UTC

I have tried to build Haruna from source multiple times over the last few months, and running the built executable always fails with the following:

$ haruna
QML debugging is enabled. Only use this in a safe environment.
unknown() : QQmlApplicationEngine failed to load component

unknown() : qrc:/qml/main.qml:15:1: plugin cannot be loaded for module "org.kde.kirigami": Cannot load library /home/nate/kde/usr/lib64/qml/org/kde/kirigami.2/libkirigamiplugin.so: (/home/nate/kde/usr/lib64/qml/org/kde/kirigami.2/libkirigamiplugin.so: undefined symbol: _ZN8Kirigami5Units19longDurationChangedEv)

I am building it using a totally standard kdesrc-build procedure (`kdesrc-build haruna`), and none of my other Kirigami-based apps that I build from source have this problem. I have done a clean build of both Haruna and also Kirigami. Could there be configuration issue in Haruna's CMake somehow?

Comment 1 george fb 2021-12-05 08:08:38 UTC

Running `kdesrc-run haruna` works for me (KDE Neon Developer Edition).

Don't know what's going on. I get that error when I'm trying to use a new feature from a lib and the version I have installed is older. I'm not even using `longDuration` in my code.

What does `readelf -Ws --dyn-syms /home/nate/kde/usr/lib64/qml/org/kde/kirigami.2/libkirigamiplugin.so | grep longDuration` return?

>  Could there be configuration issue in Haruna's CMake somehow?
No, at least not intended.

Comment 2 Nate Graham 2021-12-05 13:26:55 UTC

> $ readelf -Ws --dyn-syms /home/nate/kde/usr/lib64/qml/org/kde/kirigami.2/libkirigamiplugin.so | grep -i longduration
> 88:    84: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZN8Kirigami5Units19longDurationChangedEv
> 126:   122: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNK8Kirigami5Units12longDurationEv
> 2897:  2132: 000000000001f1a0    19 FUNC    LOCAL  DEFAULT   11 _ZN17QmlComponentsPool19longDurationChangedEv
> 3331:  2566: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZN8Kirigami5Units19longDurationChangedEv
> 3369:  2604: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND _ZNK8Kirigami5Units12longDurationEv

Comment 3 george fb 2021-12-06 10:54:10 UTC

I have no idea what's causing this.

Try building older versions with kdesrc-build, try building with your system's libraries or try with a fresh kdesrc-build.
To build older version add
```
module haruna
  repository https://invent.kde.org/multimedia/haruna
  tag 0.2.0
end module
```
to kdesrc-build's config file.

Comment 4 Nate Graham 2021-12-06 17:30:30 UTC

Yes, I am doing clean builds for all of these builds to rule out issues with incremental builds.

If I build an older version, then I get a different symbol error in Kirigami:

$  ((HEAD detached at 0.2.0)) haruna
QML debugging is enabled. Only use this in a safe environment.
haruna: symbol lookup error: /home/nate/kde/usr/lib64/plugins/kf5/kirigami/org.kde.desktop.so: undefined symbol: _ZN11KIconColorsC1Ev

If I unset `QML2_IMPORT_PATH` to force Haruna use Kirigami from the system installation, it launches just fine. However opening a file makes it crash with another missing symbol error:

haruna: symbol lookup error: /home/nate/kde/usr/lib64/libKF5KIOCore.so.5: undefined symbol: _ZN15KPluginMetaData11findPluginsERK7QStringSt8functionIFbRKS_EE

It seems like all my built-from-source libraries are making Haruna very sad. Again I don't have this issue with any other KDE software that I build from source.

Comment 5 george fb 2021-12-07 00:02:21 UTC

(In reply to Nate Graham from comment #4)
> Yes, I am doing clean builds for all of these builds to rule out issues with
> incremental builds.
Does clean build mean starting from scratch with kdesrc-build or clean builds only for haruna and kirigami? 

If the first, please provide the steps you're doing, like the exact commands you run, from cloning kdesrc-build to running haruna, and wheter you change any config of kdesrc-build.
If the second, try starting from scratch with kdesrc-build.
Also please post your system info.

Comment 6 Nate Graham 2021-12-13 22:21:01 UTC

I upgraded to Fedora 35 over the weekend and can no longer reproduce this issue. :/

Build gnomes...