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

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