Is something different about Manjaro's runpath handling?

Support AUR
,
1

I’m a contributor to O3DE, and I noticed when trying to return to Manjaro as my daily driver, that the AUR binary installation is unable to install due to an undefined symbol error thrown by Qt. Upon looking it up in the AUR site, I found that this is a known issue that they’ve traced to needing a fix in O3DE itself.

Unfortunately, Manjaro isn’t officially supported by the core O3DE team due to resource constraints, and therefore they declined to troubleshoot and fix this issue. However, I greatly prefer Manjaro over Ubuntu, so I’ve been working on tracking down the root cause to see about fixing it.

Based on the existing discussions, it seems to be a difference with how Manjaro handles the RPATH vs RUNPATH compiler/linker flags, but I don’t know enough about Manjaro’s internals to even begin to determine what that might be, exactly. Judging from discussions in the O3DE Discord, as well as the AUR entry for it, it installs and runs without issue on plain Arch, but some downstream distributions (Manjaro being the most common, but Garuda was also mentioned) run into this RPATH/RUNPATH issue.

What’s different between Manjaro and Arch in this regard?

2

A few things I saw, re the comments on the AUR page for this software.
(three comments by “ibanrothschild”)

  • the package is not compiled - it uses the latest available .deb version, extracts it and that is pretty much it
    therefore: autoconf (which he asks for to include as a dependency) is not needed
    Also: autoconf is - as other software as well - considered to be a prerequisite and available for literally anything AUR
    The package group base-devel contains it.

  • it seems to rely on python 3.10 - that is not the python version in Arch or Manjaro (seems to be 3.11 at the moment)

  • maybe just add /opt (where the package is installed to) to the PATH, instead of just linking /usr/bin/ode3 to where it actually is
    (speculation on my part here - prepend instead of append, if that would make a difference)

AUR is not officially suported as you (now) know - why not use Arch - to confirm that there really is that much of a difference between it and Manjaro?
EOS is quickly installed - and then you know …

I think that someone mentioning this RPATH vs RUNPATH difference … has sent you on a wild goose chase.
It may just be an issue with how the PKGBUILD handles the installation of the binary .deb …

1 Like
3

I don’t think there is any difference.

As a courtesy - I will test the build - and subsequently try to launch the app … let’s see the deb file is 5056M in download size.

EDIT:
@dragonwolf
The package is downloaded an installed without issues but it cannot be run.

The following warnings are produced and may explain - at least partly - why it won’t work.

WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
/opt/O3DE/23.10.2
/opt/O3DE/23.10.2/python /opt/O3DE/23.10.2
Obtaining file:///opt/O3DE/23.10.2/scripts/o3de
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Installing collected packages: o3de
  Running setup.py develop for o3de
Successfully installed o3de-1.0.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
/opt/O3DE/23.10.2
tput: No value for $TERM and no -T specified
NOTE: You may need to increase the maximum file descriptor limit according to the needs of your O3DE Project
See https://wiki.archlinux.org/title/Limits.conf#nofile
tput: No value for $TERM and no -T specified
Error: o3de-bin: command failed to execute correctly
Running post-transaction hooks...
Arming ConditionNeedsUpdate...                                                                           [1/4]
Refreshing PackageKit...                                                                                 [2/4]
Updating icon theme caches...                                                                            [3/4]
Updating the desktop file MIME type cache...                                                             [4/4]
Transaction successfully finished.

The problem has nothing to do with Manjaro Linux or Arch Linux as the application will fail if your system python is not 3.10 which will fail equally on Arch Linux.

 $ o3de 
o3de: error while loading shared libraries: libpython3.10.so.1.0: cannot open shared object file: No such file or directory

The package is specifically linking libpython3.10.so which is not available on systems with Python 3.11.

The library also exist in the programs folder structure - so it must be something in their binaries which is not working as expected - possibly why the abandoned supporting Manjaro.

For as far as my knowledge go - in this regard there is no difference. Although I have seen @philm commenting another place stating that Manjaro has a different glibc - I don’t know what that is about? And my knowledge is zero in that regard.

