tr1::cyl_bessel_* functions are not found at linking stage of jit

[Martin Sandve Alnæs]

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()

[Garth Wells (garth-wells)]

I've added the math library to DOLFIN, but it doesn't seem to help. Perhaps Instant is not taking the flags from DOLFIN?

[Kristian B. Ølgaard (k.b.oelgaard)]

On 27 October 2011 15:50, Garth Wells <email address hidden> wrote:
> I've added the math library to DOLFIN, but it doesn't seem to help.
> Perhaps Instant is not taking the flags from DOLFIN?

It looks like FFC.Jit calls instant through UFC passing only a few arguments.
Adding the line:

            libraries=["boost_math_tr1"])

to the call to

module = ufc_utils.build_ufc_module(

in jit_form() seems to do the trick.

The question is if we should ask users to set this manually through
the parameter system like 'cpp_optimize'?

> ** Changed in: dolfin
>       Status: New => Confirmed
>
> --
> 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
>

[Johan Hake (johan-hake)]

We have discussed this before and I remember someone(TM) did not want to make compiling of UFC modules dependent on DOLFIN. I think that is a good choice and that Kristian's fix is what we should go with. Isn't UFC modules already dependent on cmath?

Johan

On Oct 27, 2011, at 7:08, Kristian B. Ølgaard <email address hidden> wrote:

> On 27 October 2011 15:50, Garth Wells <email address hidden> wrote:
>> I've added the math library to DOLFIN, but it doesn't seem to help.
>> Perhaps Instant is not taking the flags from DOLFIN?
>
> It looks like FFC.Jit calls instant through UFC passing only a few arguments.
> Adding the line:
>
> libraries=["boost_math_tr1"])
>
> to the call to
>
> module = ufc_utils.build_ufc_module(
>
> in jit_form() seems to do the trick.
>
> The question is if we should ask users to set this manually through
> the parameter system like 'cpp_optimize'?
>
>
>> ** Changed in: dolfin
>> Status: New => Confirmed
>>
>> --
>> 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
>>
>
> --
> 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

[Garth Wells (garth-wells)]

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

    libboost_math_tr1-mt.so

and not

    libboost_math_tr1.so

Perhaps UFC should supply the build flags?

Garth

[Johan Hake (johan-hake)]

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
>
> libboost_math_tr1-mt.so
>
> and not
>
> libboost_math_tr1.so
>
> Perhaps UFC should supply the build flags?

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.

What do you mean with UFC supply build flags?

Johan

> Garth

[Garth Wells (garth-wells)]

Instant needs to get the compiler flags from somewhere. They could come from DOLFIN, e.g. via dolfin.pc, or from UFC, e.g. via ufc.pc or UFCConfig.cmake.

[Kristian B. Ølgaard (k.b.oelgaard)]

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.

> 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.

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

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.

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

[Johan Hake (johan-hake)]

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.
> >...

[Martin Sandve Alnæs (martinal)]

On 27 October 2011 17:06, Johan Hake <email address hidden> wrote:
> We have discussed this before and I remember someone(TM) did not want to
> make compiling of UFC modules dependent on DOLFIN. I think that is a

Good point :)

> good choice and that Kristian's fix is what we should go with. Isn't UFC
> modules already dependent on cmath?

The difference is that cmath is standard and always available, it
doesn't require linking to external libraries which is the issue here.

