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
