libAzQtComponents.so symbol lookup error

[Malthbern]

fails to open with:
o3de: symbol lookup error: /opt/O3DE/22.10.0/bin/Linux/profile/Default/libAzQtComponents.so: undefined symbol: _ZN16QStyleSheetStyle16staticMetaObjectE, version Qt_5_PRIVATE_API

Operating System: Manjaro Linux
KDE Plasma Version: 5.26.4
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Kernel Version: 6.0.15-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2

ldd_libAzQtComponents.so.txt

[xaque]

It looks like the QT system libraries are getting loaded over the O3DE provided ones--I am not entirely sure why but it seems to only be cropping up on Manjaro. In other words, the ldd command should show:

        libQt5Concurrent.so.5 => /opt/O3DE/22.10.0/bin/Linux/profile/Default/libQt5Concurrent.so.5 (0x00007fc635599000)
        libpython3.10.so.1.0 => /opt/O3DE/22.10.0/bin/Linux/profile/Default/libpython3.10.so.1.0 (0x00007fd221200000)
        libxcb-xkb.so.1 => /usr/lib/libxcb-xkb.so.1 (0x00007fd22583a000)
        ...
        libQt5Svg.so.5 => /opt/O3DE/22.10.0/bin/Linux/profile/Default/libQt5Svg.so.5 (0x00007fc630d85000)
        libQt5Widgets.so.5 => /opt/O3DE/22.10.0/bin/Linux/profile/Default/libQt5Widgets.so.5 (0x00007fc62ea00000)
        libQt5Xml.so.5 => /opt/O3DE/22.10.0/bin/Linux/profile/Default/libQt5Xml.so.5 (0x00007fc630d3e000)
        libQt5Gui.so.5 => /opt/O3DE/22.10.0/bin/Linux/profile/Default/libQt5Gui.so.5 (0x00007fc62e200000)
        libQt5Core.so.5 => /opt/O3DE/22.10.0/bin/Linux/profile/Default/libQt5Core.so.5 (0x00007fc62da00000)

You might be able to force the provided libs to load first with:
LD_LIBRARY_PATH="/opt/O3DE/22.10.0/bin/Linux/profile/Default" o3de
or if not, you might need to LD_PRELOAD each of the QT libs in that directory.

[xaque]

I found this post from QT which might explain the confusion around it and why behavior is different between distros
https://www.qt.io/blog/2011/10/28/rpath-and-runpath

If this is the case, then this is something that might need to be fixed upstream

And based on the apparent load order, LD_LIBRARY_PATH might not be high priority enough to work before the system libs are loaded...

[Malthbern]

LD_LIBRARY_PATH didn't seem to resolve this and unless i'm doing this wrong neither did LD_PRELOAD

LD_preload-o3de bashscript.txt to check my work

ldd_LD_PRELOAD_libAzQtComponents.so.txt the output of the above

[xaque]

LD_PRELOAD might need to be on the same line as the final command. If that doesn't work though, I don't think this is something that can be fixed in the AUR package

[Malthbern]

yah, defiantly needs a fix from upstream. I've tried a few different iterations of the same thing and none of it works

[xaque]

One other thing i might ask of you just to verify whats happening, if you run
readelf -d /opt/O3DE/22.10.0/bin/Linux/profile/Default/o3de
What is the result for RUNPATH or RPATH? For example, mine on Arch (which works as expected):

...
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
0x000000000000000c (INIT)               0x394000
...

[Malthbern]

...
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
 0x000000000000000c (INIT)               0x394000
...

[Malthbern]

submitted issue to O3DE here for future reference: o3de/o3de#14171

[ShaunaGordon]

Hey! I'm a Manjaro user and community contributor to O3DE. Unsurprisingly, I ran into this error when trying to install from the package in the AUR. Since I'd much rather work on Manjaro than either Ubuntu or Windows, I decided to dig into the issue and see if I could figure out the source of the issue.

