On Thursday October 27 2011 12:02:35 Kristian B. Ølgaard wrote:
> On 27 October 2011 19:38, Johan Hake <email address hidden> wrote:
> > On Thursday October 27 2011 10:25:22 Garth Wells wrote:
> >> I don't think that it's a fix. We need to search for right library. It
> >> may be in a non-standard location, and in my case it should link to
> 
> It was just meant as a pointer to where the problem lies, not a proper
> fix.
> 
> >>     libboost_math_tr1-mt.so
> >> 
> >> and not
> >> 
> >>     libboost_math_tr1.so
> >> 
> >> Perhaps UFC should supply the build flags?
> 
> That could work for this case, but since UFC is not concerned about
> how the functions are implemented it seems more natural that the form
> compiler supplies the additional flags needed for the generated code.

Sure, but we actually moved from a situation where the actuall compilation 
were done in FFC to UFC. It simplified the interface to the JIT compilations 
alot. 

> > There are already logic in the building of extension modules to find the
> > boost libraries, or more precise the boost header for shared_ptr. So it
> > is not unatural to add logic for finding the correct boost math library.
> 
> But should it be? shared_ptr is not used in native UFC AFAIK, it is
> used for the DOLFIN wrapper code generated by FFC which again suggests
> that FFC supplies the additional flags.

Well, it provides a shared_ptr interface of UFC objects. DOLFIN depends on 
this but it is not tied to DOLFIN per se. Other programs can use this wrapper 
to include UFC modules.

> So with this argument, FFC could use the DOLFIN configuration to get
> the correct include dirs and libraries?

I think FFC generated UFC code should not have to depend on DOLFIN flags. The 
most natural thing is to include the flags in a UFCCmake/pkg-config file I 
guess. Unfortunatly this will give us the libs each time also when we do not 
use them. Not sure this is a problem though.

> If FFC is used from the command line to generate a header file which
> is included in a DOLFIN program, I would expect Garth's fix to work
> for the C++ version.

That is true. But ufc code should be able to be integrated with any software, 
and optimally it should be self contained. But introducing boost dependencies 
we drop that.

For a cleaner dependency chain I suggest UFC provide everything it needs to 
compile UFC code (and python extensions) and then form compilers have to limit 
them self to what UFC provides. Whenever a formcompiler want something new and 
fancy we need to update UFC to make that happen.

Johan

> Kristian
> 
> > What do you mean with UFC supply build flags?
> > 
> > Johan
> > 
> >> Garth
> > 
> > --
> > You received this bug notification because you are a member of DOLFIN
> > Core Team, which is subscribed to DOLFIN.
> > https://bugs.launchpad.net/bugs/882560
> > 
> > Title:
> >  tr1::cyl_bessel_* functions are not found at linking stage of jit
> > 
> > Status in DOLFIN:
> >  Confirmed
> > 
> > Bug description:
> >  When a jit compiled module using bessel functions is imported into
> >  python, it fails with an undefined symbol error. Probably because the
> >  boost math tr1 library is not linked in.
> > 
> >  ImportError:/home/martinal/.instant/cache/d003d0ea29ed9346265963000f1a90
> > 648953f6a6/_d003d0ea29ed9346265963000f1a90648953f6a6.so: undefined
> > symbol: boost_cyl_bessel_j;
> > 
> > 
> >  Code to reproduce:
> > 
> >  from dolfin import *
> >  mesh = Interval(10, 0.1, 2.0)
> >  V = FunctionSpace(mesh, "CG", 1)
> >  x = interval.x
> >  f = bessel_J(0, x)
> >  g = project(f, V)
> >  plot(g, mesh=mesh)
> >  interactive()
> > 
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/dolfin/+bug/882560/+subscriptions