Test C++11 builds

Issue #229 resolved
Prof Garth Wells created an issue

Some C++11 features have been dropped into the DOLFIN master branch to test the waters for using C++11 in DOLFIN. The motivation for testing C++11 was put forward in the thread

http://fenicsproject.org/pipermail/fenics/2014-January/001099.html

This Issue to provide a common point to register any problems (and successes) in building DOLFIN with C++11.

If you have a problem building DOLFIN and/or running the demos, please report the compiler, compiler version, Boost version and SWIG version.

Comments (47)

  1. Prof Garth Wells reporter

    @mikael_mortensen Merge in the branch logg/fix-issue-228. It's in next and will move soon to master.

  2. Anders Logg (Chalmers)

    Will that help? That fix is only for compiling demos (it adds the flag DOLFIN_CXX_FLAGS which contains -std=c++11) so it should not affect compile_extension_module in any way.

    On the other hand, is that flag necessary for extension modules if they don't use c++11?

  3. Prof Garth Wells reporter

    @logg -std=c++11 needs to be added if DOLFIN files are included because the flag brings shared_ptr into the std namespace.

    Instant uses CMake, so the CMakle file needs the extra flag.

  4. Anders Logg (Chalmers)

    So instead of the fix I made - which was to add DOLFIN_CXX_FLAGS explicitly in the generated CMakeLists.txt for demos - I should have modified the generation of UseDOLFIN.cmake?

  5. Prof Garth Wells reporter

    @logg I don't recall the details of how Instant uses CMake files, but it should probably use DOLFIN_CXX_FLAGS from DOLFINConfig.cmake.

  6. Mikael Mortensen

    The demo_compiled-extension-module.py does not work for me after merging logg/fix-issue-228. Not sure exactly how instant works, but I get this error in the compile.log

    CMake Error at CMakeLists.txt:10 (INCLUDE):
      include called with wrong number of arguments.  Include only takes one
      file.
    

    and the CMakeLists.txt looks like this

    # Configuration for package DOLFIN
    FIND_PACKAGE(DOLFIN REQUIRED)
    IF(DOLFIN_FOUND)
     INCLUDE(${DOLFIN_USE_FILE})   ## << line 10
    ENDIF(DOLFIN_FOUND)
    

    Is this what you get as well with this demo?

  7. Anders Logg (Chalmers)

    No, that demo actually works for me. Do you have some old lying around that needs to be cleaned out? What's in your share/dolfin/cmake/dolfin-config.cmake?

    I have

    set(DOLFIN_USE_FILE "/home/logg/scratch/src/dolfin/local.master/share/dolfin/cmake/UseDOLFIN.cmake")

  8. Prof Garth Wells reporter

    @mikael_mortensen It looks to me from the CMake files that it should work. Have you run instant-clean?

  9. Anders Logg (Chalmers)

    Good to hear. I've started to sneak in other useful things from c++-11. std::tuple / bind are very useful.

  10. Corrado Maurini

    Building on macosx 10.9 with clang-500.2.79, swig-2.0.11, and boost 1.55 (build with homebrew with options --without-single, --with-mpi)

    I get this error when compiling latest version of dolfin

    /dolfin/dorsal_build_dir/dolfin/swig/modules/mesh/modulePYTHON_wrap.cxx:2963:51: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
      "in method '" name"', argument "argn" of type '"type"'
    

    I suppose it is related to this thread. Suggestions about how to solve?

  11. Johan Hake

    @corrado I suspect this is a SWIG bug. I have also seen this bug with clang. It is also present for development version of SWIG. As a workaround I think we can add a compiler flag to turn the error into a warning.

  12. Prof Garth Wells reporter

    @cmaurini Strange - I have the same configuration but I don't get any warnings or errors. Did you clean everything out (git clean -fdx)?

  13. Corrado Maurini

    Yes, more precisely I removed the dolfin dir and downloaded again. I also run instant-clean. Is that enough?

  14. Corrado Maurini

    @johanhake Do you have any specific suggestion about the compiler flag that could I try to use?

  15. Johan Hake

    From the error message it looks like the error can be turned into a warning using:

    -Wreserved-user-defined-literal
    

    When compiling the SWIG extension module we have turned of -Wall and -Werror so any warnings should just be warnings and not errors.

  16. Martin Sandve Alnæs

    How much do I need to rebuild?

    /home/martinal/opt/fenics/dorsal-unstable/include/CGAL/Lazy.h:831:4268: note: template argument deduction/substitution failed: In file included from /home/martinal/opt/fenics/dorsal-unstable/include/CGAL/Mesh_triangulation_3.h:29:0, from /home/martinal/dev/fenics/dolfin/dolfin/generation/PolyhedralMeshGenerator.cpp:27: /home/martinal/opt/fenics/dorsal-unstable/include/CGAL/Mesh_3/Robust_weighted_circumcenter_filtered_traits_3.h:109:55: note: candidate expects 5 arguments, 4 provided to_exact(s)));

  17. Johannes Ring

    This has broken the build on the osx-10.7 buildbot. The GCC version is 4.2.1. I can update the buildbot to use a later version of GCC from MacPorts, however, we can no longer provide binary packages for 10.7.

  18. Prof Garth Wells reporter

    I don't think we need to worry about OSX 10.7 - the demand is for OSX 10.9.

    I believe there is a trick to get it working on OSX 10.7. When I checked a few days back, apparently 10.7 is screwed up with respect to which standard library gcc uses on 10.7, but this can be tweaked on the command line.

  19. Johan Hake

    Ok after some hours of debugging me and @peppu found the source for the error we and @cmaurini is having. It is not code generated by SWIG that triggers the error but code inserted by petsc4py through the petsc4py.i file.

    I will file a bug report to petsc4py and another here for reference.

  20. Geoff Oxberry

    Compiling from Dorsal failed on OS X 10.8.5 with Homebrew, Apple LLVM 5.1 (clang-503.0.38, based on LLVM 3.4svn), SWIG 2.0.12, Boost 1.51 (included via Dorsal), and DOLFIN https://bitbucket.org/fenics-project/dolfin/commits/fbe73cf4802106a04e95229afe15dcbdf83236c6. (Also reported in http://fenicsproject.org/pipermail/fenics-support/2014-March/000436.html.)

    All errors during DOLFIN and FFC compiling were related to std::shared_ptr. I could squelch the compile-time errors by kludging in the -stdlib=libc++ flag into Dorsal, but then the compiler threw errors during linking due to problems mixing libstdc++ and libc++. Mass-replacing std::shared_ptr with boost::shared_ptr in the C++ source and hacking the SWIG interface files to use boost::shared_ptr instead of std::shared_ptr seemed to silence all of the shared_ptr errors and linking problems in FFC, but in compiling DOLFIN, clang++ then threw compile-time errors because it could not find the file type_traits.

    This build is on a work laptop, so upgrading the OS to 10.9.2 isn't an option at present.

  21. Corrado Maurini

    I am trying to compile on a large shared memory machine with intel13 compilers and mpt (sgi) as mpi. Among the several problems, I have a series of errors as the following when compiling dolfin:

    /home/maurini/share/src/FEniCS/dolfin/dolfin/io/File.h(269): error: qualified name is not allowed
          std::unique_ptr<GenericFile> file;
          ^
    
    /home/maurini/share/src/FEniCS/dolfin/dolfin/io/File.h(269): error #77: this declaration has no storage class or type specifier
          std::unique_ptr<GenericFile> file;
          ^
    
    /home/maurini/share/src/FEniCS/dolfin/dolfin/io/File.h(269): error: expected a ";"
          std::unique_ptr<GenericFile> file;
                         ^
    
    /home/maurini/share/src/FEniCS/dolfin/dolfin/adaptivity/ErrorControl.cpp(479): error: namespace "std" has no member "unique_ptr"
          std::unique_ptr<DirichletBC> e_bc;
    

    I imagine it is related to c++11 pointers. Any idea how to solve it? Has anyone tested with intel14?

  22. Prof Garth Wells reporter

    @cmaurini I've tested with Intel 14. It works fine, but there is an issue with Boost 1.55 + Intel 14 (Boost 1.54 is ok).

    I have previously used Intel v13 compilers without problems.

  23. Lizao Li

    I tried to compile FEniCS with gcc 4.9 (now default on Archlinux), which seems to be more strict about c++11 rules. It turns out that SWIG is a bottleneck. The old SWIG up to 2.0.8 is not c++11 compliant. All parts of FEniCS (without any solver) compile and work with SWIG 3.0.0 (which is c++11 compliant) and gcc 4.9. But the picture with the solvers is not good. The newest Trilinos, version 11.8, still only supports SWIG <= 2.0.8. If dolfin has PETSc and petsc4py enabled, then it fails to compile. Tons of error messages of the type:

    fenics-test/src/dolfin/dorsal_build_dir/dolfin/swig/modules/mesh/modulePYTHON_wrap.cxx:2963:55: error: unable to find string literal operator ‘operator""argn’
       "in method '" name"', argument "argn" of type '"type"'"
    

    I am not sure if there is an easy fix for this. I had to downgrade gcc to get things to work.

  24. Prof Garth Wells reporter

    @lzlarryli If Trilinos and petsc4py need fixing, report the issues to the developers. It is much more efficient/effective to fix upstream projects rather than to work around their deficiencies. The petsc4py developers in particular have been responsive to fixes.

  25. Lizao Li

    @garth-wells Thank you for the response. I found the solution now. I was too eager to try the newer SWIG. Actually the old SWIG 2.0.8 with the patch by @johanhake (https://bitbucket.org/petsc/petsc4py/issue/3) works just fine. I can confirm on Archlinux with GCC4.9 c++11, FEniCS with both Trilinos and PETSc compiles and runs smoothly.

  26. Lizao Li

    @johanhake I made some minimal changes in dorsal to use the git version of petsc4py. It did not compile. The dev version seems to assume TAO is installed and I did not find a simple switch to turn that off. I did not find a TAO package file in dorsal and am not familiar with it. In any case, it seems the patch which solved the SWIG problem was added to the dev branch of petsc4py since Feb 9. So that part should be fine.

  27. Sean Farley

    @lzlarryli Did you actually get this to work with swig 3.0? I still end up with boost::shared_ptr in the generated cxx files. Even if I search / replace them, I get many errors of missing members of a namespace:

    /Users/sean/sandbox/dolfin/build/dolfin/swig/modules/common/modulePYTHON_wrap.cxx:4881:30: error: no member named 'has_tao' in namespace 'dolfin'
          result = (bool)dolfin::has_tao();
    
    /Users/sean/sandbox/dolfin/build/dolfin/swig/modules/common/modulePYTHON_wrap.cxx:6453:11: error: no type named 'MPICommunicator' in namespace 'dolfin'
      dolfin::MPICommunicator *result = 0 ;
    
  28. Lizao Li

    @seanfarley I got everything to work with SWIG 2.0.8. As @johanhake pointed out, your problem might be resolved by using the branch

    git checkout 2dffbbc88844d69580258d9a372bd8f411609a7a -b after-std11-fix
    

    which is taken after the c11 part was fixed but before the tao part was added. I did not try SWIG 3.0.0 afterwards because the current PyTrilinos only support SWIG <= 2.0.8.

  29. Sean Farley

    That's for using petsc4py which I'm not using. In fact, I'm not using petsc nor trilinos at all.

  30. Log in to comment