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
while the PPA offers
I'll make them all and see what comes up next.
Zini wrote: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.Can we maybe ship the library with our binary?
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:Nope. OpenMW exists cleanly in this case with a somewhat suitable error message:I made the links and the engine starts and ... segfaults, probably because I don't have Morrowind's data in place.
Could use some improvements, but it is certainly not a segfault.ERROR: boost::filesystem::basic_directory_iterator constructor: No such file or directory: "/home/marc/OpenMW/build/data2"
werdanith wrote:Indeed, that was not the source of the error, according to the ogre.log it does load resources, but it segfaults.Zini wrote:Could use some improvements, but it is certainly not a segfault.
This is the last output in the log before it dies, maybe someone can make sense of it.
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.
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.
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:It is not supposed to segfault any way.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.
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").
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.Linux, where getting a binary you downloaded to run is harder than compiling it from source. I give up.
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:So maybe that library that I got from the PPA was crappy, or I screwed up something with the symbolic links.
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
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.