DOLFIN

Bug #882560
Comment #12

Comment 12 for bug 882560

Revision history for this message

Martin Sandve Alnæs (martinal) wrote on 2011-10-28: Re: [Bug 882560] Re: tr1::cyl_bessel_* functions are not found at linking stage of jit

#12

Just a few quick comments here:

cmath is fully standard, which makes it not comparable to boost math for
these issues.

The issue is mainly from python because from C++ there will be a build
system to handle libraries.

I think boost math is comparable to boost shared_ptr, in fact they are both
tr1 and light weight. Configuring one more boost library in ufc would not be
so bad.

But it is more robust if it is optional and not linked with unless needed.

Martin
Den 28. okt. 2011 17.41 skrev "Johan Hake" <email address hidden>
følgende:

> 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
>
> --
> 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/d003d0ea29ed9346265963000f1a90648953f6a6/_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
>

Just a few quick comments here:

cmath is fully standard, which makes it not comparable to boost math for
these issues.

The issue is mainly from python because from C++ there will be a build
system to handle libraries.

I think boost math is comparable to boost shared_ptr, in fact they are both
tr1 and light weight. Configuring one more boost library in ufc would not be
so bad.

But it is more robust if it is optional and not linked with unless needed.

Martin
Den 28. okt. 2011 17.41 skrev "Johan Hake" <882560@bugs.launchpad.net>
følgende:

> 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.
>
> > 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
>
> --
> 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/d003d0ea29ed9346265963000f1a90648953f6a6/_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
>