PyCEGUI 0.8.4 fails to build against boost 1.60

Issue #1114 resolved
Rémi Verschelde
created an issue

Operating System: Mageia Linux (64-bit) OS version: 6 (Cauldron, development) GCC 5.3.1 - Boost 1.60

Since we switched to boost 1.60 in Mageia's buildsystem, CEGUI 0.8.4 does not build anymore: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20151226202904.daviddavid.valstar.20574/log/cegui-0.8.4-27.mga6/build.0.20151226203010.log (search for the "error:" string to spot the issue in the huge log)

The error runs like:

/home/iurt/rpmbuild/BUILD/cegui-0.8.4/cegui/src/ScriptModules/Python/bindings/output/CEGUI/TreeItem.pypp.cpp:911:1:   required from here
/usr/include/boost/python/converter/registered.hpp:93:30: error: no matching function for call to 'registry_lookup2(void (*)())'
       return registry_lookup2((T(*)())0);
                              ^
/usr/include/boost/python/converter/registered.hpp:83:3: note: candidate: template<class T> const boost::python::converter::registration& boost::python::converter::detail::registry_lookup2(T& (*)())
   registry_lookup2(T&(*)())
   ^
/usr/include/boost/python/converter/registered.hpp:83:3: note:   template argument deduction/substitution failed:
/usr/include/boost/python/converter/registered.hpp:93:30: note:   mismatched types 'T&' and 'void'
       return registry_lookup2((T(*)())0);
                              ^
cegui/src/ScriptModules/Python/bindings/CMakeFiles/PyCEGUI.dir/build.make:713: recipe for target 'cegui/src/ScriptModules/Python/bindings/CMakeFiles/PyCEGUI.dir/output/CEGUI/TreeItem.pypp.cpp.o' failed

