dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Apr 13, 2008 at 09:16:50PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Sun, Apr 13, 2008 at 08:28:34PM +0100, Garth N. Wells wrote:
> >> Matthew Knepley wrote:
> >>> I have said this more than 13 times. 
> >> Nice that you're counting ;).
> >>
> >> That link procedure is Wrong Wrong Wrong.
> >>> I have also given the right ways to do it:
> >>>
> >>>   1) 'make getlinklibs' prints the correct link line
> >>>
> >>>   2) 'include ${PETSC_DIR}/conf/variables' in the makefile and use
> >>> ${PETSC_TS_LIB}
> > 
> > It's been there:
> > 
> >   http://fenics.org/hg/dolfin?cs=716a643cf63b
> > 
> > but was later removed:
> > 
> >   http://fenics.org/hg/dolfin?cs=5f87c119a79d
> > 
> >>>   3) Load the pickled configure information and read it into Python.
> >>> There is an example
> >>>       in $PETSC_DIR/bin/configVars.py
> >>>
> >>> Why in the hell is this still screwed up? Of course you need to link
> >>> all the 3rd party
> >>> libraries.
> >>>
> >> There is a reason why we don't want to link to third-party libraries
> >> which PETSc depends on. The reason has been discussed at length on this
> >> list; we don't want to be tied into the libraries (and versions of
> >> libraries) which PETSc downloads and uses, and possibly modifies. Any 
> >> suggestions on how deal nicely with this issue are welcome.
> > 
> > Don't we always need to ask a library which has other dependencies
> > which those dependencies are and add them when building an application
> > against DOLFIN (and PETSc)?
> > 
> 
> Don't we just need to resolve the location of any header files that we 
> might include from an external library (via DOLFIN header files) and 
> libs for any functions that we call? I can compile and run most demos 
> (perhaps even all) without any PETSc library flags at all because they 
> don't call any PETSc functions directly. libdolfin knows where the PETSc 
> libraries are. We need to add the PETSc libraries because users can 
> access the underlying PETSc data and call PETSc functions.

ok.

> > In dolfin.pc, we have
> > 
> >   Requires: numpy-1 boost ufc-1 umfpack python-2 petsc gts scotch libxml-2.0
> > 
> > which means pkg-config will lookup petsc.pc to find the dependencies
> > for PETSc. Then petsc.pc should list its requirements etc, or list
> > them in the Libs field. (Since PETSc mostly downloads/builds its own
> > stuff, it's more appropriate to just list the dependencies in the Libs
> > field.)
> > 
> > It seems to me we need to add everything PETSc needs in the Libs field
> > in petsc.pc (by looking at PETSC_TS_LIB). If we stick it in at the
> > end, it shouldn't mess anything else up, since other dependencies will
> > be found first.
> > 
> 
> Say PETSc is configured with UMFPACK and DOLFIN depends on the UMFPACK 
> library installed under /usr/lib. Which UMFPACK will PETSc will use? The 
> first listed one from /usr/lib or the correct one under 
> $PETSC_DIR/external_packages?
> 
> Garth

ok, I understand (finally).

Is the following correct?

1. This is no problem when PETSc is compiled with --with-shared=1,
since then libpetsc.so will know the correct location of UMFPACK.

2. If PETSc is not compiled with --with-shared=1, there is *no way* to
tell the linker (gcc) to use one specific UMFPACK for some of the
.o/.a files it sees on the command line and another UMFPACK for
others.

-- 
Anders