openmw.org

There is also this issue with the Generic Linux build here: https://gitlab.com/OpenMW/openmw/-/issues/6074

Not necessarily the crashing bit, but the lack of missing libjpeg that prevents the osg jpeg plugin from loading. Perhaps this should be included?

Nectarine wrote: ↑04 Jun 2021, 00:40 Forgot to mention earlier: I am running Debian 10.

$ export LD_LIBRARY_PATH="./lib";ldd plugins/platforms/libqxcb.so
...
libxcb-xinput.so.0 => not found
libxcb-xinput.so.0 => not found
...

I'm not too fond of packaging X11 libraries. I think in this case it would be best if you install the libxcb-xinput0 package which provides libxcb-xinput.so.0. Maybe i should add what is expected to be present on the system to the readme.

psi29a wrote: ↑04 Jun 2021, 06:41 There is also this issue with the Generic Linux build here: https://gitlab.com/OpenMW/openmw/-/issues/6074

Not necessarily the crashing bit, but the lack of missing libjpeg that prevents the osg jpeg plugin from loading. Perhaps this should be included?

Yeah that needs to be included. I'll add some other libraries that seem reasonable to include and create a new RC.

For the sake of posterity, installing libxcb-xinput0 via my package manager fixed my problem.

Generic Linux targz package RC2:

64 Bit

The lib directory now also contains libjpeg62, libexpat, libgraphite2, libharfbuzz, libfreetype, libglib, libgthread and libpcre.

Did you ever provide a Flatpak?

Not sure who maintains the flatpak... looks like it might be Ace, our windows guy (among others who contributed here):
https://github.com/flathub/org.openmw.O ... tributors/

K1ll wrote: ↑04 Jun 2021, 14:39 Generic Linux targz package RC2:

64 Bit

The lib directory now also contains libjpeg62, libexpat, libgraphite2, libharfbuzz, libfreetype, libglib, libgthread and libpcre.

Thanks for doing this K1ll, the build runs great on my Void Linux system. Our unreleased builds that are generated by CI, don't though ("wrong" OSG and other issues). Would you mind helping get the CI artifacts to where they can be more portable?

darkbasic wrote: ↑04 Jun 2021, 16:46 Did you ever provide a Flatpak?

I have a working AppImage build, but Gitlab-CI can't allow fuse in their CI dockers so I'm at somewhat of an impasse there.

Built up new Windows dependencies and a new 64-bit RC build;

https://openmw.rgw.ctrl-c.liu.se/Releas ... -win64.exe

Alrighty, we have RCs for all major platforms... let the testing begin!

Linux: https://redfortune.de/openmw/rc/openmw- ... RC2.tar.gz
Windows: https://openmw.rgw.ctrl-c.liu.se/Releas ... -win64.exe
macOS: https://mega.nz/file/LRtXgIxC#w-Aq1u0U5 ... s4GzAPK58M

The macOS build provided by tess, tested on macos 10.14 and 11.15; known issue shadows are broken... if they are not, please post here your system. (or just verify that they are broken for you too)

The OSG builds in https://gitlab.com/OpenMW/openmw-deps/- ... in/windows haven't been updated. Also I just realised that we're totally dependent on not pushing new builds with the same version numbers with how the CI scripts are set up if we want reproducible builds or the ability to build old versions of OpenMW, so as we've not got a new tag or anything, it's probably a good idea to put the short-form commit hash in the zip name.

Another thought: It's probably a good idea to turn on the /Zi flag manually when building the actual release and keep the PDBs around. Now we've got crash dumping as a feature, it would be a pain if the release build gave us crash dumps that were useless. It's been less of an issue with dev builds as anyone downloading those can be fairly easily talked into downloading the RelWithDebInfo version and reproducing the issue, but it won't be the same with the release, and we can't compile the release as RelWithDebInfo as it disables a few optimisations.