> On Oct 27, 2011, at 7:08, Kristian B. Ølgaard
> <email address hidden> wrote:
>
>> On 27 October 2011 15:50, Garth Wells <email address hidden> wrote:
>>> I've added the math library to DOLFIN, but it doesn't seem to help.
>>> Perhaps Instant is not taking the flags from DOLFIN?
>>
>> It looks like FFC.Jit calls instant through UFC passing only a few arguments.
>> Adding the line:
>>
>>            libraries=["boost_math_tr1"])
>>
>> to the call to
>>
>> module = ufc_utils.build_ufc_module(
>>
>> in jit_form() seems to do the trick.
>>
>> The question is if we should ask users to set this manually through
>> the parameter system like 'cpp_optimize'?

If FFC can pass it directly to ufc (and thus instant) in jit _if_ it
is needed, I think that would be the most robust solution.

Martin

[Kristian B. Ølgaard (k.b.oelgaard)]

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?

>> 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.

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'.

>> 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...

[Johan Hake (johan-hake)]

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 ...

[Martin Sandve Alnæs (martinal)]

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? The...

[Johan Hake (johan-hake)]

On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
> Just a few quick comments here:
>
> cmath is fully standard, which makes it not comparable to boost math for
> these issues.

Ok.

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

But who tells the build system to provide the library? Should that be a user
tweaking the local CMakeList.txt. I think it would be nice if UFC provided a
generic FindUFC.cmake including all dependencies by default, or FFC provided
such a file (FindSomething.cmake), which then could be problem dependent.

> 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.

Ok.

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

Sure but then we rely on user interaction, and we need to provide a consistant
and robust interface for that. If I have not missed anything I see two ideal
solutions:

  1) UFC provides everything for us:

       Python : Everything just works
       C++ : We include all flags in FindUFC.cmake

  2) FFC provides optional dependecies for us. For this to be automated FFC
     need to scan a form for the use of non standard functions this
     information is then propagated:

       Python : to the ufc provided JIT compilation
       C++ : to a local CMakeFile (not sure what name we should have),
                which a user manually should include in the local CMakeFile,
                or (optimally) is already included in the local CMakeFiles.txt
                through some fancy include path.

Other suggestions? I am open for both solutions. 1) is the easiest to
implement and is the least disruptive to the present functionality.

Johan

> 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...

[Kristian B. Ølgaard (k.b.oelgaard)]

On 28 October 2011 21:16, Johan Hake <email address hidden> wrote:
> On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
>> Just a few quick comments here:
>>
>> cmath is fully standard, which makes it not comparable to boost math for
>> these issues.
>
> Ok.
>
>> The issue is mainly from python because from C++ there will be a build
>> system to handle libraries.
>
> But who tells the build system to provide the library? Should that be a user
> tweaking the local CMakeList.txt. I think it would be nice if UFC provided a
> generic FindUFC.cmake including all dependencies by default, or FFC provided
> such a file (FindSomething.cmake), which then could be problem dependent.

If UFC has to provide all possible dependencies for all possible
compilers, we end up with an infinite list of libraries which a
specific code generated by a specific form compiler might not even
need.
The form compiler e.g., FFC generates the code and therefore knows
which special libraries are needed.
It would therefore make sense if FFC could provide the flags for all
special libraries that it _might_ need, and then only in those cases
where it is actually needed should they be added to the standard
flags.
This approach will work well with Python but is more troublesome to
integrate with C++ and compiling a header file against DOLFIN.

>> 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.
>
> Ok.
>
>> But it is more robust if it is optional and not linked with unless
>> needed.
>
> Sure but then we rely on user interaction, and we need to provide a consistant
> and robust interface for that. If I have not missed anything I see two ideal
> solutions:
>
>  1) UFC provides everything for us:
>
>       Python : Everything just works
>       C++    : We include all flags in FindUFC.cmake

As I write above, this could easily get out of hand if many compilers
start using different libraries.

>  2) FFC provides optional dependecies for us. For this to be automated FFC
>     need to scan a form for the use of non standard functions this
>     information is then propagated:
>
>       Python : to the ufc provided JIT compilation
>       C++    : to a local CMakeFile (not sure what name we should have),
>                which a user manually should include in the local CMakeFile,
>                or (optimally) is already included in the local CMakeFiles.txt
>                through some fancy include path.

Python is easy, C++ is not in this case.

> Other suggestions? I am open for both solutions. 1) is the easiest to
> implement and is the least disruptive to the present functionality.

Since we're currently just talking about adding one extra boost
dependency in DOLFIN and UFC, I think we should go with option 1).

Kristian

> Johan
>
>> 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...

[Johan Hake (johan-hake)]

