Build Petsc with Shared Libraries

[Ryan Schmidt]

On Jul 18, 2012, at 12:42, Clemens Lang wrote:

> On Wed, Jul 18, 2012 at 09:34:24AM -0700, Romain Jolivet wrote:
>> DEBUG: Marking /opt/local/lib/petsc/lib/libparmetis.dylib as broken
>> Could not open /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_petsc/petsc/work/petsc-3.3-p0/darwin/lib/libmetis.dylib: Error opening or reading file (referenced from /opt/local/lib/petsc/lib/libparmetis.dylib)
>> DEBUG: Marking /opt/local/lib/petsc/lib/libpetsc.dylib as broken
>> Could not open /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_petsc/petsc/work/petsc-3.3-p0/darwin/lib/libparmetis.dylib: Error opening or reading file (referenced from /opt/local/lib/petsc/lib/libpetsc.dylib)
>> DEBUG: Marking /opt/local/lib/petsc/lib/libpetsc.dylib as broken
> 
> The libraries have not been linked correctly. I assume the first line in
> otool -L /opt/local/lib/petsc/lib/libpetsc.dylib contains the
> worksrcdir, which causes this issue when linking against it.
> 
> Please file a bug so the maintainer can fix this.

Note that this issue only exists because Romain altered the portfile to install shared libraries. There was no problem with the portfile in its unmodified state.

Still, it would be nice to have shared libraries, so it's a reasonable request to add properly-linked shared libraries to the port.

Here's the ticket Romain filed:

https://trac.macports.org/ticket/35245


On Jul 18, 2012, at 13:11, Sean Farley wrote:

> The PETSc portfile is very wrong, particularly with the prefix
> install. I've been meaning to submit a diff but for the time being,
> here my own PETSc portfile that I use:
> 
> https://bitbucket.org/seanfarley/scienceports/src/5b57adccee2f/math/petsc/Portfile
> 
> Notable things that need to be fixed in the MacPorts version:
> 
> * don't use both --with-c-support and --with-c++-support
> * unnecessary to use --with-python
> * don't use --with-pic
> * don't use --with-mpi=1
> * don't pass ${destroot} to --prefix
> * don't pass mpi compiler wrappers to --with-{cc,cxx}; just use
> --with-mpi-dir=${prefix} (the correct compilers will be used based on
> that)
> * don't ever mess with blas/lapack options
> * don't pass things to --LIB
> 
> If the devs at macports want, they could update metis, parmetis,
> blacs, scalapck, mumps, ml, and SuiteSparse to my ports located at
> bitbucket; they are the same ones that are used for
> --download-{metis,parmetis,blacs,scalapack,mumps,ml,umfpack} and, as a
> bonus, are all updated to the latest versions.

Sean, it's up to the maintainers of those ports as to whether they would like to incorporate your changes, and for the petsc port, I would encourage you to file a bug report with a diff with these changes and explanations about why the changes need to be made.

In the case of our metis and SuiteSparse ports, they have no maintainers. You can still file tickets with diffs and someone will review them and commit them eventually. If the tickets don't get addressed in a timely manner you can ping the macports-dev mailing list to remind us.

None of the other ports you mentioned exist in MacPorts at this time. You would be welcome to contribute your ports to us by filing tickets in the issue tracker as usual. Note that for parmetis a port has already been submitted; you could see if that one is the same as yours, or if not, submit an updated version there:

https://trac.macports.org/ticket/20844