Comments (53)

  1. Rémi Verschelde reporter

    We don't plan to rollback to an earlier boost version for the future Mageia 6, but there is also no hurry - I can temporarily disable the build of PyCEGUI for now until there is a patch to backport (as our OpenImageIO packager did too until the issue was fixed a few days ago). So far I think the only package in Mageia that uses PyCEGUI is CEED.

  2. Lukas Meindl

    Okay, it seems like this should be easy to fix but I never touched this part of CEGUI. Any chance you can figure out what is wrong and make a PR? I will gladly merge it.

  3. Rémi Verschelde reporter

    I can have a look at it but it might take some time as I'm still running Mageia 5 (with boost 1.55) currently, but I do plan to upgrade to the current development version and then I can hack a bit at PyCEGUI with boost 1.60.

  4. chris beck

    I looked into the exact issue a little bit -- I haven't been able to solve it, I'm not really experienced with boost python.

    However, it appears that the issue is in adapting the constructor of CEGUI::ListboxItem to python. The constructor has signature unsigned int, void *, bool, bool. The int is the index of the item, the void * is userdata, and the bool are some flags.

    The problem is that in previous versions of boost python, this would be adapted successfully, but in boost 1.60, it's rejected. And in the docs, they say that void * is simply not supported as an argument or return type.

    One piece of useful info is, if it is "wrapped" with a caller function which passes a pointer to any (even empty) class type instead, and casts that to void, it will be acceptable to boost python: See "How do I handle void * conversion?"

    Also, see boost::python::make_constructor: https://wiki.python.org/moin/boost.python/HowTo#named_constructors_.2F_factories_.28as_Python_initializers.29

    So intuitively, one approach would be go to the registration of ListboxItem here, exclude all the constructors, and instead register a factory function which safely wraps the void *.

    I didn't get far enough to actually try it though, my main development machine is down right now and my mac-book is not adequately set up to attempt this yet.

    HTH

  5. David Reepmeyer

    Archlinux users: A quick workaround is to downgrade boost to the last version of 1.59 (before 1.60). Running the following script will acomplish the downgrade then rebuild cegui and ceed. I would like to fix the root of the issue but I don't really know python or boost well enough

    cd /var/cache/pacman/pkg/
    wget https://archive.archlinux.org/packages/b/boost/boost-1.59.0-5-x86_64.pkg.tar.xz
    wget https://archive.archlinux.org/packages/b/boost-libs/boost-libs-1.59.0-5-x86_64.pkg.tar.xz
    pacman -U boost-libs-1.59.0-5-x86_64.pkg.tar.xz boost-1.59.0-5-x86_64.pkg.tar.xz
    
  6. Christopher Beck

    Really glad that this is a 1.60 only issue, it makes it hard to build CEED if you can't build PyCEGUI, so if telling people to upgrade to boost 1.61 fixes it then that is great. +1

  7. Christopher Beck

    I just saw an old email in my spam that linked to this comment... T_T

    I can try to do a test of vanilla CEGUI versions against various boost versions, but I assume that if there were more problems they would have got reported.

  8. Yaron Cohen-Tal

    @Christopher Beck: Thanx for volunteering to do this. However, I really don't think it's our role to manage Boost regressions - that's for the Boost ppl to do. They make releases regularly and I think it's impractical that every project that uses boost should test itself against every recent boost version.

  9. Christopher Beck

    Hey, so I used to have an old server that was running an automatic cegui github mirror and trying to regularly track the mercurial repository.

    However that machine broke a few months ago (it was physically in my house :p )

    More recently I was fiddling around with an actual server hosted remotely, for like personal website and stuff like that. (I have a lot of time recently...)

    I guess my plan is,

    1. try to get the automatic github mirror running again
    2. set up a travis-ci on the automatic mirror which tests against many boost versions

    That is how I usually do testing against boost versions for libs that I make. For instance here's another lib I made, it tests against like 8 versions of boost :)

    https://github.com/cbeck88/spirit-po/blob/master/.travis.yml

    If I got the github mirror working again then this kind of testing is trivial.

  10. Yaron Cohen-Tal

    @Christopher Beck: Assume u find a bug in Boost ver x that was fixed in Boost ver y. What do u do then? Seems like Boost very rarely makes bug-fix releases, so they'll just tell u to switch to version >=y. So the only benefit I can see is to test the latest Boost ver anyway.

    If u have a lot of time I guess we could find some more useful stuff u can do for cegui..

  11. Christopher Beck

    Yeah but it's useful to know that "boost ver x works, boost ver y doesn't"

    Many linux distributions basically only distribute a certain version in their package managers, so it becomes really annoying if the boost in that linux doesn't work. It's not at all trivial to just upgrade to latest boost version, unless your dependencies are header only. And boost python is not header-only afaik :(

    I think it's useful for me to know how to do this kind of automatic mirroring thing anyways

  12. Yaron Cohen-Tal

    Ok, go for it then :)

    I'm aware of the distributions problem, however there's little we can do about it, other than have those distributions patch their Boost to fix that bug. And that starts to become a mess.

    Perhaps a more practical and useful thing to do would b to test Boost versions b4 they're released, so that the bugs can b fixed inside the official Boost when it's released. If you're willing to do that, it'll b appreciated.

  13. Christopher Beck

    I set up the travis thing, here's an example build https://travis-ci.org/cbeck88/cegui-mirror-two/builds/186457331

    The v0-8 branch appears to fail against 1.59 and 1.60, and works against 1.61 and 1.62

    I didn't really look into either of them. I dimly remember that I was able to build against 1.59, but it might have required a more recent gcc. These tests were gcc 4.8. I might set it up to build against 4.9 and 5.4 also.

    There were other failures on default branch, which I reported separately.

  14. Christopher Beck

    do you think its a good idea to do master, or just their "beta" releases? there might be a lot of noise from master, idk

    maybe master is the way to go though, can try it and find out i guess

  15. Yaron Cohen-Tal

    @Christopher Beck: I dunno, they also have a branch develop which is prolly even more unstable. Usually when u wanna test a development branch u use master, but I can't tell u anything specific about Boost; yeah, u can prolly just try it out and c. I'd start with branch master, and only if it seems to b too unstable go for the latest (in this case beta) pre-release.

  16. Christopher Beck

    Yeah, so I started one using master, but it looks like I got a build failure within boost, some included file doesn't exist (?)

    Not sure if there's some preparation step that needs to be run first before running boost when you clone it from the repo like this?

    https://travis-ci.org/cbeck88/cegui-mirror-two/jobs/186557679

    Might poke it a bit later

    I think I'm doing exactly the same thing the boost hana guy is doing: https://github.com/boostorg/hana/blob/master/.travis.yml#L226

    so maybe boost master just doesn't always build ? :/

  17. Christopher Beck

    The way I'm doing it works on my local machine, but not on the travis instance. But I also have a libboost-dev version installed so possibly that is masking the file-not-found error...

    I think it's important to somehow get the "--depth 1" flag in there somewhere or it will risk timing out the travis build, at least that's what I understand.

  18. Yaron Cohen-Tal

    @Christopher Beck: Yeah, it should work either way, and it works for me too either way.

    I don't know y the travis doesn't work for u. I have libboost-dev installed locally too and it doesn't create any problems.

    Yeah, --depth 1 in a CI is a good idea if u don't want them to ban u ;)

  19. Christopher Beck

    Ok, I tried doing it your way with the git submodule update, now it fails to clone libs/accumulators:

    https://travis-ci.org/cbeck88/cegui-mirror-two/jobs/186812059

    That was this version of the command:

      travis_retry git clone --depth 1 https://github.com/boostorg/boost boost || exit 1
      cd boost
      travis_retry git submodule update --init --recursive --remote --no-fetch --depth 1 || exit 1
    

    This is my log:

    fatal: Needed a single revision
    
    Unable to find current origin/master revision in submodule path 'libs/accumulators'
    
    The command "git submodule update --init --recursive --remote --no-fetch --depth 1" failed. Retrying, 2 of 3.
    

    Actually I reproduce this locally on my ubuntu machine also :/

    Thinking now it might be better to just try to test the beta releases...

    I wonder if there is an easy way to build boost.python without building all of boost?

  20. Yaron Cohen-Tal

    @Christopher Beck:: I'm glad building Boost branch master works now! Thanx for doing the testing!

    Yeah, my guess is ./b2 headers is what fixed it. Seems like the headers must be genereated when using Boost version from Git. One of the things that confused me is that on our local machines it worked without this step, but that's prolly coz we had recent enough boost headers installed systemwide, what the Travis machine prolly doesn't have..

  21. Log in to comment