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?
OpenMW 0.47.0
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: OpenMW 0.47.0
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.
Yeah that needs to be included. I'll add some other libraries that seem reasonable to include and create a new RC.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?
Re: OpenMW 0.47.0
For the sake of posterity, installing libxcb-xinput0 via my package manager fixed my problem.
Re: OpenMW 0.47.0
Generic Linux targz package RC2:
64 Bit
The lib directory now also contains libjpeg62, libexpat, libgraphite2, libharfbuzz, libfreetype, libglib, libgthread and libpcre.
64 Bit
The lib directory now also contains libjpeg62, libexpat, libgraphite2, libharfbuzz, libfreetype, libglib, libgthread and libpcre.
Re: OpenMW 0.47.0
Did you ever provide a Flatpak?
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: OpenMW 0.47.0
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/
https://github.com/flathub/org.openmw.O ... tributors/
- johnnyhostile
- Posts: 25
- Joined: 08 May 2019, 17:26
- Location: USA
- Gitlab profile: https://gitlab.com/hristoast
- Contact:
Re: OpenMW 0.47.0
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?
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.
Re: OpenMW 0.47.0
Built up new Windows dependencies and a new 64-bit RC build;
https://openmw.rgw.ctrl-c.liu.se/Releas ... -win64.exe
https://openmw.rgw.ctrl-c.liu.se/Releas ... -win64.exe
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: OpenMW 0.47.0
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)
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)
- AnyOldName3
- Posts: 2685
- Joined: 26 Nov 2015, 03:25
Re: OpenMW 0.47.0
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.
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.