dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Sun, Jul 17, 2005 at 03:41:11PM -0400, Faheem Mitha wrote:
> On Sun, 17 Jul 2005, Johan Jansson wrote:
> >I'm not sure how to resolve this. It looks to be related to the issue
> >of implicit dependencies which you talk about below, but it's actually
> >separate. DOLFIN could have determined on its own to use the flags
> >"-L/usr/lib/mpich/lib -lmpich", which would still have led to link
> >errors when installing lam4-dev.
> 
> I don't understand. Why is it necesary for DOLFIN to use the alternatives 
> system at all? If it is using MPICH libraries explicitly everywhere, I 
> don't see the problem, and from what I understand, that is what it is 
> doing.
> 
> Please elaborate.
> 

No, the library path is explicit while the include path is the one
provided by the alternatives system. I'm not sure why both aren't
discovered in the same way, but it seems PETSc provides the link path
but not the include path. Still, the alternatives system should
guarantee that the different alternatives provided are
interchangeable, and in this case they're not, since they break
compilation.

...

> The standard place for these kinds of discussions is debian-devel. I could 
> possibly also file a bug against some Debian package, but I'm not sure 
> which. I guess I'll post to debian-devel and take it from there. Feel free 
> to post yourself if you wish, since you probably understand the issue 
> better than I do.
> 
> In the meantime, I'll put a conflicts in libdolfin-dev against lam4-dev 
> till this is resolved.

Ok. I can post there and ask for clarification.

> In that case, I notice that DOLFIN links to the debug version of the 
> shared libraries by default. Presumably it should link to the optimized 
> version. How can I change this?

You can pass --with-petsc-bopt=O_c++ to DOLFIN's configure. I think
it's a good idea to keep linking to the debug version though, since it
should make it easier to debug user-reported errors.

  Johan