Skip to content

Improving LCGCmake builds on ubuntu1404-gcc48

Hadrien Benjamin Grasland requested to merge (removed):ubuntu1404-gcc48-build-integration into ubuntu_tests

Hi everyone,

Here is a branch featuring most of the LCGCmake tweaks which I had to apply in order to get it to build on ubuntu 14.04.

Required dependencies on my Ubuntu machine, if you want to record that somewhere, were as follows:

  • For lockfile issues: procmail
  • For Python2.7: python-gdbm-dev tk-dev libncurses5-dev libdb-dev python-bsddb libreadline-dev
  • For Geant4: libmotif-dev

You will find attached a summary of the remaining test errors which I don't know how to address:

make_test.log test_results.tar.gz

One point which I do not know how to address yet is that at this point, builds for sherpa-2.2.0 and sherpa-2.2.0.blackhat fail with various linking errors related to libLHAPDF. I can trace it back to a LIBRARY_PATH parameter to make not being taken into account, which I replaced by manually setting LD_LIBRARY_PATH on my machine when running make, but obviously a better fix is needed.

Finally, the reason why I'm marking this merge request as WIP and not final is that I had to do something quite ugly in order to get Qt to build, and I'm looking for suggestions of a better alternative:

The problem which I was trying to address is that in src/3rdparty/webkit/Source/JavaScriptCore/wtf/TypeTraits.h , there are using declarations for multiple standard math functions, including std::isnan and std::isinf. Now, obviously, this is bound to produce namespace collisions since there are identically named functions in the libc. And the code doesn't disappoint.

Completely addressing this requires hunting through the Webkit codebase for all references to these functions, and replacing them with fully qualified calls to namespace'd function, e.g. isnan() -> std::isnan() or webkit::isnan(). But that's a large undertaking, that would have to be done over and over again for every patched Qt4 release.

My answer was thus to replace the using declarations with macros that have similar semantics, but turn e.g. isnan calls into std::isnan calls. For example...

#ifndef isnan
#define isnan(x) std::isnan(x)
#endif

This works because the preprocessing stage occurs before the namespace collision resolution occurs. It is an ugly hack, because already qualified calls to "std::isnan" will be turned into nonsensical "std::std::isnan" calls by the preprocessor, causing errors. And, well, any code which features preprocessor macros is a hack, really 🙁

So if you have an idea of a better solution, I am all ears.

Cheers, Hadrien

Merge request reports