[petsc-dev] configure failed after update of OSX

[Geoff Oxberry]

On Tue, Jan 28, 2014 at 4:48 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> 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]
>

I did that because I'm paranoid, and there are reports of the hpc.sf
language standard libraries interfering with the system language standard
libraries. I think you're right that it is unnecessary. The AT&T binaries
do require it.


>
> > 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.
>
>
The symlinking is more or less what Homebrew does if you install
apple-gcc42. GNU Stow is also supposed to use symlink farms, and I've come
to appreciate the approach precisely because you can delete directories
without much hassle.


> >
> > > [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]


Aside from SciPy's warning, no. I wrote a couple cross-language programs to
test it a few years ago, and I'm pretty sure I screwed up the linking when
the two versions were different. If I get some time, I'll retry it and let
you know if something weird happens. There isn't a lot of easily
Google-able material on mixing gfortran from one GCC version and the rest
of the GCC suite from another version; I'll see if I can convince Ondrej
Certik to write docs about building cross-language Fortran code (and not
just writing it). I rebuilt PETSc today on another machine with
gfortran-4.8 and clang-3.3 and it worked fine.


> > 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]
>

I can answer some Homebrew questions. I typically skim petsc-dev and
petsc-users due to my relative PETSc inexperience, and only read a few
posts here and there. If someone bugs you about it and I miss it, ping me,
and I'll do my best to help. PETSc is also a package in the
homebrew-science repo, so I can lean on some of them for help also. I've
learned to build PETSc from source because the package builds in Linux
distros and Mac package managers usually lack the external package
capabilities I want (and they're old versions, too).


>
> thanks,
> Satish
>

Cheers,

Geoff

-- 
Geoffrey Oxberry, Ph.D., E.I.T.
goxberry at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140129/e7326de1/attachment.html>