When the upstream developers decides to move to Python 3.11 - then likely it will work - at least for as long as Manjaro is on 3.11 - if that happens when Python 3.12 comes then it will still fail as Arch and Manjaro could have moved on to 3.12 and o3de will still not work.

If the packaged application included libpython3.10.10.1.0 in it’s on lib path it is possible the app could work on Manjaro - that is the resonsibility of the packager.

1 Like
4

Good on you! - That is why I didn’t try. :grinning:

5

The Python error is easily enough fixed right now by simply installing 3.10. Yes, I know that needs handled better, but I’m not at that point yet, rather, I’m still in the phase of gathering what all needs to be done to get it working. I do apologize for not making that explicit in my initial post.

If you install Python 3.10, it handles the Python installation part just fine, and that’s when the Qt error pops up, that previous discussion has concluded is the runpath issue.

I am that upstream developer…and it doesn’t work. That’s why I’m asking here. If it was as simple as a Python version issue, I’d be talking to the rest of the O3DE team about upgrading the Python dependency. (I wish it were that simple, and maybe the fix still is, but it’s at least proving to be a little harder to track down.)

I don’t know that I’d call it a wild goose chase, at least not for myself, when I’m currently just investigating and verifying the conclusion my predecessors came to after running into the same error, and compiling a list of what needs fixed in order to make it work. That said, it might very well be one on the packager’s part, as it looks like the Qt error could indeed be a red herring.

I mean…I already knew that, but neither Qt nor whatever part handles runpath are AUR. I’m doing the upstream support for the AUR package, I’m asking for help about an error that seems to be originating from an official package, and attempting to verify the conclusion of those downstream of me.

As I’m not a package maintainer at the OS level, I came here hoping to be able to defer to those who are, for some high-level information on whether there is or isn’t some quirk we’re running into, so that I can more specifically pinpoint what’s actually wrong and what I need to fix, which the responses here have helped with already, so thank you for those.

Because a user of vanilla Arch within the O3DE developer community had already confirmed that it worked for them, and all of the existing reports of it not working are coming from Manjaro users. I know the Manjaro team makes it clear that it’s not identical to Arch, so it made sense to me to start here, and see if this might be a point where it differs for some reason that I’m unaware of. Since the matter doesn’t seem to be that straightforward, trying EOS and double checking will be among my next steps.

As I mentioned, I’m an upstream application dev, not a package maintainer, so I’m not familiar with the best practices on that front. Is the approach the package maintainers used the usual way of handling applications that don’t officially support a given distro? I would assume compiling a package targeted to Arch is the most ideal way, but is there a middle ground at all that might be preferred to the method they chose? Downloading the source and compiling it on the user’s machine isn’t really desired in this case, I don’t think, because the raw source is significantly larger still, due to the nature of the application, but perhaps a different approach might work for them.

6

It’s just the way that particular person chose to make the precompiled .deb “compatible” to be installed on Arch via AUR.

They could have chosen to compile from source as well, I guess.

That just often involves a lot of time and space and build dependencies and using precompiled binaries is quicker and equally as effective.
IMO

it was probably not the best or most appropriate use of that phrase
“down the garden path” or simply “the wrong direction” would probably have been more fitting
I’m not a native speaker.

1 Like
7

One prerequsite for using AUR build scripts is using unstable branch - but as I am using unstable branch and I cannot run the application.

While I had it installed to see if I could figure out why - I had a look at the scripts - and I couldn’t make head or tail from it.

VMware uses libpython3.10.so.1.0 as well and it has no issues finding the library.

If it works with an Arch Linux base desktop - for all intent and purpose - it should work with Manjaro as well.

Yes Manjaro build kernels - the exact patches can be found at [gitlab/packages/core] and I recently learned that Manjaro builds glibc to maintain gaming compatibility with Steam.

What I could figure out is that you store your python initializing in /opt/O3DE/$ENGINE/python where some scripts seem to populate the runtime/python-$VERSION

I cannot say I am familiar with RPATH/RUNPATH but an educated guess is an assumption on where certain libraries lives relative to the location of the binary.

My otherwise logically arranged brain does understand why RUNPATH should be handled differently?

It makes no sense - if that were to be true - it would break more than O3DE - perhaps @philm or @RomanPerekhrest has some insight? Please don’t expect a quick response from them - unless they specifically take interest - just like I do - I am just not that capable :grin:

1 Like
8

To make it clear: considering that installing the proper python version doesn’t get in the way (as you mentioned), does setting LD_LIBRARY_PATH before running the app (in the same console session) make any effect?

9

Hello @dragonwolf :wink:

I tried it myself and I see no issue.

I just downloaded the deb, extract it, run the script get_python.sh and it runs with ./bin/Linux/profile/Default/o3de.

I could reproduce it by adding running it like that:

LD_LIBRARY_PATH=/usr/lib ./bin/Linux/profile/Default/o3de

That way it will prefer system libraries (/usr/lib) over local libraries ($ORIGIN).

./bin/Linux/profile/Default/o3de: symbol lookup error: /home/user/storage/projects/o3de/opt/O3DE/23.10.2/bin/Linux/profile/Default/libAzQtComponents.so: undefined symbol: _ZN16QStyleSheetStyle16staticMetaObjectE, version Qt_5_PRIVATE_API

The symbol _ZN16QStyleSheetStyle16staticMetaObjectE is available in the delivered library, but not in the system library.

$ strings bin/Linux/profile/Default/libQt5Widgets.so.5 | grep "_ZN16QStyleSheetStyle16staticMetaObjectE"
_ZN16QStyleSheetStyle16staticMetaObjectE
_ZN16QStyleSheetStyle16staticMetaObjectE
_ZN16QStyleSheetStyle16staticMetaObjectE

Probably a difference between how it is compiled? Arch Linux / Packaging / Packages / qt5-base · GitLab

The difference is simple in my eyes: o3de delivers QT 5.15.1, but ArchLinux/Manjaro QT 5.15.13. Don’t ask me why, but this symbol must have been removed or probably replaced. Or is it the difference between commercial and opensource? Sorry, I am not a developer. :man_shrugging:

1 Like
10

I found when I compiled the development branch, it ran fine, too (I hadn’t gotten around to other testing quite yet). Combined with this, it does seem like it might indeed be something the package maintainer is doing differently.

No worries. :blush:

The heart of what you meant does seem to be proving true (or at least has an increasingly strong case supporting it). Given what all has been said here, I’m equally inclined to believe the rpath thing is a red herring.

As I understand it, rpath is the deprecated reference to non-default libraries, but it’s been deprecated for something like a decade or more. My initial hypothesis that prompted my question was that (assuming it wasn’t a red herring) perhaps someone is still allowing for rpath fall back, someone is strictly on runpath, and something with the package is set up such that it works fine for one configuration and not the other. Which one was doing what was the unknown to me, though.

I don’t know if they tried it in the same console session, but previous reports did find that setting LD_LIBRARY_PATH didn’t seem to have an effect. That permutation can go on the list of things to verify.

lol, I’m by no means a Qt or package expert, either, so hell if I know. :sweat_smile: It’s a possibility, but I couldn’t immediately find what might even be indirectly referencing it in O3DE’s code, so I hadn’t gone down that rabbit hole yet (I’m not much of a Qt dev, either, so I’d have had the newbie overhead to contend with, too).

This has all been great help! :heart: I think I’ve got a bunch of stuff to take back to the package maintainers now to start digging a bit deeper into this and hopefully get it fixed. I’ll toss it to them and see where it goes from there.

Thanks all for the help! :pray:

1 Like
11

OMG, I figured out the issue…

It seems in the post-install, when the package script tries to run the get_python script, it’s doing so with elevated privileges, which upsets pip and doesn’t seem to do the rest of the linking (or it tries and doesn’t stick, I’m not sure which). That, in turn, means it’s not referencing the correct library files and therefore unable to run.

12

I noted that when I installed the package and reached a similar conclusion,

I was/am speculating how one could modify the PKGBUILD - I am thinking the .install should be inside package() in PKGBUILD but that may create other issues.

One may speculate - why does it work on an Arch Linux?