On Friday October 28 2011 13:02:36 Kristian B. Ølgaard wrote:
> On 28 October 2011 21:16, Johan Hake <email address hidden> wrote:
> > On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
> >> Just a few quick comments here:
> >>
> >> cmath is fully standard, which makes it not comparable to boost math for
> >> these issues.
> >
> > Ok.
> >
> >> The issue is mainly from python because from C++ there will be a build
> >> system to handle libraries.
> >
> > But who tells the build system to provide the library? Should that be a
> > user tweaking the local CMakeList.txt. I think it would be nice if UFC
> > provided a generic FindUFC.cmake including all dependencies by default,
> > or FFC provided such a file (FindSomething.cmake), which then could be
> > problem dependent.
>
> If UFC has to provide all possible dependencies for all possible
> compilers, we end up with an infinite list of libraries which a
> specific code generated by a specific form compiler might not even
> need.

I see that theoretically this might be the case, but in practice?

> The form compiler e.g., FFC generates the code and therefore knows
> which special libraries are needed.
> It would therefore make sense if FFC could provide the flags for all
> special libraries that it _might_ need, and then only in those cases
> where it is actually needed should they be added to the standard
> flags.

I see this take on it.

> This approach will work well with Python but is more troublesome to
> integrate with C++ and compiling a header file against DOLFIN.

Yes, then FFC need to provide some sort of CMake file to take care of the
extra flags.

> >> 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.
> >
> > Ok.
> >
> >> But it is more robust if it is optional and not linked with unless
> >> needed.
> >
> > Sure but then we rely on user interaction, and we need to provide a
> > consistant and robust interface for that. If I have not missed anything
> > I see two ideal solutions:
> >
> > 1) UFC provides everything for us:
> >
> > Python : Everything just works
> > C++ : We include all flags in FindUFC.cmake
>
> As I write above, this could easily get out of hand if many compilers
> start using different libraries.

Sure.

> > 2) FFC provides optional dependecies for us. For this to be automated
> > FFC need to scan a form for the use of non standard functions this
> > information is then propagated:
> >
> > Python : to the ufc provided JIT compilation
> > C++ : to a local CMakeFile (not sure what name we should have),
> > which a user manually should include in the local
> > CMakeFile, or (optimally) is already included in the local
> > CMakeFiles.txt through some fancy include path.
>
> Python is easy, C++ is not in this case.

I think C++ is incorporated into my suggestion. We just need FFC to generate
some sort of general CMakeFile, which is included in the CMakeFile of each
poject.

> > Other suggestions? I am open for both solutions. 1) is the easiest to
> > implement and is the leas...

[Kristian B. Ølgaard (k.b.oelgaard)]

On 28 October 2011 23:08, Johan Hake <email address hidden> wrote:
> On Friday October 28 2011 13:02:36 Kristian B. Ølgaard wrote:
>> On 28 October 2011 21:16, Johan Hake <email address hidden> wrote:
>> > On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
>> >> Just a few quick comments here:
>> >>
>> >> cmath is fully standard, which makes it not comparable to boost math for
>> >> these issues.
>> >
>> > Ok.
>> >
>> >> The issue is mainly from python because from C++ there will be a build
>> >> system to handle libraries.
>> >
>> > But who tells the build system to provide the library? Should that be a
>> > user tweaking the local CMakeList.txt. I think it would be nice if UFC
>> > provided a generic FindUFC.cmake including all dependencies by default,
>> > or FFC provided such a file (FindSomething.cmake), which then could be
>> > problem dependent.
>>
>> If UFC has to provide all possible dependencies for all possible
>> compilers, we end up with an infinite list of libraries which a
>> specific code generated by a specific form compiler might not even
>> need.
>
> I see that theoretically this might be the case, but in practice?
>
>> The form compiler e.g., FFC generates the code and therefore knows
>> which special libraries are needed.
>> It would therefore make sense if FFC could provide the flags for all
>> special libraries that it _might_ need, and then only in those cases
>> where it is actually needed should they be added to the standard
>> flags.
>
> I see this take on it.
>
>> This approach will work well with Python but is more troublesome to
>> integrate with C++ and compiling a header file against DOLFIN.
>
> Yes, then FFC need to provide some sort of CMake file to take care of the
> extra flags.
>
>> >> 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.
>> >
>> > Ok.
>> >
>> >> But it is more robust if it is optional and not linked with unless
>> >> needed.
>> >
>> > Sure but then we rely on user interaction, and we need to provide a
>> > consistant and robust interface for that. If I have not missed anything
>> > I see two ideal solutions:
>> >
>> >  1) UFC provides everything for us:
>> >
>> >       Python : Everything just works
>> >       C++    : We include all flags in FindUFC.cmake
>>
>> As I write above, this could easily get out of hand if many compilers
>> start using different libraries.
>
> Sure.
>
>> >  2) FFC provides optional dependecies for us. For this to be automated
>> > FFC need to scan a form for the use of non standard functions this
>> > information is then propagated:
>> >
>> >       Python : to the ufc provided JIT compilation
>> >       C++    : to a local CMakeFile (not sure what name we should have),
>> >                which a user manually should include in the local
>> > CMakeFile, or (optimally) is already included in the local
>> > CMakeFiles.txt through some fancy include path.
>>
>> Python is easy, C++ is not in this case.
>
> I think C++ is incorporated into my suggestion. We just need FFC to generate
> some sort of general CMakeFile, which is incl...

