question, why they switch away from github? I'm thinking about cuppa support

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.

@livingsilver94 You were right, taking the git tag using git actually made it work ?

@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:

• switch to unstable repo
• eopkg update then restart
• git clone openal-soft (v1.18.2/release 7)
• patch package.yml with your changes (to 1.19.1/ninja)
• solbuild the new packages
• install openal-soft 1.19.1 (32 and 64 packages, not devel)
• restart computer again for good measure
• try to start Borderlands 2
• still getting segmentation fault

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?

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 ?

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.

You were right @BennZoid, that seemed to be the case ?

FWIW, the export command for build flags should be needed only in the build block.

Mark inline comments as done

I tested that @livingsilver94 and it doesn't work...

Hah, that's something I wouldn't ever have bet on. Thanks for the test!

No worries ? @livingsilver94

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.