Building OIS instead of using the shared library
Moderator: Oberlus
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
Building OIS instead of using the shared library
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.]
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.]
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Building OIS instead of using the shared library
This is intentional. This (stripped) source is only used with the platform SDK for windows and mac osx.I notice that a sub-set of the OIS source files come with the FreeOrion source, though they are not compiled at build-time.
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.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!
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=79237
https://forum.openmw.org/viewtopic.php?f=6&t=1276
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.Can they advise on the easiest way for me to change my local configuration to test a few things?
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- 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
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.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.
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Building OIS instead of using the shared library
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.Geoff the Medio wrote: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.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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
Re: Building OIS instead of using the shared library
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: At the commandline, in the right directory (In my installation, libX11.so.6 is a link to libX11.so.6.3.0): ...gives : Yet, gives: ... 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 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?
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
[...]
Code: Select all
nm libX11.so.6.3.0
Code: Select all
nm: /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0: no symbols
Code: Select all
libX11.a | grep XNextEvent
Code: Select all
0000000000000000 T XNextEvent
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 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?
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Building OIS instead of using the shared library
It's a bit offtopic, but okay: the linker statement you quoted already tells you what is wrong.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.
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./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
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. TrymrSpaceman wrote:At the commandline, in the right directory (In my installation, libX11.so.6 is a link to libX11.so.6.3.0):...gives:Code: Select all
nm libX11.so.6.3.0
Yet,Code: Select all
nm: /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0: no symbols
gives:Code: Select all
libX11.a | grep XNextEvent
Code: Select all
0000000000000000 T XNextEvent
Code: Select all
nm -D libX11.so.6.3.0
Not that I am aware of.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?
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
Re: Building OIS instead of using the shared library
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: and .
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
Code: Select all
FFConsoleTest_LDADD = -lOIS -lX11
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
Re: Building OIS instead of using the shared library
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:...but of course the make fails: 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.
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
[...]
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....
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
Re: Building OIS instead of using the shared library
Sorry, I found this on the wiki (http://freeorion.org/index.php/Compile_ ... cy_Changes):
Code: Select all
rm CMakeCache.txt
make clean
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Building OIS instead of using the 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.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.
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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
Re: Building OIS instead of using the shared library
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.
The other thing to say is that OIS version 1.4.0 does not fix the Linux Alt-TAB issue.
Re: Building OIS instead of using the shared library
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 viamrSpaceman wrote:Once I'd done the prescribed clean up of the make and cmake files things went well.
Code: Select all
sudo apt-get install cmake-curses-gui
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
- mrSpaceman
- Space Floater
- Posts: 31
- Joined: Fri Apr 29, 2011 3:58 pm
- Location: UK
Re: Building OIS instead of using the shared library
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!
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!
Re: Building OIS instead of using the shared library
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