[Johan Hake (johan-hake)]

I have commited a hack for this in UFC. We need to figure out how to properly
fix this. It is related to:

  https://bugs.launchpad.net/dolfin/+bug/887324

Johan

On Saturday October 29 2011 02:11:29 Kristian B. Ølgaard wrote:
> On 28 October 2011 23:08, Johan Hake <email address hidden> wrote:
> > On Friday October 28 2011 13:02:36 Kristian B. Ølgaard wrote:
> >> On 28 October 2011 21:16, Johan Hake <email address hidden> wrote:
> >> > On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
> >> >> Just a few quick comments here:
> >> >>
> >> >> cmath is fully standard, which makes it not comparable to boost math
> >> >> for these issues.
> >> >
> >> > Ok.
> >> >
> >> >> The issue is mainly from python because from C++ there will be a
> >> >> build system to handle libraries.
> >> >
> >> > But who tells the build system to provide the library? Should that be
> >> > a user tweaking the local CMakeList.txt. I think it would be nice if
> >> > UFC provided a generic FindUFC.cmake including all dependencies by
> >> > default, or FFC provided such a file (FindSomething.cmake), which
> >> > then could be problem dependent.
> >>
> >> If UFC has to provide all possible dependencies for all possible
> >> compilers, we end up with an infinite list of libraries which a
> >> specific code generated by a specific form compiler might not even
> >> need.
> >
> > I see that theoretically this might be the case, but in practice?
> >
> >> The form compiler e.g., FFC generates the code and therefore knows
> >> which special libraries are needed.
> >> It would therefore make sense if FFC could provide the flags for all
> >> special libraries that it _might_ need, and then only in those cases
> >> where it is actually needed should they be added to the standard
> >> flags.
> >
> > I see this take on it.
> >
> >> This approach will work well with Python but is more troublesome to
> >> integrate with C++ and compiling a header file against DOLFIN.
> >
> > Yes, then FFC need to provide some sort of CMake file to take care of the
> > extra flags.
> >
> >> >> 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.
> >> >
> >> > Ok.
> >> >
> >> >> But it is more robust if it is optional and not linked with unless
> >> >> needed.
> >> >
> >> > Sure but then we rely on user interaction, and we need to provide a
> >> > consistant and robust interface for that. If I have not missed
> >> > anything I see two ideal solutions:
> >> >
> >> > 1) UFC provides everything for us:
> >> >
> >> > Python : Everything just works
> >> > C++ : We include all flags in FindUFC.cmake
> >>
> >> As I write above, this could easily get out of hand if many compilers
> >> start using different libraries.
> >
> > Sure.
> >
> >> > 2) FFC provides optional dependecies for us. For this to be automated
> >> > FFC need to scan a form for the use of non standard functions this
> >> > information is then propagated:
> >> >
> >> > Python : to the ufc provided JIT compilation
> >> > C++ : to a local CMakeFile (not sure...

[Martin Sandve Alnæs (martinal)]

Works for me. I've enabled the bessel function test and pushed it to
my personal buildbot. If that passes, I will push it to 1.0.x to see
if the macbot passes too. If it doesn't I'll disable the test again.

Martin

On 17 November 2011 07:47, Johan Hake <email address hidden> wrote:
> I have commited a hack for this in UFC. We need to figure out how to properly
> fix this. It is related to:
>
>  https://bugs.launchpad.net/dolfin/+bug/887324
>
> Johan
>
> On Saturday October 29 2011 02:11:29 Kristian B. Ølgaard wrote:
>> On 28 October 2011 23:08, Johan Hake <email address hidden> wrote:
>> > On Friday October 28 2011 13:02:36 Kristian B. Ølgaard wrote:
>> >> On 28 October 2011 21:16, Johan Hake <email address hidden> wrote:
>> >> > On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
>> >> >> Just a few quick comments here:
>> >> >>
>> >> >> cmath is fully standard, which makes it not comparable to boost math
>> >> >> for these issues.
>> >> >
>> >> > Ok.
>> >> >
>> >> >> The issue is mainly from python because from C++ there will be a
>> >> >> build system to handle libraries.
>> >> >
>> >> > But who tells the build system to provide the library? Should that be
>> >> > a user tweaking the local CMakeList.txt. I think it would be nice if
>> >> > UFC provided a generic FindUFC.cmake including all dependencies by
>> >> > default, or FFC provided such a file (FindSomething.cmake), which
>> >> > then could be problem dependent.
>> >>
>> >> If UFC has to provide all possible dependencies for all possible
>> >> compilers, we end up with an infinite list of libraries which a
>> >> specific code generated by a specific form compiler might not even
>> >> need.
>> >
>> > I see that theoretically this might be the case, but in practice?
>> >
>> >> The form compiler e.g., FFC generates the code and therefore knows
>> >> which special libraries are needed.
>> >> It would therefore make sense if FFC could provide the flags for all
>> >> special libraries that it _might_ need, and then only in those cases
>> >> where it is actually needed should they be added to the standard
>> >> flags.
>> >
>> > I see this take on it.
>> >
>> >> This approach will work well with Python but is more troublesome to
>> >> integrate with C++ and compiling a header file against DOLFIN.
>> >
>> > Yes, then FFC need to provide some sort of CMake file to take care of the
>> > extra flags.
>> >
>> >> >> 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.
>> >> >
>> >> > Ok.
>> >> >
>> >> >> But it is more robust if it is optional and not linked with unless
>> >> >> needed.
>> >> >
>> >> > Sure but then we rely on user interaction, and we need to provide a
>> >> > consistant and robust interface for that. If I have not missed
>> >> > anything I see two ideal solutions:
>> >> >
>> >> >  1) UFC provides everything for us:
>> >> >
>> >> >       Python : Everything just works
>> >> >       C++    : We include all flags in FindUFC.cmake
>> >>
>> >> As I write above, this could easily get out of hand if many compilers
>> >> start using diffe...