Perhaps this is causing it because it is run in root context during install?

    if [ ! "$(logname 2>&1 >/dev/null)" ]; then
        _user=$(logname)
        _group=$(id -g -n ${_user})
    else
        _user=root
        _group=root
    fi
    # Change ownership to user
    # Not entirely sure if this is still required
    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"
13

Good question.

I was looking at another package today that results in a user-owned folder inside opt, so it’s clearly possible, though none of the files I have access to indicate any way of explicitly making it so. Both that package and my O3DE install were done through Pamac.

Is there a standard way to tell Pamac to make the folder in opt user-owned?

14

This can be done in the PKGBUILD - pamac uses pacman libalpm for all transactions - so PKGBUILD rules.

1 Like
15

It is, apparently, but that root context isn’t coming from anything special. It happens with a standard install via Pamac.

So…since it clearly can work, do you have an example of a PKGBUILD config/snippet where it does work?

16

just an interjection - ignore if this is too trivial or too dumb a question

Why would there need to be a user owned folder in /opt - or anywhere system wide?

1 Like
17

Because when the folder’s owned by root, the get_python script then has to run with elevated privileges, which then requires pip to run with elevated privileges, which it doesn’t like and the script ends up dying or not running like it’s supposed to, as I described previously. It works just fine if I manually chown the folder then run the script.

Technically, it doesn’t have to be owned by the user, nor does it actually need to be in /opt, strictly speaking, if it can be installed somewhere else. That script just can’t run as root or it doesn’t work. So if there’s a more appropriate location or way to have this install, I (and probably the package maintainer) am open to recommendations.

18

I have been giving a lot of thought to the process - and you have now mentioned twice - Pamac.

The PKGBUILD is a recipe and the final package is defined by the content.

The content is designed to be handled by Arch Linux package manager - pacman.

Pacman in turn provides libalpm which does the heavy lifting using an API which allows other frontends to be created - with Manjaro such frontend is Pamac

I am beginning to suspect this is an issue generated by the way Pamac handles the interaction with the content.

When the .install script is run - using pamac - there is no change in the user running the script - BUT - when run using pacman - pacman provides a user variable holding the user whom launched the script and therefore the .install part works as expected.

I would try the Arch way - and verify if this is the case

System used

 $ inxi -S
System:
  Host: tiger Kernel: 6.6.27-1-MANJARO arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.0.3 Distro: Manjaro Linux

 $ pacman-mirrors -G
unstable

Process

sudo pacman-mirrors -aS unstable
sudo pacman -Syu base-devel git --needed
git clone https://aur.archlinux.org/libffi7
git clone https.//aur.archlinux.org/o3de-bin
cd libffi7
makepkg -is
cd ../o3de-bin
cd o3de-bin
makepkg -is

[...]

