[petsc-dev] now that we have -lpetsc should we also have #include "petsc.h"?

Lisandro Dalcin dalcinl at gmail.com
Fri Feb 26 13:31:59 CST 2010

On 26 February 2010 15:22, Satish Balay <balay at mcs.anl.gov> wrote:
> On Fri, 26 Feb 2010, Lisandro Dalcin wrote:
>> On 26 February 2010 13:48, Satish Balay <balay at mcs.anl.gov> wrote:
>> > One note on this scheme wrt linux..
>> >
>> > Fedora is making it illegal for appliation to link *only* to
>> > libpetsc.so [if libpetsc.so relies on lipetscsys.so etc..]
>> >
>> > http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
>> >
>> > perhaps other linux distos will do the same..
>> >
>> OK, these folks have lost their mind. This policy is something they
>> should not enforce, but check for it, let say in a tool like
>> rpmlint... Moreover, these checks should only make sense where the
>> dependencies are for DSO's comming from unrelated packages...
>> The issues that the proposed change is trying to address is VERY
>> valid, but it has nothing to do with the use case I'm proposing for
>> PETSc.
> An't you proposing things should work for user with 'gcc usercode.c -lpetsc'?

Yes, That's what I'm proposing.

> The way I understant the above - eventhough we create:
> 'gcc -shared libpetsc.so -lpetscksp -lpetscmat -lpetscsys -lmpich -lblas'
> one would have to use:
> gcc usercode.c -lpetsc -lpetscksp -lpetscmat -lpetscsys -lmpich -lblas'?
> And if the user does only 'gcc usercode.c -lpetsc' - he would get unresolved symbol
> errors.

Yes, and there is my complain about this nonsense... because -lpetsc
should silently load all the other petscxxx, though I accept that for
MPI and BLAS the story is different.

Lisandro Dalcin
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

More information about the petsc-dev mailing list