[Anders Logg (logg)]

Are there any unit tests for JIT compilation of Bessel forms? If not, could you add some?

It looks like your buildbot failed, but it doesn't look like it's related to Bessel functions.

[Johan Hake (johan-hake)]

On Thursday November 17 2011 02:24:27 Martin Sandve Alnæs wrote:
> Works for me. I've enabled the bessel function test and pushed it to
> my personal buildbot. If that passes, I will push it to 1.0.x to see
> if the macbot passes too. If it doesn't I'll disable the test again.

Thanks!

Johan

> Martin
>
> On 17 November 2011 07:47, Johan Hake <email address hidden> wrote:
> > I have commited a hack for this in UFC. We need to figure out how to
> > properly fix this. It is related to:
> >
> > https://bugs.launchpad.net/dolfin/+bug/887324
> >
> > Johan
> >
> > On Saturday October 29 2011 02:11:29 Kristian B. Ølgaard wrote:
> >> On 28 October 2011 23:08, Johan Hake <email address hidden> wrote:
> >> > On Friday October 28 2011 13:02:36 Kristian B. Ølgaard wrote:
> >> >> On 28 October 2011 21:16, Johan Hake <email address hidden>
wrote:
> >> >> > On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
> >> >> >> Just a few quick comments here:
> >> >> >>
> >> >> >> cmath is fully standard, which makes it not comparable to boost
> >> >> >> math for these issues.
> >> >> >
> >> >> > Ok.
> >> >> >
> >> >> >> The issue is mainly from python because from C++ there will be a
> >> >> >> build system to handle libraries.
> >> >> >
> >> >> > But who tells the build system to provide the library? Should that
> >> >> > be a user tweaking the local CMakeList.txt. I think it would be
> >> >> > nice if UFC provided a generic FindUFC.cmake including all
> >> >> > dependencies by default, or FFC provided such a file
> >> >> > (FindSomething.cmake), which then could be problem dependent.
> >> >>
> >> >> If UFC has to provide all possible dependencies for all possible
> >> >> compilers, we end up with an infinite list of libraries which a
> >> >> specific code generated by a specific form compiler might not even
> >> >> need.
> >> >
> >> > I see that theoretically this might be the case, but in practice?
> >> >
> >> >> The form compiler e.g., FFC generates the code and therefore knows
> >> >> which special libraries are needed.
> >> >> It would therefore make sense if FFC could provide the flags for all
> >> >> special libraries that it _might_ need, and then only in those cases
> >> >> where it is actually needed should they be added to the standard
> >> >> flags.
> >> >
> >> > I see this take on it.
> >> >
> >> >> This approach will work well with Python but is more troublesome to
> >> >> integrate with C++ and compiling a header file against DOLFIN.
> >> >
> >> > Yes, then FFC need to provide some sort of CMake file to take care of
> >> > the extra flags.
> >> >
> >> >> >> 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.
> >> >> >
> >> >> > Ok.
> >> >> >
> >> >> >> But it is more robust if it is optional and not linked with unless
> >> >> >> needed.
> >> >> >
> >> >> > Sure but then we rely on user interaction, and we need to provide a
> >> >> > consistant and robust interface for that. If I have not missed
> >> >> > anything I see two ideal solutions:
> >> >> >
> >> >> > 1) UFC provid...

