On Fri, 26 Feb 2010, Lisandro Dalcin wrote: > On 26 February 2010 15:22, Satish Balay <balay at mcs.anl.gov> wrote:
> > 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. Ah MLK does something like: [petsc:mkl/lib/32] petsc> cat libmkl.so GROUP (-lmkl_intel -lmkl_intel_thread -lmkl_core) Perhaps this will work for your usage. However currently I don't see the usefulness of this scheme when the user still has to do the following - [and the difficult part is getting the c/fortran compiler libraries] and PETSc makefile handles this gcc usercode.c -lpetsc -lmpich -lblas -lc_compiler_lib -lfortran_compiler_lib Satish
