[petsc-dev] configure failed after update of OSX

[Satish Balay]

On Tue, 28 Jan 2014, Geoff Oxberry wrote:

> On Tuesday, January 28, 2014, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > On Tue, 28 Jan 2014, Barry Smith wrote:
> >
> > > >
> > > > Satish is probably right here about the build location. It's been
> > three or four years since I've installed it this way. I stand by that it's
> > still difficult to revert. I actually tried this method because of PETSc
> > and regretted it because the experience was terrible. Using a package
> > manager is more maintainable, and I think PETSc's recommendation of the
> > hpc.sourceforge build is a disservice to both users and to PETSc's
> > excellent reputation.
> > >
> > >    I think package managers for Mac OS are a disservice to the community
> > and recommend not using them. (See all the discussions in these emails
> > about how they fuck up).
> > >
> >
> > My view is: anyone using OSX has bought into the idea of not having a
> > proper package management system. [yeah you get easy-install packages
> > - but most of them don't have an proper way to uninstall - unless its
> > an "osx-app" which you can drag/drop into trash]
> >
> > gfortran from hpc.sourceforge does things "no worse" than most packages
> > that are available for OSX.
> >
> > Its not obvious - but one can use the file listing from the tarball [as
> > mentioned in my previous e-mail to uninstall]. And is tucked away
> > in /usr/local - so it doesn't do any damage like other packages.
> 
> 
> If you follow the relative install paths, yes, your method does the job.
> It's what I did, with some testing, and then I reinstalled the XCode
> Command Line Tools.

Just to clarify did you have to reinstall xcode because it broke when
you uninstalled hpc.sf gfortran?  [I had to do that due to R's
gfortran - but never for hpc - at it was in /usr/local - and never
interfered with xcode]

> As long as a user is careful, no harm done; it's also
> easy to mess up. You could do something similar via lsbom for packages in
> OS X and/or delete via the package identifier using pkgutil and largely
> only leave behind plist files. This method is what homebrew-cask uses for
> managing OS X binaries.

I agree any package on OSX can be deleted by using the above methond
[instead of quering tarball for file-list - query the pkg database for
file-list]. I've had to do this a couple of times.

On an added note - I've also experimented with installing gfortran from hpc
in say ~/soft/gf/bin/gfortran instead of /usr/local/bin/gfortran so
that uninstall is just 'rm -rf ~/soft/gf/'. This would work after fixing
the dylibs with:
find . -type f -name "*.dylib" -exec install_name_tool -id `pwd`/{} {} \;

[Last time I did this - I had to do some additional stuff - but there
might have been some extra issues with this install]. Since 'tar -tf'
was relatively easier - I've settled on /usr/local/bin/gfortran for
past few years.

> 
> > [for eg: install mercurial for OSX - and see if you can uninstall it]
> 
> 
> For Mercurial, I'd install & uninstall via pip and a virtualenv. Your point
> is well-taken for packages in general, and can still be managed (see
> above). Uninstall apps will also do the job.

Yes there are many ways of installing mercurial. If one were to
install binary from http://mercurial.selenic.com/downloads/ - one
would have to use the 'query pkg database to get file-list and delete
them' approach [as it doesn't have uninstall option].

I refered to this to say 'uninstalling gfortran from hpc is no worse
than uninstalling such packages'. Its slightly better because nuking
/usr/local won't break the core OS files]

> > I agree a better package management system [aka macports/homebrew]
> > should be preferable. But with all the wierd issues that keep comping
> > up with users using macports on petsc lists - I can't convince myself
> > that it is a better recommendation.
> >
> > perhaps homebrew is better - I don't know.
> 
> You guys do the support work (and do a good job of it), so I defer to your
> judgment here. My opinion was borne out of a bad experience and trying
> several methods of installation; I apologize for the brief burst of
> impertinence.
> 
> I would not recommend MacPorts either; I don't use it. Sean knows more
> about this than I do and can better defend MacPorts.
> 
> With Homebrew, it should be possible to replicate the current
> recommendation and only install six additional packages (cloog, gmp, isl,
> mpfr, libmpc, and pkg-config).
> 
> Mixing gfortran 4.8 with the rest of the gcc 4.2 or clang 3.3 stack can
> also be tricky, which was my point about different compiler versions.

Any known issues? gfortran-4.8 from HPC [with apple gcc-4.2] is used
in our default nightly test suite - and we haven't seen any issues
[wrt petsc]

> SciPy
> recommends the AT&T build and states that problems may arise with the
> hpc.sourceforge build; as you pointed out, this version causes problems for
> PETSc. So I tend to use multiple builds of PETSc in different PETSC_ARCH
> directories; one of these builds is a gcc 4.8 build because PETSc is
> relatively self-contained (which is a testament to your design and build
> system), so I'm not terribly worried about system library conflicts.
> 
> My Python rant is not a good argument for hpc.sourceforge (or against
> package managers) because sitewide installs of interpreted language
> packages -- especially via an OS package manager -- should be minimized,
> regardless of operating system or distribution. Otherwise, you run into
> problems like pip trying to overwrite system libraries.
> 
> I would aswell recommend virtualbox with linux as a superior choice.
> >
> > Satish
> >
> 
> Probably the best choice. Even then, some can't run virtual machines (I
> can't at work), and OS X is a lesser evil than a Windows machine.
> 
> As Jed points out, manual installation is difficult to maintain. Fixing
> a package manager is my best path forward (not getting a different job);
> they're not perfect, but they won't get better unless people work on
> them. I agree with Matt that most of this discussion is ideology.

Matt know hows to debug/fix and workarround issues if they come up :)

The primary source of contention here is 'which gfortran' to
recommend.

If folks on petsc lists can support MacPorts and Homebrew - I can
update the FAQ accordingly [with the 3 options listed]

thanks,
Satish