:: Processing package changes...
installing o3de-bin                                          [####################################] 100%
get_python.sh: Python is already downloaded: Python 3.10.5
installing via pip...
/opt/O3DE/23.10.2/python /opt/O3DE/23.10.2/python
Requirement already satisfied: atomicwrites==1.4.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 1)) (1.4.1)
Requirement already satisfied: attrs==20.1.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 4)) (20.1.0)
Requirement already satisfied: boto3==1.20.44 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 8)) (1.20.44)
Requirement already satisfied: botocore==1.23.44 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 12)) (1.23.44)
Requirement already satisfied: certifi==2022.12.7 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 16)) (2022.12.7)
Requirement already satisfied: chardet==3.0.4 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 20)) (3.0.4)
Requirement already satisfied: charset-normalizer==2.0.10 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 24)) (2.0.10)
Requirement already satisfied: colorama==0.4.3 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 29)) (0.4.3)
Requirement already satisfied: docutils==0.15.2 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 33)) (0.15.2)
Requirement already satisfied: easyprocess==0.2.8 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 38)) (0.2.8)
Requirement already satisfied: exceptiongroup==1.0.4 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 42)) (1.0.4)
Requirement already satisfied: gitdb==4.0.10 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 44)) (4.0.10)
Requirement already satisfied: smmap==5.0.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 48)) (5.0.0)
Requirement already satisfied: gitpython==3.1.30 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 52)) (3.1.30)
Requirement already satisfied: idna==2.9 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 56)) (2.9)
Requirement already satisfied: imageio==2.8.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 60)) (2.8.0)
Requirement already satisfied: importlib-metadata==1.6.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 64)) (1.6.1)
Requirement already satisfied: Jinja2==3.1.2 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 68)) (3.1.2)
Requirement already satisfied: jmespath==0.9.5 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 72)) (0.9.5)
Requirement already satisfied: MarkupSafe==2.1.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 76)) (2.1.1)
Requirement already satisfied: more-itertools==8.4.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 118)) (8.4.0)
Requirement already satisfied: numpy==1.23.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 122)) (1.23.0)
Requirement already satisfied: packaging==20.4 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 146)) (20.4)
Requirement already satisfied: pillow==9.3.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 150)) (9.3.0)
Requirement already satisfied: pluggy==0.13.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 213)) (0.13.1)
Requirement already satisfied: progressbar2==3.53.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 217)) (3.53.1)
Requirement already satisfied: psutil==5.9.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 221)) (5.9.0)
Requirement already satisfied: pyparsing==2.4.7 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 255)) (2.4.7)
Requirement already satisfied: pyscreenshot==0.6 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 259)) (0.6)
Requirement already satisfied: pytest-mock==3.8.2 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 263)) (3.8.2)
Requirement already satisfied: pytest-timeout==2.1.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 267)) (2.1.0)
Requirement already satisfied: pytest==7.2.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 271)) (7.2.0)
Requirement already satisfied: python-dateutil==2.8.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 274)) (2.8.1)
Requirement already satisfied: python-utils==2.5.6 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 278)) (2.5.6)
Requirement already satisfied: requests==2.31.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 282)) (2.31.0)
Requirement already satisfied: s3transfer==0.5.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 286)) (0.5.0)
Requirement already satisfied: scipy==1.8.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 290)) (1.8.1)
Requirement already satisfied: six==1.13.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 316)) (1.13.0)
Requirement already satisfied: urllib3==1.26.8 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 320)) (1.26.8)
Requirement already satisfied: wcwidth==0.2.5 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 324)) (0.2.5)
Requirement already satisfied: zipp==3.8.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 328)) (3.8.0)
Requirement already satisfied: tomli==2.0.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 332)) (2.0.1)
Requirement already satisfied: iniconfig==1.1.1 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 335)) (1.1.1)
Requirement already satisfied: toml==0.10.2 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 338)) (0.10.2)
Requirement already satisfied: resolvelib==0.9.0 in ./runtime/python-3.10.5-rev4-linux/python/lib/python3.10/site-packages (from -r /opt/O3DE/23.10.2/python/requirements.txt (line 341)) (0.9.0)
/opt/O3DE/23.10.2/python
/opt/O3DE/23.10.2/python /opt/O3DE/23.10.2/python
Obtaining file:///opt/O3DE/23.10.2/scripts/o3de
  Preparing metadata (setup.py): started
  Preparing metadata (setup.py): finished with status 'done'
Installing collected packages: o3de
  Attempting uninstall: o3de
    Found existing installation: o3de 1.0.0
    Uninstalling o3de-1.0.0:
      Successfully uninstalled o3de-1.0.0
  Running setup.py develop for o3de
Successfully installed o3de-1.0.0
/opt/O3DE/23.10.2/python
NOTE: You may need to increase the maximum file descriptor limit according to the needs of your O3DE Project
See https://wiki.archlinux.org/title/Limits.conf#nofile


Optional dependencies for o3de-bin
    ninja: Support for multiple build configurations per project [installed]
:: Running post-transaction hooks...
(1/4) Arming ConditionNeedsUpdate...
(2/4) Refreshing PackageKit...
(3/4) Updating icon theme caches...
(4/4) Updating the desktop file MIME type cache...

The answer

Why does it work on Arch LInux but not Manjaro Linux?

  • If you use Pamac to build and install it won’t work
  • If you use makepkg and pacman it works as expected
Screenshot

image
image1221×945 67.4 KB

1 Like
19

I’m going to call this solved, since the discussion seems to have found the root problem. Thanks for the help, everyone! :heart:

20

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.