Anders Logg wrote:
> 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.
>
Correct.
> 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.
>
Not as far as I know.
Garth
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