After reading through the trail left here and in the O3DE Discord, and looking through the O3DE code and finding nothing non-standard about the scripts I have access to, I hopped over to the Manjaro forums to ask about the runpath thing you found. Here's what I found out:

• There's no known quirk with Manjaro regarding runpath that might be doing this
• Downloading the source from Github and following the documentation for it results in a working setup
• Manually downloading the .deb file, extracting it, and running the get_python script results in a working setup

Given these three things, that means the issue most likely does, in fact, lie somewhere within the AUR package script, since if it was an issue with the O3DE build, itself, at the very least, the .deb download test wouldn't work, and likely neither would the source build. So, I started digging through the scripts and checking with my install logs, and comparing it with the .deb scripts.

In doing so, I noticed that in the o3de.install file, you have this bit:

    if [ ! "$(logname 2>&1 >/dev/null)" ]; then
        _user=$(logname)
        _group=$(id -g -n ${_user})
    else
        _user=root
        _group=root
    fi

In my log, I'm getting warnings from pip not to run as root, which means this is resolving to root:root, which is confirmed by a quick ls -la on /opt/O3DE. So, I manually chowned the folder, then ran the get_python.sh script, and once it successfully installed everything, ran o3de to see what would happen. Lo and behold, it started up without issue!

I'm no package maintainer, so I don't really know what the proper fix for this ought to be, but this does seem to be the root cause.

[xaque]

Thanks for digging into all this! I was never able to exactly reproduce the issue but it seems then that the runpath stuff was all a red herring after all. I can see where there could be some holes in the current approach with logname, but could you shed any light on how that is messing up? I am guessing it is returning "root" instead of the sudo-ing user. Are you installing with makepkg or some other AUR helper? That might shed some light on when/for whom this is happening.

Without being able to trust we can get a non-root user name to chown with, my idea for a more robust solution is to create a system user account take over the directory. I think I have seen this before in an AUR package, but not sure if its the most ideal. If we were to do that as a last resort we might do something like:

o3de_python_install() {
    # Try to get local user
    if [ ! "$(logname 2>&1 >/dev/null)" ]; then
        _user=$(logname)
        _group=$(id -g -n ${_user})
    fi
    # Only create o3de system user if necessary
    if [ -z $_user ] || [ $_user = "root" ]; then
        if ! id -u o3de &>/dev/null; then
            useradd -rU o3de
        fi
        _user=o3de
        _group=o3de
    fi

    # Change ownership to user
    chown -R ${_user}:${_group} /opt/O3DE/${_engver}

    # Run O3DE provided python install script as user
    runuser -l ${_user} -c "/opt/O3DE/${_engver}/python/get_python.sh"
}

[ShaunaGordon]

Are you installing with makepkg or some other AUR helper?

It's just stock Pamac (version 11.7.1-1, in case it matters). I started with Gnome Minimal image from the site, then attempted to install O3DE using the Pamac GUI.

Looking at my /opt folder, I do have one other application that does make its folder owned by the user, so it's evidently possible, though I don't know how, since there doesn't seem to be a PKGBUILD file or any other config that tells it to change the ownership. My only guess is that it downloads as the user and when it copies the opt folder over, it retains the permissions somehow, but it's pure speculation.

[ShaunaGordon]

Another update on this -- something I noticed early on is that vanilla Arch users mentioned it worked fine. Likewise, installing from basically any method other than Pamac worked. This caught aarhus's attention. Indeed, by doing it "the Arch way" described in his response, it works as expected, meaning it's in the way Pamac handles the script user stuff.

[xaque]

So after looking more into the system user option, I have scrapped that as it could just introduce more permission issues when the python script or potentially other parts of the engine generate new files. For example, hitting permission issues when trying to create a new o3de project.

I spent some time then messing with pamac to see if there's another way to determine the correct user to chown and runas and was able to get it working in the latest update. It might not account for all possible installation methods but is certainly a step more robust than before.