Build notes for Ember prerequisites
  • JonJon
    I've been working on building the Ember code from git, and wanted to share some notes. Rather than put this in the Wiki, I'll share things here so that others can decide what makes sense.

    I am building under Fedora 10, and it looks like the following packages were downloaded via yum:

    * libcurl
    * SDL
    * openal
    * openal-devel
    * pcre
    * pcre-devel
    * cg
    * freealut
    * freealut-devel
    * ois
    * ois-devel

    I'm not sure on the devel packages, if they really exist. I just went back over my shell history and saw I attempted to load them. It is usually a good idea to pull down the devel versions of libraries if they exist. I have noticed (under Fedora) that configure will complain about a package not existing when in fact it does. What configure is actually complaining about is the devel version of the package not existing. I attribute this to configure being developed on systems which do not split the runtime and devel versions of packages. The worst case scenario is that yum tells you the package doesn't exist when you ask it to install.

    I made a couple of changes to Filter.cpp in Atlas-C++-0.6.1. I believe something was erroneously referenced in the std namespace, when it shouldn't be. Also I believe memset and memcpy were not found. I changed the include of <string> to <string.h> so that the definitions could be picked up.

    I believe CEGUI 0.6.2 was using ILvoid in a couple of places. I really don't have much to go on other than memory. But I think one of the spots was CEGUIDevILImageCodec.cpp. ILvoid was removed from DevIL, so I replaced ILvoid with void. Everything built OK, and CEGUI-based Ogre demos work.

    Speaking of CEGUI, I rebuilt this from source rather than using the package. This was so I could change configuration parameters. I ended up using: --disable-opengl-renderer --includedir=/usr/local/include/CEGUI --enable-toluacegui
    I also added -lzzip to CEGUI.pc so that running configure on Ember would find lua. There is probably a better solution, but I was in a hurry. The code to check for lua was failing to link due to libzzip being missing, rather than the lua library. I think most CEGUI users will want libzzip anyways.

    IO.cpp in libwfut-0.2.1 needed to include <algorithm> so that std::find could be picked up.


    The following packages were downloaded and built from source (rather than being installed via yum):
    * Altas-C++-0.6.1
    * CEGUI-0.6.2
    * eris-1.3.14
    * freetype-2.3.9
    * libsigc++-2.2.0
    * libwfut-0.2.1
    * mercator-0.2.7
    * ogre-1.6.2
    * skstream-0.3.6
    * varconf-0.6.6
    * wfmath-0.3.9
    * zziplib-0.13.54

    This list is probably the same as on the Wiki, I don't think there were any surprises. The zziplib was obtained from sourceforge, so I agree with the later link on the Wiki. I think Ogre has this as a prereq, and they point users to sourceforge.

    As for building Ogre, here is how I configured it. I first exported LIBS=-lzzip since I got tired of fighting with configure. Next the following
    switches were used: --with-platform=GLX --disable-freeimage --enable-devil --enable-ogre-demos

    I like building the Ogre demos, since it shows that a lot of the supporting code is working.

    Where this leaves me at present is that configure completes for Ember, but ember (via git) does not build. The support libraries build and I believe are functional. Ember's gripe is with ConfigListenerContainer.h, specifically with the typedef of SettingChangedSlot. The header file <sigc++/slot.h> has only a #define, and no type definitions so the compiler has no clue what a sigc::slot is.

    Update: Including <libwfut/WFUT.h> at the top of ConfigListenerContainer.h got past the build issue. I'm willing to be that is not
    the proper fix, but I noticed that WfutSession.h made use of sigc::slot and didn't have any compile issues. Perhaps this gives someone a clue what the proper fix should be.

    Update 2: got as far as the main link which failed. I'm seeing an error about an undefined reference to setDefaultPCallErrorHandler. I see a mention of this error in the IRC log, but no indication of a solution. I'm going to spend some time later seeing if I can track this down.

    The exact error is:
    GUIManager.cpp:130: undefined reference to `CEGUI::LuaScriptModule::setDefaultPCallErrorHandler(CEGUI::String const&)'


    A string search shows this symbol in libCEGUILuaScriptModule.so.1.2.0 so this is a good place to start. I dumped the symbols using nm and found two definitions:
    000000000009dc50 T _ZN5CEGUI15LuaScriptModule27setDefaultPCallErrorHandlerERKNS_6StringE
    000000000009b670 T _ZN5CEGUI15LuaScriptModule27setDefaultPCallErrorHandlerEi

    which demangle to
    CEGUI::LuaScriptModule::setDefaultPCallErrorHandler(CEGUI::String const&)
    CEGUI::LuaScriptModule::setDefaultPCallErrorHandler(int)

    The first flavor, with the string reference matches what the linker was looking for (at least to my eye). I verified that the library was included on the command line of the link ( -lCEGUILuaScriptModule ) and that the library path pointed to the directory with this lib: ( -L/usr/local/lib )
    Since the T in the nm output means the symbol was defined in the text section, I believe that pulling in this library would be sufficient to resolve the reference. In years past I recall problems where library ordering was an issue, I'm not sure if that is still the case.
    So I am still puzzled as to what may be going on here.
  • JonJon
    I spotted an old version of the CEGUI libraries which were being pulled in instead of the newly built ones.
  • erikerik
    Hi, as you've discovered yourself the error you got was because you had an older version of the CEGUI library installed. That method signature is new in 0.6.2.

    I would think it's also better if you use the hammer script, found here: http://wiki.worldforge.org/wiki/Compili ... mer_Script
    It will download all of the latest versions of the libs and the client for you. Many of the issues that you describe have already been fixed in git, so it's better to use that directly than the released versions.
  • JonJon
    Thanks for getting back to me, I haven't seen anyone on IRC or in here for a bit and was getting worried. Perhaps it is just a matter of adjusting the times when I check IRC, but I have left my client on overnight on occasion and seen nothing. In the end I managed to get past my issues on my own, but it was expensive in terms of time.

    To say I am nervous about using the Hammer script would be an understatement. I have a working client and a working server at the moment, and don't trust the script to understand the nuances of every Linux distribution.

    Please note that I am currently using Ember code from git That is very important for me to get across. The code I pulled from git is a few days old, and so I did a new pull this morning. No updates to ConfigListenerContainer.h came down. Although I am having to rebuild everything. We use subversion at our lab, and I have no experience with git outside of my efforts here. I am assuming that "pull" is similar to svn's "update".

    On a related note, I did not obtain cyphesis via git. Would I be right in assuming there is a similar git repository? (Update: I see there is a CVS repository for worldforge, mentioned on the Cyphesis web page. I wonder how out of date this is, since the Cyphesis change log left off in 2000). This is a good argument for having the documentation on a wiki, where entries are time-stamped.

    I'm willing to share patches, but cannot guarantee that anyone would find them of value. Having my cyphesis in sync with everyone else would be a good thing. I haven't been considering using development versions of the support libraries.
  • erikerik
    Hi, you shouldn't worry about using the hammer script: it will install everything to its own subdirectory, so there's no chance of it messing up your current setup.

    Cyphesis has moved to git. We need to update the web page to reflect this. If you plan to patch cyphesis it would be excellent if you did those patches in a local git branch. If you feel that they would benefit the project it's then a simple task of publishing them or merging them into cyphesis master. That of course requires you to get cyphesis from git.
    The development versions of the support libraries are all extremely stable, often more stable than the released versions, so I definitely encourage you to use them.
Add a Comment

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID
Sign In Apply for Membership

Categories