[aspect-devel] [deal.II] Re: deal.ii problem during aspect compile, static libs

Tue Jul 1 12:03:42 PDT 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Thorsten,

I don't know if it's the same issue, but when I first installed
deal.II I was having trouble with different build processes using
different default compilers. For some reason cmake was choosing the
wrong one when compiling Trilinos but not deal.II, or something. I
found that specifying the compilers directly in the cmake calls helps.
I ended up saving the following to a script that I can use when I want
to update or reinstall these things. This works for me:

Cheers,
Jonathan

# Build Trilinos
    echo "Building Trilinos"
    tar -C /tmp -xzf $HOME/Downloads/trilinos-11.8.1-Source.tar.gz
    cd /tmp/trilinos-11.8.1-Source
    mkdir build ; cd build
    cmake -D Trilinos_ENABLE_Sacado=ON \
          -D Trilinos_ENABLE_Stratimikos=ON \
          -D CMAKE_BUILD_TYPE=RELEASE \
          -D CMAKE_CXX_FLAGS="-g -O3" \
          -D CMAKE_C_FLAGS="-g -O3" \
          -D CMAKE_FORTRAN_FLAGS="-g -O5" \
          -D Trilinos_EXTRA_LINK_FLAGS="-lgfortran" \
          -D CMAKE_VERBOSE_MAKEFILE=FALSE \
          -D Trilinos_VERBOSE_CONFIGURE=FALSE \
          -D TPL_ENABLE_MPI=ON \
          -D BUILD_SHARED_LIBS=ON \
          -D CMAKE_INSTALL_PREFIX=$TRILINOS_DIR \
          -D CMAKE_C_COMPILER=`which mpicc` \
          -D CMAKE_CXX_COMPILER=`which mpicxx` \
          -D CMAKE_Fortran_COMPILER=`which mpif90` \
          -D MPI_EXEC=`which mpiexec` \
          -D MPI_Fortran_COMPILER=`which mpif90` \
          ..
    make install -j7
    cd ../../ ; rm -rf trilinos-11.8.1-Source*

# Build p4est
    echo "Building p4est"
    mkdir /tmp/p4est-build ; cd /tmp/p4est-build
    wget http://www.p4est.org/tarball/p4est-0.3.4.2.tar.gz
    wget http://www.dealii.org/developer/external-libs/p4est-setup.sh
    chmod +x p4est-setup.sh
    ./p4est-setup.sh p4est-0.3.4.2.tar.gz $P4EST_DIR
    cd ..; rm -rf p4est-build

# Build deal.II development version
    echo "Updating deal.II"
    if [ ! -d $HOME/packages/build ]; then
       mkdir -p $HOME/packages/build
       cd $HOME/packages/build
       svn checkout https://svn.dealii.org/trunk/deal.II
    fi
    cd $HOME/packages/build/deal.II
    svn update
    mkdir /tmp/deal.II-build ; cd /tmp/deal.II-build
    cmake -DDEAL_II_WITH_MPI=ON \
        -DCMAKE_INSTALL_PREFIX=$DEAL_II_DIR \
        -DTRILINOS_DIR=$TRILINOS_DIR \
        -DP4EST_DIR=$P4EST_DIR \
        $HOME/packages/build/deal.II
    make install -j7
    cd .. ; rm -rf /tmp/deal.II-build

On 07/01/2014 11:53 AM, Thorsten Becker wrote:
> Thanks much, Wolfgang and Timo, for your quick reply and comments!
> 
> 
> This all makes sense, but I am not sure if any of it applies for 
> me. I spent a day+ trying to compile shared libraries, that's how
> I ended up with my static attempts. (I should have kept track of
> the shared compilation problems, and might go back and document
> those.) During the whole process, I tried to make sure to have
> "clean" compiles on the same head node, with the same compilers
> and libraries.
> 
> In the end, adding a -DCMAKE_EXE_LINKER_FLAGS="-static" to the deal
> compiled "worked", though now both the test problems and Aspect are
> stuck on something like
> 
> Linking CXX executable aspect 
> /usr/lib/../lib64/libpthread.a(libpthread.o): In function 
> `sem_open': (.text+0x774d): warning: the use of `mktemp' is 
> dangerous, better use `mkstemp' 
> /usr/usc/mpich2/1.5/lib/libmpich.a(simple_pmi.o): In function 
> `PMI_Init': simple_pmi.c:(.text+0xc89): warning: Using 
> 'gethostbyname' in statically linked applications requires at 
> runtime the shared libraries from the glibc v ersion used for 
> linking /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with 
> pointer equality in `/usr/lib/../lib64/libc.a(strcmp.o)' can not
> be used when making an execut able; recompile with -fPIE and
> relink with -pie collect2: error: ld returned 1 exit status
> make[2]: *** [aspect] Error 1 make[1]: ***
> [CMakeFiles/aspect.dir/all] Error 2 make: *** [all] Error 2
> 
> This makes me think that there's still something wrong with the 
> compiler versions, or that the link line doesn't take into account 
> -static. I wonder (and Rene's been giving me good suggestions all 
> along) if I should really heed the -pie advice, or rather try 
> something else?
> 
> Thanks!
> 
> T
> 
> 
> 
> 
> Thorsten W Becker - USC http://geodynamics.usc.edu/~becker
> 
> 
> On Tue, Jul 1, 2014 at 7:59 PM, Timo Heister <heister at clemson.edu 
> <mailto:heister at clemson.edu>> wrote:
> 
> Thorsten,
> 
> two quick comments:
> 
>>> to post. After numerous attempts to compile shared libraries, 
>>> I
> am now
>>> trying static.
> 
> My personal experience is that shared compilation is a lot easier 
> to do.
> 
>> 2/ It finds neither of these libraries because you are on a
> cluster where
>> the frontend node (where we are trying to execute
> 'expand_instantiations')
>> has a different operating system than the compute nodes
> 
> If this is the case you can often configure/compile on a compute 
> node using an interactive session.
> 
> -- Timo Heister http://www.math.clemson.edu/~heister/
> 
> 
> 
> 
> _______________________________________________ Aspect-devel 
> mailing list Aspect-devel at geodynamics.org 
> http://lists.geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTswYNAAoJEGe6xJ1FYRpR0O0IALeNZkAccPXZB16AkuzBNbeJ
ecveihb6w6ZwD7bt8CDweoWIMNlGiHUgHrZ/6u950yf6SNu+oHDz0UepUOJA1FB5
jTb7iWVoH97cCFg50sAjKGyxqyicracDnpmwXOpKJx1zMg553qMLyYAnRkFGGyFD
I1Jd54igmE11vzxg3SeYGkWgjXpYaCr+J7TORWe3D/4UvUW8KCqAc2eIEbbZf/bb
2Yfsay7D/rr0WWFnq4JWR5yGkoPT7JcrUTIgUQQK1DV312VfGQNeyB26qpgpbadE
pLUpv2bwQVp6iJcDhf0zSIgQgjsO1wv5YreJwd+oBQ1WJL0513iwBtIRqe9S2+I=
=rqhs
-----END PGP SIGNATURE-----