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


_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to