- edited description
Test C++11 builds
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)
-
reporter -
reporter - edited description
-
Working flawlessly for me, but note this fix necessary to get demos and binaries depending on DOLFIN to build: https://bitbucket.org/fenics-project/dolfin/issue/228
-
How can this CMAKE_CXX_FLAG be added to instant or compile_extension_module?
-
reporter @mikael_mortensen Merge in the branch
logg/fix-issue-228
. It's innext
and will move soon tomaster
. -
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?
-
reporter @logg -std=c++11 needs to be added if DOLFIN files are included because the flag brings
shared_ptr
into thestd
namespace.Instant uses CMake, so the CMakle file needs the extra flag.
-
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?
-
reporter @logg I don't recall the details of how Instant uses CMake files, but it should probably use
DOLFIN_CXX_FLAGS
fromDOLFINConfig.cmake
. -
The
demo_compiled-extension-module.py
does not work for me after merginglogg/fix-issue-228
. Not sure exactly howinstant
works, but I get this error in thecompile.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?
-
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")
-
Ok, I have nothing there. I'll clean out everything and try again.
-
reporter @mikael_mortensen It looks to me from the CMake files that it should work. Have you run instant-clean?
-
just did
git clean -df
, so I'll get back to you. -
Ok, it works. Sorry about that.
-
Worked fine for me (OSX 10.9, clang 5.0.0)
Dave
-
Good to hear. I've started to sneak in other useful things from c++-11. std::tuple / bind are very useful.
-
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?
-
@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.
-
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)?
-
Yes, more precisely I removed the dolfin dir and downloaded again. I also run instant-clean. Is that enough?
-
@johanhake Do you have any specific suggestion about the compiler flag that could I try to use?
-
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.
-
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)));
-
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.
-
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.
-
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 bypetsc4py
through thepetsc4py.i
file.I will file a bug report to
petsc4py
and another here for reference. -
reporter @johanhake Looks like the same problem @pefarrell had (https://bitbucket.org/fenics-project/dolfin/commits/d0a93899236e6e5aff6a9dae6cd27c32ca08e533).
-
Yes I think you are correct @garth-wells.
-
I confirm I compile dolfin with petsc4py support. Thanks.
-
petsc4py issue and patch posted by @johanhake
https://bitbucket.org/petsc/petsc4py/issue/3/petsc4pyi-is-emitting-wrapper-code-that
-
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.
-
I am trying to compile on a large shared memory machine with
intel13
compilers andmpt
(sgi) as mpi. Among the several problems, I have a series of errors as the following when compilingdolfin
:/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? -
reporter - changed milestone to 1.4
-
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.
-
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.
-
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.
-
@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.
-
Have you tried with dev version of petsc4py?
Johan
-
@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.
-
@lzlarryli I have encountered the same problem with petsc4py. It follows petsc-dev, which no incorporates TAO. You can just check out a branch of petsc4py including the fix:
git checkout 2dffbbc88844d69580258d9a372bd8f411609a7a -b after-std11-fix
and install it.
-
@johanhake I confirm that the branch "after-std11-fix" works. Thank you very much~
-
reporter - changed status to resolved
This seems to be in pretty good shape now, so I'm closing the Issue.
-
@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 ;
-
@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.
-
That's for using petsc4py which I'm not using. In fact, I'm not using petsc nor trilinos at all.
-
reporter - removed milestone
Removing milestone: 1.4 (automated comment)
- Log in to comment