| DataDrake |
| Triage Team |
The issues with games ported from Aspyr Media not starting was caused by a the flag -free-vectorize, this commit fixes that.
Fixes T7458
Changelog:
Changes between 1.18.2 and 1.19.1 can be found here.
Packaging Changes:
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
There are still GitHub tarballs but for some reason Borderlands 2 doesn't start when using them :I
I can step up with maintaining this, I just need to subscribe to the GitHub releases but use their own tarballs. I know it is kind of a bummer for Cuppa support, but it is better than having a lot of games not starting 🙁
Could you try using the git tag against GitHub instead of switching to another source? Sometimes actually, GitHub-generated tarballs are not fine, but git tags are okay.
| package.yml | ||
|---|---|---|
| 22–23 | Are you sure these flags are still needed? | |
| package.yml | ||
|---|---|---|
| 22–23 | From what I can tell it looks like that they are still needed. | |
@Jacalz what steps are you taking to make this patch work? I've been testing but this doesn't appear to fix the issue on my system
Steps taken:
This affects all games that were ported by Aspyr. Tried Civ V, Civ VI, Borderlands2, and KOTOR II. All fail to start.
Currently the only solution I have found is preloading the 32-bit library from release 6.
That is strange @BennZoid, could you try to build with https://kcat.strangesoft.net/openal-releases/openal-soft-1.19.1.tar.bz2?
Might be some issue with stuff sticking around after updating, if that works for you I will use that just like this was from the beginning 🙂
Thanks for looking into this so quick! Sadly using the tarball results in the exact same issue.
Just one more thing for you to try, bump the release version one number to. I think I got a better result when installing an update with bigger release number...
Just found something that makes things weirder. I tried to compile release 6 on my computer and it is also segfaulting 😕
I'll try iterating the release number and see if that helps. Otherwise I'm updating my old laptop to see if I can reproduce on a different system.
I was running in to issues when using GitHub tarballs but switching to those from https://kcat.strangesoft.net/openal-releases/ did seem to fix it for me and bumping the release number to one higher seemed to help when installing that newly built version...
Same issue happened on my laptop as my desktop. Doesn't seem to matter which source is used. Iterating release numbers didn't help either.
I have made some progress though. Narrowed down the issue to being one of the build flags used by the macros. By adding an environment key and unsetting all flags it successfully builds and runs the games. This is probably a sub optimal solution but when it comes to flags its all over my head. Any ideas which particular flag could cause this? There was a similar problem in arch that was fixed using -mstackrealign, but that doesn't seem to help in this case (or I'm using it wrong!)
For reference the following is what I added before the builddeps key
environment:
unset CFLAGS;
unset CXXFLAGS;
unset LDFLAGS;@Jacalz I've got this all figured out! My issues were caused by -ftree-vectorize
We can remove that flag by adding the following key to the package.yml
environment:
export CFLAGS="${CFLAGS/-ftree-vectorize/}"This works with all sources, including the github tarball. Could you test and confirm that this change still works for you?
| package.yml | ||
|---|---|---|
| 22–23 | -DCMAKE_INSTALL_PREFIX=/usr is not required anymore, it is set by the ninja macro. | |
It sounds like wonderful news @BennZoid and you did a really good job working it out 👍 I don’t know why my system got fixed during my testing, but I will see about implementing your change tomorrow 🙂
| package.yml | ||
|---|---|---|
| 22–23 | Okay, will get this sorted tomorrow 🙂 | |
I have an idea why your system might be fixed. Check if /usr/lib/libopenal.so.1.19.1 exists. Without the libdir flag for cmake ninja it installs the 32bit library into /usr/lib rather then /usr/lib32. So if you locally built and installed a working version from git then you could still have it installed. I briefly did that and it made debugging very confusing.
Good eye @livingsilver94. I just ran a quick test, looks like we can change the flags in the setup step, before the cmake_ninja macro.
This has sat accepted for a long time now, could we please get this merged so users can start playing some of their games again? 🙂
Are you able to retest without dropping -ftree-vectorize? GCC is much less broken now.
Just did a quick retest with Borderlands 2 and Civ V, we still need to drop the flag otherwise they can't start.