DOLFIN

Bug #882560
Comment #11

Comment 11 for bug 882560

Revision history for this message

Johan Hake (johan-hake) wrote on 2011-10-28: Re: [Bug 882560] Re: tr1::cyl_bessel_* functions are not found at linking stage of jit

#11

On Friday October 28 2011 02:37:34 Kristian B. Ølgaard wrote:
> On 28 October 2011 01:03, Johan Hake <email address hidden> wrote:
> > 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.
>
> There are no shared_ptr in ufc.h, but I guess you're talking about the
> swig generated modules?

Yes, and the decission of letting ufc handle its own JIT compilation made it
important to have a configure step where we found boost.

> >> 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.
>
> No, but what should happen when 'ffc -l dolfin foo.ufl' is used? Then
> the output is wrapped for DOLFIN and it would be natural to use the
> DOLFIN flags. If, on the other hand, pure UFC is generated and the
> presence of bessel functions demand the boost_math_tr library, we
> should get the flags directly from FFC. We can't get the flags from
> UFC, as UFC cannot know which libraries the form compilers might need
> for their code.

Sure, but my point is that ufc should provide all possible libraries a form
compiler can use.

> But for now, it will be simpler to require users to supply a list of
> libraries, when needed, using the parameter system in FFC.
> This will only be needed for the Python interface, and users can
> decide for themselves if they will use 'libboost_math_tr1-mt.so' or
> 'libboost_math_tr1.so'.

Why is this only needed for the Python compilation? If nost_math is included
in DOLFIN now we have to include any "exotic" libraries in the future to
DOLFIN too.

> >> 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.
>
> Yes, this will be the simplest solution, but it means that whenever a
> random form compiler decides to implement e.g., the dof evaluation by
> calling some exotic library, we have to update UFC to use that
> library, while most other form compilers will generate code which
> doesn't need it.

Would this be a problem? In a way this is what we do in compile_expressions.
Here we make cmath functions and also complex expression available. I see that
this might constrain the user.

Johan

> Kristian
>
> > 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/d003d0ea29ed9346265963000f1
> >> > a90 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
> >
> > --
> > 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

On Friday October 28 2011 02:37:34 Kristian B. Ølgaard wrote:
> On 28 October 2011 01:03, Johan Hake <882560@bugs.launchpad.net> wrote:
> > On Thursday October 27 2011 12:02:35 Kristian B. Ølgaard wrote:
> >> On 27 October 2011 19:38, Johan Hake <882560@bugs.launchpad.net> 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.
> 
> There are no shared_ptr in ufc.h, but I guess you're talking about the
> swig generated modules?

Yes, and the decission of letting ufc handle its own JIT compilation made it 
important to have a configure step where we found boost.
 
> >> 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.
> 
> No, but what should happen when 'ffc -l dolfin foo.ufl' is used? Then
> the output is wrapped for DOLFIN and it would be natural to use the
> DOLFIN flags. If, on the other hand, pure UFC is generated and the
> presence of bessel functions demand the boost_math_tr library, we
> should get the flags directly from FFC. We can't get the flags from
> UFC, as UFC cannot know which libraries the form compilers might need
> for their code.

Sure, but my point is that ufc should provide all possible libraries a form 
compiler can use.

Why is this only needed for the Python compilation? If nost_math is included 
in DOLFIN now we have to include any "exotic" libraries in the future to 
DOLFIN too.

> >> 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.
> 
> Yes, this will be the simplest solution, but it means that whenever a
> random form compiler decides to implement e.g., the dof evaluation by
> calling some exotic library, we have to update UFC to use that
> library, while most other form compilers will generate code which
> doesn't need it.

Would this be a problem? In a way this is what we do in compile_expressions. 
Here we make cmath functions and also complex expression available. I see that 
this might constrain the user.

Johan

> Kristian
> 
> > 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/d003d0ea29ed9346265963000f1
> >> > a90 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
> > 
> > --
> > 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