On Monday November 7 2011 13:51:46 Garth Wells wrote:
> On 7 November 2011 21:28, Johan Hake <email address hidden> wrote:
> > On Monday November 7 2011 13:10:35 Garth Wells wrote:
> >> Public bug reported:
> >>
> >> The flags used in JIT are a mess. I'm seeing this first-hand when using
> >> specialised BLAS. The full lib path is not being used.
> >>
> >> ** Affects: dolfin
> >> Importance: Undecided
> >> Status: New
> >
> > Could you please hand a more descriptive report? What are you doing and
> > what are you expecting JIT to do. Can now the generated ufc module be
> > dependent on blas?
>
> No. But JIT throes in the blas libs without providing the path to the
> lib.
So you are refering to the dolfin extension modules (expressions,
compile_subdomains) not ufc extension modules (from ufl forms)?
> Here is just some of the junk used during JIT:
>
> -ldl -lm -lutil -lnsl -lopen-pal -lopen-rte -lmpi -lmpi_cxx -lcppunit
> -lhdf5 -lz -lboost_thread-mt -lgmp -lmpfr -lgmpxx -lCGAL -lmetis
> -lparmetis -lptscotcherr -lptscotch -latlas.3gf -lf77blas.3gf
> -lcblas.3gf -llapack.3gf -lccolamd -lcolamd -lcamd -lamd -lcholmod
> -lumfpack -lpetsc -lslepc -lteuchos -ltpi -lsacado -lrtop -lkokkos
> -lkokkosnodeapi -lkokkoslinalg -lepetra -lzoltan -lshards -lglobipack
> -ltriutils -ltpetra -ltpetrainout -ltpetraext -lepetraext -lthyracore
> -lthyraepetra -lthyraepetraext -lthyratpetra -lthyra -loptipack
> -lisorropia -ldpliris -laztecoo -lgaleri -lamesos -lpamgen
> -lpamgen_extras -lifpack -lkomplex -lml -lbelos -lbelosepetra
> -lbelostpetra -lifpack2 -lstratimikosifpack -lstratimikosml
> -lstratimikosamesos -lstratimikosaztecoo -lstratimikosbelos
> -lstratimikos -lfei_base -lfei_trilinos -lanasazi -lanasaziepetra
> -lModeLaplace -lanasazitpetra -lintrepid -lnox -lnoxepetra -lnoxthyra
> -lloca -llocaepetra -llocathyra -lmoertel -lrythmos -lmoocho
> -lmoochothyra -lmesquite -lboost_serialization-mt -lboost_mpi-mt
> -lboost_math_tr1-mt -lboost_iostreams-mt -lboost_system-mt
> -lboost_program_options-mt -lboost_filesystem-mt -larmadillo -ldolfin
> -lxml2
>
> A problem is that Cmake allows C++ code to run with libs that are not
> in LD_LIBRARY_PATH by using the full path, but JIT is getting flags
> from somewhere but using the full path.
jit compilation of dolfin extension modules get the dolfin flags from pkg-
config. Everything that is in dolfin.pc gets included in the appropriate
flags. If the path to the blas library was included there it should just work.
> JIT should either use all DOLFIN flags, but done properly (i.e. not
> with pkg-config), or with a bare minimum of libs.
Any suggestion on how this can be done properly? CMake lack a good way to get
the flags from the command prompt, and hence from within instant. Here pkg-
config is nice.
What is problematic with pkg-config? Sure it is not the generation of the pkg-
config file that is flawed?
On Monday November 7 2011 13:51:46 Garth Wells wrote:
> On 7 November 2011 21:28, Johan Hake <email address hidden> wrote:
> > On Monday November 7 2011 13:10:35 Garth Wells wrote:
> >> Public bug reported:
> >>
> >> The flags used in JIT are a mess. I'm seeing this first-hand when using
> >> specialised BLAS. The full lib path is not being used.
> >>
> >> ** Affects: dolfin
> >> Importance: Undecided
> >> Status: New
> >
> > Could you please hand a more descriptive report? What are you doing and
> > what are you expecting JIT to do. Can now the generated ufc module be
> > dependent on blas?
>
> No. But JIT throes in the blas libs without providing the path to the
> lib.
So you are refering to the dolfin extension modules (expressions,
compile_subdomains) not ufc extension modules (from ufl forms)?
> Here is just some of the junk used during JIT: tecoo -lstratimikosbelos serialization- mt -lboost_mpi-mt iostreams- mt -lboost_system-mt program_ options- mt -lboost_ filesystem- mt -larmadillo -ldolfin
>
> -ldl -lm -lutil -lnsl -lopen-pal -lopen-rte -lmpi -lmpi_cxx -lcppunit
> -lhdf5 -lz -lboost_thread-mt -lgmp -lmpfr -lgmpxx -lCGAL -lmetis
> -lparmetis -lptscotcherr -lptscotch -latlas.3gf -lf77blas.3gf
> -lcblas.3gf -llapack.3gf -lccolamd -lcolamd -lcamd -lamd -lcholmod
> -lumfpack -lpetsc -lslepc -lteuchos -ltpi -lsacado -lrtop -lkokkos
> -lkokkosnodeapi -lkokkoslinalg -lepetra -lzoltan -lshards -lglobipack
> -ltriutils -ltpetra -ltpetrainout -ltpetraext -lepetraext -lthyracore
> -lthyraepetra -lthyraepetraext -lthyratpetra -lthyra -loptipack
> -lisorropia -ldpliris -laztecoo -lgaleri -lamesos -lpamgen
> -lpamgen_extras -lifpack -lkomplex -lml -lbelos -lbelosepetra
> -lbelostpetra -lifpack2 -lstratimikosifpack -lstratimikosml
> -lstratimikosamesos -lstratimikosaz
> -lstratimikos -lfei_base -lfei_trilinos -lanasazi -lanasaziepetra
> -lModeLaplace -lanasazitpetra -lintrepid -lnox -lnoxepetra -lnoxthyra
> -lloca -llocaepetra -llocathyra -lmoertel -lrythmos -lmoocho
> -lmoochothyra -lmesquite -lboost_
> -lboost_math_tr1-mt -lboost_
> -lboost_
> -lxml2
>
> A problem is that Cmake allows C++ code to run with libs that are not
> in LD_LIBRARY_PATH by using the full path, but JIT is getting flags
> from somewhere but using the full path.
jit compilation of dolfin extension modules get the dolfin flags from pkg-
config. Everything that is in dolfin.pc gets included in the appropriate
flags. If the path to the blas library was included there it should just work.
> JIT should either use all DOLFIN flags, but done properly (i.e. not
> with pkg-config), or with a bare minimum of libs.
Any suggestion on how this can be done properly? CMake lack a good way to get
the flags from the command prompt, and hence from within instant. Here pkg-
config is nice.
What is problematic with pkg-config? Sure it is not the generation of the pkg-
config file that is flawed?
Johan
> Garth /bugs.launchpad .net/bugs/ 887324 /bugs.launchpad .net/dolfin/ +bug/887324/ +subscriptions
>
> > Johan
> >
> > --
> > You received this bug notification because you are a member of DOLFIN
> > Core Team, which is subscribed to DOLFIN.
> > https:/
> >
> > Title:
> > JIT should be given/use proper flags
> >
> > To manage notifications about this bug go to:
> > https:/