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

[Lisandro Dalcin]

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