Another clang compatibility issue

[Alpar Juttner]

Yongjia Song, from lemon-user:

I checked these two version out, however, I still have compiling issues below:

In file included from /Users/administrator/Downloads/lemon-main-62dba6c90f35/tools/lgf-gen.cc:31:

In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:593:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/utility:221:9: error: 

      field has incomplete type '_delaunay_bits::BeachIt'

    _T2 second;

        ^

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__tree:602:16: note: 

      in instantiation of template class 'std::__1::pair<double,

      _delaunay_bits::BeachIt>' requested here

    value_type __value_;

               ^

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__tree:624:22: note: 

      in instantiation of template class

      'std::__1::__tree_node<std::__1::pair<double, _delaunay_bits::BeachIt>,

      void *>' requested here

    typedef typename __node::base                                 __node_base;

                     ^

[...]

-- Sincerely: SONG Yongjia（宋永佳）

[Alpar Juttner]

I cannot reproduce this issue on Linux with clang version 3.3

Could you please let me know how exactly configure and use LEMON? I suspect you apply a custom approach instead of the CMAKE build environment.

[farghen]

I see this issue as well on OSX Mavericks, with clang 3.4 (with revision c180a66f6edd off branch 1.3)

clang --version Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix

I try to compile with the following commands: mkdir build cd build cmake ../ make

And get the following error:

In file included from /Users/alex.nelson/projects/source/lemon/1.3-c180a66f6edd/tools/lgf-gen.cc:31: In file included from /Applications/Xcode?.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:626: /Applications/Xcode?.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/utility:254:9: error: field has incomplete type '_delaunay_bits::BeachIt?'

_T2 second

...

and many more BeachIt? related errors, which causes the build to fail with:

fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated.

The problem seems to be that BeachIt? is essentially recursively defined, which is not allowed:

​http://stackoverflow.com/questions/6349822/incomplete-type-in-class ​http://clang.llvm.org/compatibility.html#undep_incomplete

[Alpar Juttner]

The situation is a bit more complex. The definition of BeachIt is fine. However BeachIt is and incomplete type when typedef std::multimap<double, BeachIt> SpikeHeap; is declared. This may of may not work depending on the implementation of std::multimap. The OSX/clang std::multimap class implementation seems to depend on the size of BeachIt, while the GCC and Linux/clang ones does not.

[Alpar Juttner]

The changeset [51deaff8728a] in the attached patch​ should solve the problem. Could you please test it on OSX/clang?

[creisle]

I tested it on OSX/Clang and it compiled

[farghen]

I was finally able to get back to this, and tried your patch. It works for me as well.

[Alpar Juttner]

Three changesets related to CLANG compatibility has been merged to branches 1.3 and default:

• [89e1877e335f] is a rebased version of the attached patch​
• [fc35e3ff4bea] sets clang compatible linker flags in Maintainer mode
• [f747a0ddbbf6] removes an unused variable.