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 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 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).
>> >
>> > If this is what we land on I can try to hack the CMake of UFC and add it
>> > there. If I fail I might ask some CMake guro to help out. I can also add
>> > configuration of the libmath from boost to the compilation of the python
>> > extension module.
>>
>> Yes, let's go with this approach for now and see if we can avoid
>> making things too general/complex.
>>
>> Kristian
>>
>> > Johan
>> >
>> >> 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:
>> >> >> > > >> 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/d003d0ea29ed934626596300
>> >> >> > 0f1
>> >> >> >
>> >> >> > > >> > 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/d003d0ea29ed934626596300
>> >> >> > 0f1 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/d003d0ea29ed934626596300
>> >> >> > 0f1 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/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
>