Building OIS instead of using the shared library

Questions, problems and discussion about compiling FreeOrion.

Moderator: Oberlus

Post Reply
Message
Author
User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Building OIS instead of using the shared library

#1 Post by mrSpaceman »

Hi there,

My query pertains to configuring CMake such that the OIS source is build instead of depending on an installed library. This exercise is to find where problems in Linux keyboard input are arising, and potentially remove current problems (see thread: http://freeorion.org/forum/viewtopic.ph ... 9&start=30). I'm just testing things at the moment.

I notice that a sub-set of the OIS source files come with the FreeOrion source, though they are not compiled at build-time. I'm hoping that it is possible to build these, so that I can try some modifications to the class methods. Whether these modifications can then be supplied with FreeOrion, or if they can be added to a new release of OIS, is probably for future discussion in a different sub-forum! At the moment I am happy hacking away at these codes, learning a lot about programming games in C++.

Has any one person set up the CMakeLists.txt files for FreeOrion? Can they advise on the easiest way for me to change my local configuration to test a few things? Despite being fairly computer-savvy, Makefiles are still one of those things which I haven't got 100% to grips with yet. Any useful advice will be appreciated.

[It might help you to know that I am running Ubuntu 14.04 on an AMD64 and have the latest revision of FreeOrion from the SVN.]

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Building OIS instead of using the shared library

#2 Post by adrian_broher »

I notice that a sub-set of the OIS source files come with the FreeOrion source, though they are not compiled at build-time.
This is intentional. This (stripped) source is only used with the platform SDK for windows and mac osx.
Whether these modifications can then be supplied with FreeOrion, or if they can be added to a new release of OIS, is probably for future discussion in a different sub-forum!
We don't maintain upstream projects. If you have problems with OIS please refer to the OIS project. Which won't help because upstream is dead and the issues you describe are well known by other user of the library (e.g. OGRE). The OGRE project for example already discuss to abandon OIS in favour of SDL in future releases because OIS is unmaintained and broken on all platforms.

http://www.ogre3d.org/forums/viewtopic.php?f=4&t=79237
https://forum.openmw.org/viewtopic.php?f=6&t=1276
Can they advise on the easiest way for me to change my local configuration to test a few things?
The code you refer to doesn't contain any build system by itself and wasn't ever incorporated into the CMake build system. OIS upstream uses automake. So the 'easiest' way to fix this is to ignore the OIS code in our tree, use the OIS upstream code, fix it and, well no idea, maintain the project yourself? There is nobody that could appreciate your effort. The main users of OIS are going away soon and we should probably follow.

You can also write CMake files by yourself from scratch to use the OIS code in our source tree. But this will cause even more problems at installation and runtime because our customized OIS library will 'cover' or even worse overwrite the regular system installation of OIS or we woudn't see our custom OIS library without setting LD_LIBRARY_PATH or similar stuff which usually isn't very welcome by distribution maintainers.

The bottom line: OIS is broken beyond repair, the maintainer doesn't maintain it anymore and we should better start working on replacing it with a working library.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Building OIS instead of using the shared library

#3 Post by Geoff the Medio »

adrian_broher wrote:The bottom line: OIS is broken beyond repair, the maintainer doesn't maintain it anymore and we should better start working on replacing it with a working library.
Given the lack of any substantial use for the Ogre rendering engine in FreeOrion right now, or any reasonable expectation of development proceeding on the 3D combat system, the Ogre dependency, including, OIS, could be removed and replaced with SDL window management, as was the case prior to moving to Ogre. GG still has an SDLGUI implementation, although I have no idea how usable it is.

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Building OIS instead of using the shared library

#4 Post by adrian_broher »

Geoff the Medio wrote:
adrian_broher wrote:The bottom line: OIS is broken beyond repair, the maintainer doesn't maintain it anymore and we should better start working on replacing it with a working library.
Given the lack of any substantial use for the Ogre rendering engine in FreeOrion right now, or any reasonable expectation of development proceeding on the 3D combat system, the Ogre dependency, including, OIS, could be removed and replaced with SDL window management, as was the case prior to moving to Ogre. GG still has an SDLGUI implementation, although I have no idea how usable it is.
Even if I would prefer to keep the Ogre dependency because I intend to work on the 3d combat in long term it's probably the best thing to remove ALL of this for now so we can focus on the management part of the game.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: Building OIS instead of using the shared library

#5 Post by mrSpaceman »

Hah. Right. I noticed that OIS's last code update was years ago. Also, after registering with the WreckedGames forum, and being promised an email verification, things were eerily quiet.

To keep on topic, and not talk about SDL (probably best to start another thread in programming, right?), I'll mention my attempt at building the OIS source with autotools. Well, to jump to the punchline, it failed. Firstly, I thought it was because it couldn't find libX11.so.6 running make gives the output then when I managed to work out how to specify where the file was in my installation, it still complained about not have the correct stuff. The output of running make:

Code: Select all

[...]
/bin/bash ../libtool  --tag=CXX   --mode=link g++  -g -O2 -L../src  -o ConsoleApp OISConsole.o -lOIS 
libtool: link: g++ -g -O2 -o .libs/ConsoleApp OISConsole.o  -L../src /home/rjaduthie/workspaces/GameDevWS/OIS/src/.libs/libOIS.so
/usr/bin/ld: OISConsole.o: undefined reference to symbol 'XNextEvent'
//usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
[...]
At the commandline, in the right directory (In my installation, libX11.so.6 is a link to libX11.so.6.3.0):

Code: Select all

nm libX11.so.6.3.0
...gives :

Code: Select all

nm: /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0: no symbols
Yet,

Code: Select all

libX11.a | grep XNextEvent
gives:

Code: Select all

0000000000000000 T XNextEvent
... so shows that the OIS make configuration is wrong, though could possibly be fixed with the right commands. I was going to keep this discussion to the WreckedGames OIS forum, tho' I suspect I'll never be able to post there (without the elusive email verification).

Of course, I'm thinking that giving up would be more productive. I could learn autotools and solve this, and even start maintaining the OIS code myself :lol: However, I don't think it would as good use of my time currently. Especially if FreeOrion is not going to use it. The bug I wanted to fix (the Linux keyboard Alt-TAB issue) might be resolved by going to SDL. Is there a thread for discussion on doing the switch?

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: Building OIS instead of using the shared library

#6 Post by mrSpaceman »

Thread in programming sub-forum discussing SDL as an OIS replacement:

viewtopic.php?f=9&t=8989

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Building OIS instead of using the shared library

#7 Post by adrian_broher »

mrSpaceman wrote:Firstly, I thought it was because it couldn't find libX11.so.6 running make gives the output then when I managed to work out how to specify where the file was in my installation, it still complained about not have the correct stuff.
It's a bit offtopic, but okay: the linker statement you quoted already tells you what is wrong.
/bin/bash ../libtool --tag=CXX --mode=link g++ -g -O2 -L../src -o ConsoleApp OISConsole.o -lOIS
[…]
/usr/bin/ld: OISConsole.o: undefined reference to symbol 'XNextEvent'
//usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
The application ConsoleApp should be linked out of the object file OISConsole.o (a compiled piece of code, probably the result of compiling OISConsole.cpp), while also using a shared library called OIS located somewhere on the library search path. Now the linker realizes that the object file OISConsole.o references to a symbol (a function or a piece of data that is exposed by a library or another object file) called XNextEvent that isn't exposed by any other object file or shared library (undefined reference to symbol). However it knows that there is in fact a library that exposes this symbol (libX11.so.6) but the user didn't add it to the command line and because the user always knows best the linker just tells you that (//usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line) instead of adding the library on its own. This could be fixed by adding somewhere in the autoconf files a compile flag that adds libX11 to the linker stage of ConsoleApp.
mrSpaceman wrote:At the commandline, in the right directory (In my installation, libX11.so.6 is a link to libX11.so.6.3.0):

Code: Select all

nm libX11.so.6.3.0
...gives:

Code: Select all

nm: /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0: no symbols
Yet,

Code: Select all

libX11.a | grep XNextEvent
gives:

Code: Select all

0000000000000000 T XNextEvent
You're dumping the static symbols. There seem to be two tables for symbols inside ELF files, one for static symbols and one for dynamic symbols. Try

Code: Select all

nm -D libX11.so.6.3.0
instead.
Of course, I'm thinking that giving up would be more productive. I could learn autotools and solve this, and even start maintaining the OIS code myself :lol: However, I don't think it would as good use of my time currently. Especially if FreeOrion is not going to use it. The bug I wanted to fix (the Linux keyboard Alt-TAB issue) might be resolved by going to SDL. Is there a thread for discussion on doing the switch?
Not that I am aware of.

Unfortunately porting to another library is something bigger to do. Especially if the platform SDKs also need to be updated and testing on all platforms is a bit more complex so this won't happen immediately and I am sure there are some unknown dependency issues somewhere in the code.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: Building OIS instead of using the shared library

#8 Post by mrSpaceman »

With experience comes great wisdom, perhaps? Thanks for the run down the OIS compiling. It was a little off-topic, though still an OIS compiling issue.

EDIT:

Just to add that the solution was to add -lX11 to the Makefile.am file in the demos subfolder like:

Code: Select all

ConsoleApp_LDADD = -lOIS -lX11
and

Code: Select all

FFConsoleTest_LDADD = -lOIS -lX11
.

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: Building OIS instead of using the shared library

#9 Post by mrSpaceman »

Oh, but it goes on....

So I managed to install libOIS (it says it's version 1.4.0) from source and it's put itself in a different place in the tree to previously (/usr/local/lib/ rather than /usr/lib/x86_64-linux-gnu/). I'm sure there's a way to specify where to install the new shared library; however, my next question again relates to cmake and FreeOrion.

I ran cmake in the FreeOrion tree to set myself up with the new libOIS. I had already uninstalled the old libOIS (the one in the Ubuntu package repo: version 1.3.0). The cmake seems not to care about all this and still tries to use the old version in the old location:

Code: Select all

[...]
-- Looking for OIS...
-- Found OIS: optimized;/usr/lib/x86_64-linux-gnu/libOIS.so;debug;/usr/lib/x86_64-linux-gnu/libOIS.so
[...]
...but of course the make fails:

Code: Select all

[...]
[ 69%] Built target freeorioncommon
make[2]: *** No rule to make target `/usr/lib/x86_64-linux-gnu/libOIS.so', needed by `libGiGiOgrePlugin_OIS.so'. Stop.
make[1]: *** [GG/src/Ogre/Plugins/CMakeFiles/GiGiOgrePlugin_OIS.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
I was under the impression that in running cmake the makefile would be created with current information on library locations. It seems cmake only remembers the old ones. This is probably me being stupid somehow. :roll:

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: Building OIS instead of using the shared library

#10 Post by mrSpaceman »

Sorry, I found this on the wiki (http://freeorion.org/index.php/Compile_ ... cy_Changes):

Code: Select all

rm CMakeCache.txt
make clean

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Building OIS instead of using the shared library

#11 Post by adrian_broher »

mrSpaceman wrote:Oh, but it goes on....

So I managed to install libOIS (it says it's version 1.4.0) from source and it's put itself in a different place in the tree to previously (/usr/local/lib/ rather than /usr/lib/x86_64-linux-gnu/). I'm sure there's a way to specify where to install the new shared library.
There is the --prefix parameter for the configure step to set /usr instead of /usr/local but I don't recommend this. /usr/local is specifically for local system installation (hence the name), /usr is under the control of the package management of the OS. Don't touch it unless you want to make yourself unhappy.

To to set the 'correct' libary path you can set the --libdir parameter to /usr/lib/x86_64-linux-gnu instead of /usr/local/lib . There maybe is a way to say configure to use the prefix when setting libdir but I'm not very familiar with automake.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: Building OIS instead of using the shared library

#12 Post by mrSpaceman »

Once I'd done the prescribed clean up of the make and cmake files things went well.

The other thing to say is that OIS version 1.4.0 does not fix the Linux Alt-TAB issue.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Building OIS instead of using the shared library

#13 Post by Dilvish »

mrSpaceman wrote:Once I'd done the prescribed clean up of the make and cmake files things went well.
As a related side-note, if cmake isn't finding a package where you want it to, or there's some other option you want it to handle differently, one possibility is of course to add command line definitions when you invoke cmake. Since our makefiles sometimes decide they should rerun cmake themselves, though, I think the command line definitions won't always work, and of course, you have to remember to use them every time. Your IDE might give you a way to review and change items in the cmake configuration (saving it to the cmake cache); alternatively, I like to use the curses cmake gui, installable in ubuntu via

Code: Select all

sudo apt-get install cmake-curses-gui
The executable is ccmake, just use it in place of cmake and specify the same target as you would for cmake ('.' or '..' or whatever depending on your build setup). It starts out presenting just a subset of the configuration, hit 't' (toggle advanced mode) to be able to scroll through the full set of configuration variables. You select a line you want to change, hit enter, provide the new value and hit enter again. The 'c' key causes it to write out new configuration files (makefiles and updating the cmake cache).

There's normally not much need for this now that Adrian has the cmake configuration set up so well, but sometimes I've had call to change compile flags, for example, and I just prefer to review the configuration in this fashion, and you might find it handy for directing cmake to a nonstandard library location.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
mrSpaceman
Space Floater
Posts: 31
Joined: Fri Apr 29, 2011 3:58 pm
Location: UK

Re: Building OIS instead of using the shared library

#14 Post by mrSpaceman »

Yes, I found the equivalent GUI version: cmake-gui and had a go with that. I'd guess it's more or less the same thing, without seeing the Curses version.

I was actually trying to cmake the OIS source (to avoid having to use autotools). It didn't work straight away (It was upset that a CMakeLists.txt file wasn't present so I left it. Of course, it would work quite well with the FreeOrion source, as the CMakeLists.txt are already established. Do you have to have a CMakeLists.txt file already specified for it to work? Can it be used to create a new set of CMakeLists.txt files? If so, that'd be useful. Even though, I've got to grips enough with the autotools in the OIS source enough to get it built and installed. It's all a learning process! :wink:

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: Building OIS instead of using the shared library

#15 Post by Dilvish »

CMakeLists.txt is really the core set of instructions to cmake about what you want to build; it's not set up to try evaluating 'what might be a sensible way to build the sources in this source tree'. If you really want to try taking on the conversion, this might help.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply