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

Satish Balay balay at mcs.anl.gov
Fri Feb 26 12:22:38 CST 2010

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'?

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


More information about the petsc-dev mailing list