Installing OpenMW on Ubuntu

A generic talk on the OpenMW project.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1189
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Github profile: https://github.com/lgromanowski
Contact:

Installing OpenMW on Ubuntu

Post by lgromanowski » 21 Aug 2011, 21:17

werdanith wrote: I see we have a linux binary up so I wanted to know what it takes to get the engine working on my Ubuntu Maverick netbook.
First of all, our Installation Instructions wiki page needs to be fixed, since clearly in order to get it to work in Linux you need a bunch of libraries. This is how my quest to install them has been going.

First the engine complains that it lacks libOgreMain.so.1.7.2 which you can install by adding the ogre ppa, ppa:ogre-team/ogre and upgrading which installed the library for me.
Next it complains about libOIS-1.2.0.so which is easier, just type sudo apt-get install libois-1.2.0
Now the game complains about libboost_system-mt.so.1.45.0
The Ubuntu repos don't have the 1.45 version of Boost (only 1.40 and 1.42).
I tried to look for a PPA and found this one https://launchpad.net/~antal.buss/+archive/boost which has 1.45, I added it and installed everything related to 1.45 and the engine still complained.

Does anyone have any solution that hopefully doesn't involve building Boost from source that we can advise Ubuntu users to do?
Can we maybe ship the library with our binary?
werdanith wrote: The files from the PPA are correct (probably) but you need to make symbolic links to them.
For example the engine asks for
libboost_system-mt.so.1.45.0
while the PPA offers
libboost_system-mt.so

I'll make them all and see what comes up next.
Zini wrote:
Can we maybe ship the library with our binary?
We usually don't do that on Linux. And I don't think either, that we actually need a newer boost. Ideally we would adjust OpenMW in a way, that it can be build with several different versions of libraries like OGRE and Boost. The packager would then build it against the versions available on the target distribution. That is higher building magic though and I have no clue about it.
werdanith wrote: I made the links and the engine starts and ... segfaults, probably because I don't have Morrowind's data in place.
We need a gentler error message for that event.
I'll try again once I copy them, which might take a while.
Note: the Linux build doesn't even ship with a default openmw.cfg, I had to copy it.
Zini wrote:
I made the links and the engine starts and ... segfaults, probably because I don't have Morrowind's data in place.
Nope. OpenMW exists cleanly in this case with a somewhat suitable error message:
ERROR: boost::filesystem::basic_directory_iterator constructor: No such file or directory: "/home/marc/OpenMW/build/data2"
Could use some improvements, but it is certainly not a segfault.
werdanith wrote:
Zini wrote:
Could use some improvements, but it is certainly not a segfault.
Indeed, that was not the source of the error, according to the ogre.log it does load resources, but it segfaults.
This is the last output in the log before it dies, maybe someone can make sense of it.

Code: Select all

17:29:26:  * PBuffer support: yes
17:29:26:  * GL 1.5 without HW-occlusion workaround: no
17:29:26: Registering ResourceManager for type Texture
17:29:26: DefaultWorkQueue('Root') initialising on thread 0xa61e430.
Maybe it's related to the graphics hardware, I wouldn't be surprised if my measly Intel 945 is supposed to segfault under the circumstances.
werdanith wrote: The Linux binary we ship is compiled against ogre 1.7.2 and our wiki advises the use of 1.7.1, as a result I can't even get it to run on my desktop with the development environment perfectly set up without reinstalling/recompiling Ogre, or making symbolic links or something.

Linux, where getting a binary you downloaded to run is harder than compiling it from source. I give up.
Peppe wrote:
werdanith wrote:Maybe it's related to the graphics hardware, I wouldn't be surprised if my measly Intel 945 is supposed to segfault under the circumstances.
It is not supposed to segfault any way.
You don't state exactly which build you are trying to run but I assume it's one of the binary builds so debugging will probably not give a lot of details, but perhaps something. Easiest way is probably to enable core file generation (ulimit -c unlimited), run it, let it crash and pull a stack trace from the core file (gdb openmw core -batch -ex "thread apply all backtrace full").
Linux, where getting a binary you downloaded to run is harder than compiling it from source. I give up.
You have the same problem on any platform, if you download a binary build towards dynamically linked libraries you don't have it will not work.
werdanith wrote: I changed the core file size to unlimited and ran the game. It produced a core file of 0 bytes.
Unsurprisingly gdb complained that it can't recognize the format.

As for the build, it's the 32bit build that is hosted on google code.
werdanith wrote: I run the game through gdb and got this:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0xb79711a3 in boost::thread::start_thread() ()
   from /usr/lib/libboost_thread-mt.so.1.45.0
So maybe that library that I got from the PPA was crappy, or I screwed up something with the symbolic links.
I made a link with that name to point to libboost_thread.so.1.45.0 since there was already two links named /usr/lib/libboost_thread.so and /usr/lib/libboost_thread-mt.so
that pointed at the same file.

Edit reason: Two links, not three.
best regards,
Lukasz

Locked

Who is online

Users browsing this forum: No registered users and 1 guest