logic of config options

Matthew Knepley knepley at gmail.com
Mon May 11 12:48:38 CDT 2009


2009/5/11 Giuseppe Ghibò <ghibo at mandriva.com>

> Satish Balay wrote:
>
>> On Tue, 5 May 2009, Giuseppe Ghibò wrote:
>>
>>
>>
>>> Hi.
>>>
>>> I'm trying to package petsc 2.3.3,
>>>
>>>
>>
>> Why package this older version? Current version is 3.0.0.
>>
>>
>>
> Because I've to use bundled with libmesh (http://libmesh.sourceforge.net)
> and IIRC it talks only (or maybe advice don't remember exactly) about PetSC
> 2.3.3 and not 3.0.0.
>
>> but I didn't understand the logic of some options, in particular for
>>> umfpack.  E.g. If I specify at the config stage:
>>>
>>> --with-umfpack-lib=[${_libdir}/libumfpack.a,${_libdir}/libamd.a]
>>>
>>> and the ${_libdir} path contains both shared and static libraries then
>>> the linking command are expanded to:
>>>
>>> -lumfpack -Wl,-rpath,<path of petsc> -lamd
>>>
>>> Ditto if I specify:
>>>
>>> --with-umfpack-lib=[libumfpack.a]
>>>
>>> they are expanded to the two libs "-lumpack -lamd" (i.e. it guesses the
>>> other lib "libamd" even if I don't specify).
>>>
>>>
>>
>> petsc-3.0.0 won't add the extra -lamd
>>
>>
>
>  Currently this is not possible. Perhpas it will be if "-Lfoo -lbar" is
>> supported.
>>
>>
> well, IIRC I tried and didn't worked (and -L was not even needed because of
> system-path), but maybe there could be added an extra behaviour (see my
> previous mail) to let the user take full control about which libraries
> should be passed to pass detecting tests.


This definitely works in the latest release.

  Matt


>
> Bye
> Giuseppe.
>
-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090511/309fafbd/attachment.html>


More information about the petsc-dev mailing list