Problem compiling Oolite on Ubuntu 19.10

[Day]

Hi everybody,

long time no see

The work made by another_commander on normal+spec-gloss maps decided me to come back traveling in the Ooniverse

I hit a snag when compiling Oolite.

The nightly works perfectly, but I require the OO_FOV_INFLIGHT_CONTROL_ENABLED flag enabled (because I just love being able to zoom and dezoom the screen while flying), which is not by default.

The compilation works flawlessly (as far as I can tell), but when running the executable, I only have rectangles where I should have text, and only the geometry of the MKIII is rendered.

In the logs, there are lots of png loading errors:

17:03:23.530 [texture.load.png.setup.failed]: ***** Error preparing to read /home/day/workspace/oolite-master/oolite/oolite.app/Resources/Textures/oolite-particle-blur.png.
17:03:23.530 [texture.load.png.setup.failed]: ***** Error preparing to read /home/day/workspace/oolite-master/oolite/oolite.app/Resources/Textures/oolite-particle-flash.png.
17:03:23.545 [texture.load.png.setup.failed]: ***** Error preparing to read /home/day/workspace/oolite-master/oolite/oolite.app/Resources/Textures/oolite_barrel_diffuse.png.
17:03:23.546 [texture.load.png.setup.failed]: ***** Error preparing to read /home/day/.Oolite/AddOns/Oolite.oxp.another_commander.188NSGMaps.1_1.oxz/Textures/oolite_barrel_normal.png.
17:03:23.548 [texture.load.png.setup.failed]: ***** Error preparing to read /home/day/.Oolite/AddOns/Oolite.oxp.another_commander.188NSGMaps.1_1.oxz/Textures/oolite_barrel_specular.png.

Would anyone have an idea or a hint?

Day

Edit: those are installed:
libpng-dev/eoan,now 1.6.37-1 amd64 [installé, automatique]
libsdl1.2-dev/eoan,now 1.2.15+dfsg2-5 amd64 [installé]
libsdl-image1.2/eoan,now 1.2.12-12 amd64 [installé]
libsdl-image1.2-dev/eoan,now 1.2.12-12 amd64 [installé]
libsdl-mixer1.2/eoan,now 1.2.12-12 amd64 [installé]
libsdl-mixer1.2-dev/eoan,now 1.2.12-12 amd64 [installé]

Edit2: I compile with this set of commands:
cd /home/day/workspace/oolite-master/oolite
git pull
git submodule update --recursive --remote
. /usr/share/GNUstep/Makefiles/GNUstep.sh
make -f Makefile clean distclean release

[another_commander]

I think it may have something to do with the libpng on your system. Is there any chance to somehow link against the libpng distributed with the nightly? Sorry I can't be more specific, not coming from a Linux background.

[Day]

Thank you another_commander

Hmm, the problem was there before I installed the nightly. I installed the nightly to check if the problem came from hardware/general conf, or from my build.
So I would say the nightly doesn't interfere.

I check uninstalling the stable and nightly versions

Edit: after uninstalling the stable and nightly versions, the problem is still here.

[another_commander]

The nightly is designed to not interfere. What I was suggesting was to use the noghtly's libpng with your own build. I think there may be some incompatibility between the game's code and the libpng on your system.

[Day]

Sorry, I didn't understand. I will try this.

[Day]

Ok, you put me on the right track, another_commander, but I'm stuck again.

If I understand correctly, to use the provided .so, I need to do a:
make deps-release

and not a:
make release

The deps-release failed, because of the $GNUSTEP_HOST not set (it didn't find the lib_linker drectory).
This is unset by the GNUstep.sh, except if GNUSTEP_SH_EXPORT_ALL_VARIABLES is set.

So now I set GNUSTEP_SH_EXPORT_ALL_VARIABLES:

cd /home/day/workspace/oolite-master/oolite
git pull
git submodule update --recursive --remote
. /usr/share/GNUstep/Makefiles/GNUstep-reset.sh
export GNUSTEP_SH_EXPORT_ALL_VARIABLES=YES
. /usr/share/GNUstep/Makefiles/GNUstep.sh
make -f Makefile clean distclean deps-release

Everything compiles, but when I run "./oolite-app/oolite", I get:

./oolite.app/oolite: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory

And there I am stuck, as I don't know anything about loading shared libraries.

[another_commander]

libpng14.so is the version used by the nightly build and thankfully we have it in the repository. You can get it from here: https://github.com/OoliteProject/oolite ... ng14.so.14

I don'tknow where the nightly exactly places it, but if you could figure that out and copy the file there, then theoretically Oolite should be able to see it and start up.

[Day]

I managed it!

Thank you, another_commander

I nail what exactly was missing and put the answer here.

[Day]

Ok, so...

I reinstalled the nightly, then put my compiled oolite executable instead of the one of the nightly, and ran oolite-wrapper.
It worked :p
as confirmed by the log, that the OO_POV_IN_FLIGHT was compiled in.

So now, there are 2 things that I don't understand:
1) I needed to put "export GNUSTEP_SH_EXPORT_ALL_VARIABLES=YES". Maybe because this is a newer version of GNUSTEP? I don't know.

2) I didn't manage to get the "oolite-wrapper" by myself. My most recent bet is that I had to "make -f Makefile pkg-autopackage" which would need the makepackage executable, which is a slackware executable, and that I would have to install. Anybody could confirm?

[Commander_X]

[Slackware here, didn't hear of makepackage, and not using it]
This is my build "wrapper" (after the initialization as recommended by README.md -- mainly for the submodules):

Code: Select all

git pull
git submodule update
. /usr/local/share/GNUstep/Makefiles/GNUstep.sh
make -j6 debug=no use_deps=yes

(gcc 9.2.0 at this time)
These are my oolite-wrapper active lines I use to launch it from the source tree (from oolite.app, along with oolite executable):

Code: Select all

. /usr/local/share/GNUstep/Makefiles/GNUstep.sh
ESPEAK_DATA_PATH=$(dirname $0)/Resources LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(dirname $0)/Linux-deps $(dirname $0)/oolite

For the record, this is what I have in the oolite.app/Linux-deps folder (copied from the deps/Linux-deps/x86_64/lib folder):

Code: Select all

libespeak.so.1*
libespeak.so.1.non-pulseaudio*
libespeak.so.1.pulseaudio*
libffi.so.4*
libgnustep-base.so.1.20*
libnspr4.so.0d*
libobjc.so.2*
libplc4.so.0d*
libplds4.so.0d*
libpng14.so.14*
libportaudio.so.2*
libvorbis.so.0*
libvorbisfile.so.3*
libz.so.1*

I didn't try to use environment variables during the build process, so I'm afraid I cannot be of too much help here.

[Day]

Thank you Commander_X.

I finally simply put my executable inside the nightly, it works

[Commander_X]

Yup, changing an working executable with yours is the safest way ... as long as it compiles