Oh, by the way, I forgot to mention: this build is with development versions of packages, rather than the stable package versions.
Cheers, Geoff On Sun, Mar 30, 2014 at 1:07 AM, Geoff Oxberry <[email protected]> wrote: > Garth, > > Here's more progress: now FEniCS builds. I have to build quite a bit with > GCC 4.8; I've attached the local.platform file I've been using, which is by > no means minimal. There are a few Dorsal packages for which I've written > custom package files, and I've updated 8 or 9 more. Once I figure all of > this out, I'll submit pull requests to upstream. > > I figured out that GCC 4.8 is used consistently, provided I make sure to > clean up previous builds by deleting the FEniCS build directory. The only > other exception is PETSc, which still uses Clang++ for some reason, and > I'll have to figure that out later. > > Now, when I run demo_poisson.py, I get the following run-time error: > > ratatoskr:~ goxberry$ env CXX=g++-4.8 python > FEniCS/src/dolfin/demo/documented/poisson/python/demo_poisson.py > Calling FFC just-in-time (JIT) compiler, this may take some time. > Calling DOLFIN just-in-time (JIT) compiler, this may take some time. > Calling DOLFIN just-in-time (JIT) compiler, this may take some time. > Calling FFC just-in-time (JIT) compiler, this may take some time. > Calling FFC just-in-time (JIT) compiler, this may take some time. > Solving linear variational problem. > python(18194,0x7fff7c323180) malloc: *** error for object 0x7fff7bc60570: > pointer being freed was not allocated > *** set a breakpoint in malloc_error_break to debug > [ratatoskr:18194] *** Process received signal *** > [ratatoskr:18194] Signal: Abort trap: 6 (6) > [ratatoskr:18194] Signal code: (0) > [ratatoskr:18194] *** End of error message *** > Abort trap: 6 > > The Dorsal platform file is attached; of particular note is that I build a > Python 2.7.2 interpreter through Dorsal (the python-osx package is a minor > hack that sets PYTHON_LIBRARY to have a .dylib extension instead of an .so > extension). Any ideas of what I may want to look at for debugging? > > Cheers, > > Geoff > > > On Fri, Mar 28, 2014 at 10:45 AM, Geoff Oxberry <[email protected]>wrote: > >> Garth, >> >> Thank you for the reply. I wish I could upgrade, but for the time being, >> work policy is to use 10.8.5. >> >> One potential fix is to use Dorsal to build enough dependencies of >> FEniCS-dev with g++ 4.8, which will use the right standard library, and >> should be able to link to existing software on my machine built with >> clang++ and libstdc++. >> >> What I've done so far is: >> >> - built a separate Python 2.7 virtualenv via gcc 4.8, so pip & setup.py >> should preferentially use GCC 4.8 for building Python packages. Compile >> logs for packages installed via pip indicate that this premise has borne >> out so far >> - set environment variables in a local.platform file for Dorsal so that: >> CC and CXX equal gcc-4.8 and g++4.8, respectively. I've also set >> OMPI_CC=gcc-4.8, OMPI_CXX=g++-4.8, and OMPI_FC=gfortran, as in the >> mountainlion.platform file set up in Dorsal. >> - I make Dorsal build many dependencies, notably: Open MPI, and anything >> that looks like it will use an MPI wrapper compiler (boost, parmetis, >> mpi4py, petsc, petsc4py, slepc, scotch). >> - Then it should build FEniCS-dev. >> >> Where I get stuck is that it seems that Dorsal uses GCC 4.8 >> inconsistently -- possibly not at all -- in the build process, because I'm >> still getting clang errors re: shared_ptr. The theory behind having Dorsal >> build Open MPI, etc., is that it will use libraries it builds >> preferentially, and will sandbox the installs, so building Open MPI via >> Dorsal should build an Open MPI wrapper compiler for GCC 4.8 localized to >> FEniCS. I would rather avoid building libraries by hand, or using Homebrew >> to build libraries using GCC 4.8, if possible. >> >> Any help on getting Dorsal to recognize the right compiler or correct my >> misunderstandings so far would be much appreciated. >> >> Cheers, >> >> Geoff >> >> >> On Fri, Mar 28, 2014 at 5:29 AM, Garth N. Wells <[email protected]> wrote: >> >>> >>> On 26 Mar 2014, at 08:55, Geoff Oxberry <[email protected]> wrote: >>> >>> > I have a similar error to a user who wrote in 2014-03-03 (see >>> https://www.mail-archive.com/[email protected]/msg00366.html >>> ): >>> > >>> > Traceback (most recent call last): >>> > File "demo_poisson.py", line 41, in <module> >>> > V = FunctionSpace(mesh, "Lagrange", 1) >>> > File >>> "~/FEniCS/lib/python2.7/dist-packages/dolfin/functions/functionspace.py", >>> > line 403, in __init__ >>> > FunctionSpaceBase.__init__(self, mesh, element, constrained_domain) >>> > File " >>> > >>> ~/FEniCS/lib/python2.7/dist-packages/dolfin/functions/functionspace.py", >>> > >>> > line 84, in __init__ >>> > ufc_element, ufc_dofmap = jit(self._ufl_element) >>> > File " >>> > ~/FEniCS/lib/python2.7/dist-packages/dolfin/compilemodules/jit.py", >>> line >>> > >>> > 60, in mpi_jit >>> > return local_jit(*args, **kwargs) >>> > File " >>> > ~/FEniCS/lib/python2.7/dist-packages/dolfin/compilemodules/jit.py", >>> line >>> > >>> > 122, in jit >>> > return jit_compile(form, parameters=p, common_cell=common_cell) >>> > TypeError: jit() got an unexpected keyword argument 'common_cell' >>> > >>> > >>> > In the same thread, Anders Logg suggested updating DOLFIN, UFL, and >>> FFC. I installed everything through Dorsal; to my knowledge, each package >>> is at the most recent stable version. If you let me know which files to >>> send, I can send build logs. >>> > >>> > I've also tried using Dorsal to build the development versions of >>> these packages. On OS X with Homebrew and LLVM 3.3, there seems to be an >>> issue with the development version of FFC; clang++ throws a number of >>> errors related to std::shared_ptr (in SWIG-generated interfaces) that have >>> to do with the version of libstdc++ clang++ is using. If I compile and link >>> with libc++ instead, those problems go away, but linking errors occur (with >>> Boost; rebuilding Boost with libc++ does not seem to work either). >>> > >>> > Are there other ways to resolve this problem while still building with >>> Homebrew? >>> > >>> >>> I don't think any developers use (or have access to) OS X 10.8, so it >>> all be hard for us to fix. I build the FEniCS dev versions on OSX 10.9 with >>> Xcode 5.1 without problems. I install via Homebrew all the dependencies >>> that are available in Homebrew, except PETSc which I choose to build myself. >>> >>> Garth >>> >>> >>> > Cheers, >>> > >>> > Geoff >>> > _______________________________________________ >>> > fenics-support mailing list >>> > [email protected] >>> > http://fenicsproject.org/mailman/listinfo/fenics-support >>> >>> >> >> >> -- >> Geoffrey Oxberry, Ph.D., E.I.T. >> [email protected] >> > > > > -- > Geoffrey Oxberry, Ph.D., E.I.T. > [email protected] > -- Geoffrey Oxberry, Ph.D., E.I.T. [email protected]
_______________________________________________ fenics-support mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics-support