[Johan Hake (johan-hake)]

On Thursday November 17 2011 10:05:40 Anders Logg wrote:
> Are there any unit tests for JIT compilation of Bessel forms? If not,
> could you add some?

Who is "you"?

Johan

[Anders Logg (logg)]

On Thu, Nov 17, 2011 at 06:35:52PM -0000, Johan Hake wrote:
> On Thursday November 17 2011 10:05:40 Anders Logg wrote:
> > Are there any unit tests for JIT compilation of Bessel forms? If not,
> > could you add some?
>
> Who is "you"?

Anyone of you, I don't care which. ;-)

--
Anders

[Martin Sandve Alnæs (martinal)]

See the tiny commit in lp:~martinal/dolfin/work which enables the Bessel jit tests.

Martin

Den 17. nov. 2011 kl. 19:47 skrev Anders Logg <email address hidden>:

> On Thu, Nov 17, 2011 at 06:35:52PM -0000, Johan Hake wrote:
>> On Thursday November 17 2011 10:05:40 Anders Logg wrote:
>>> Are there any unit tests for JIT compilation of Bessel forms? If not,
>>> could you add some?
>>
>> Who is "you"?
>
> Anyone of you, I don't care which. ;-)
>
> --
> Anders
>
> --
> 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:
> In Progress
>
> 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

[Johan Hake (johan-hake)]

On Thursday November 17 2011 13:20:13 Martin Sandve Alnæs wrote:
> See the tiny commit in lp:~martinal/dolfin/work which enables the Bessel
> jit tests.

That was easy!

It is now pushed to both branches.

Johan

> Martin
>
> Den 17. nov. 2011 kl. 19:47 skrev Anders Logg <email address hidden>:
> > On Thu, Nov 17, 2011 at 06:35:52PM -0000, Johan Hake wrote:
> >> On Thursday November 17 2011 10:05:40 Anders Logg wrote:
> >>> Are there any unit tests for JIT compilation of Bessel forms? If not,
> >>> could you add some?
> >>
> >> Who is "you"?
> >
> > Anyone of you, I don't care which. ;-)
> >
> > --
> > Anders