<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 4:48 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 28 Jan 2014, Geoff Oxberry wrote:<br>
<br>
> On Tuesday, January 28, 2014, Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Tue, 28 Jan 2014, Barry Smith wrote:<br>
> ><br>
> > > ><br>
> > > > Satish is probably right here about the build location. It's been<br>
> > three or four years since I've installed it this way. I stand by that it's<br>
> > still difficult to revert. I actually tried this method because of PETSc<br>
> > and regretted it because the experience was terrible. Using a package<br>
> > manager is more maintainable, and I think PETSc's recommendation of the<br>
> > hpc.sourceforge build is a disservice to both users and to PETSc's<br>
> > excellent reputation.<br>
> > ><br>
> > >    I think package managers for Mac OS are a disservice to the community<br>
> > and recommend not using them. (See all the discussions in these emails<br>
> > about how they fuck up).<br>
> > ><br>
> ><br>
> > My view is: anyone using OSX has bought into the idea of not having a<br>
> > proper package management system. [yeah you get easy-install packages<br>
> > - but most of them don't have an proper way to uninstall - unless its<br>
> > an "osx-app" which you can drag/drop into trash]<br>
> ><br>
> > gfortran from hpc.sourceforge does things "no worse" than most packages<br>
> > that are available for OSX.<br>
> ><br>
> > Its not obvious - but one can use the file listing from the tarball [as<br>
> > mentioned in my previous e-mail to uninstall]. And is tucked away<br>
> > in /usr/local - so it doesn't do any damage like other packages.<br>
><br>
><br>
> If you follow the relative install paths, yes, your method does the job.<br>
> It's what I did, with some testing, and then I reinstalled the XCode<br>
> Command Line Tools.<br>
<br>
</div></div>Just to clarify did you have to reinstall xcode because it broke when<br>
you uninstalled hpc.sf gfortran?  [I had to do that due to R's<br>
gfortran - but never for hpc - at it was in /usr/local - and never<br>
interfered with xcode]<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> As long as a user is careful, no harm done; it's also<br>
> easy to mess up. You could do something similar via lsbom for packages in<br>
> OS X and/or delete via the package identifier using pkgutil and largely<br>
> only leave behind plist files. This method is what homebrew-cask uses for<br>
> managing OS X binaries.<br>
<br>
</div>I agree any package on OSX can be deleted by using the above methond<br>
[instead of quering tarball for file-list - query the pkg database for<br>
file-list]. I've had to do this a couple of times.<br>
<br>
On an added note - I've also experimented with installing gfortran from hpc<br>
in say ~/soft/gf/bin/gfortran instead of /usr/local/bin/gfortran so<br>
that uninstall is just 'rm -rf ~/soft/gf/'. This would work after fixing<br>
the dylibs with:<br>
find . -type f -name "*.dylib" -exec install_name_tool -id `pwd`/{} {} \;<br>
<br>
[Last time I did this - I had to do some additional stuff - but there<br>
might have been some extra issues with this install]. Since 'tar -tf'<br>
was relatively easier - I've settled on /usr/local/bin/gfortran for<br>
past few years.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> > [for eg: install mercurial for OSX - and see if you can uninstall it]<br>
><br>
><br>
> For Mercurial, I'd install & uninstall via pip and a virtualenv. Your point<br>
> is well-taken for packages in general, and can still be managed (see<br>
> above). Uninstall apps will also do the job.<br>
<br>
</div>Yes there are many ways of installing mercurial. If one were to<br>
install binary from <a href="http://mercurial.selenic.com/downloads/" target="_blank">http://mercurial.selenic.com/downloads/</a> - one<br>
would have to use the 'query pkg database to get file-list and delete<br>
them' approach [as it doesn't have uninstall option].<br>
<br>
I refered to this to say 'uninstalling gfortran from hpc is no worse<br>
than uninstalling such packages'. Its slightly better because nuking<br>
/usr/local won't break the core OS files]</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> > I agree a better package management system [aka macports/homebrew]<br>
> > should be preferable. But with all the wierd issues that keep comping<br>
> > up with users using macports on petsc lists - I can't convince myself<br>
> > that it is a better recommendation.<br>
> ><br>
> > perhaps homebrew is better - I don't know.<br>
><br>
> You guys do the support work (and do a good job of it), so I defer to your<br>
> judgment here. My opinion was borne out of a bad experience and trying<br>
> several methods of installation; I apologize for the brief burst of<br>
> impertinence.<br>
><br>
> I would not recommend MacPorts either; I don't use it. Sean knows more<br>
> about this than I do and can better defend MacPorts.<br>
><br>
> With Homebrew, it should be possible to replicate the current<br>
> recommendation and only install six additional packages (cloog, gmp, isl,<br>
> mpfr, libmpc, and pkg-config).<br>
><br>
> Mixing gfortran 4.8 with the rest of the gcc 4.2 or clang 3.3 stack can<br>
> also be tricky, which was my point about different compiler versions.<br>
<br>
</div>Any known issues? gfortran-4.8 from HPC [with apple gcc-4.2] is used<br>
in our default nightly test suite - and we haven't seen any issues<br>
[wrt petsc]</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> SciPy<br>
> recommends the AT&T build and states that problems may arise with the<br>
> hpc.sourceforge build; as you pointed out, this version causes problems for<br>
> PETSc. So I tend to use multiple builds of PETSc in different PETSC_ARCH<br>
> directories; one of these builds is a gcc 4.8 build because PETSc is<br>
> relatively self-contained (which is a testament to your design and build<br>
> system), so I'm not terribly worried about system library conflicts.<br>
><br>
> My Python rant is not a good argument for hpc.sourceforge (or against<br>
> package managers) because sitewide installs of interpreted language<br>
> packages -- especially via an OS package manager -- should be minimized,<br>
> regardless of operating system or distribution. Otherwise, you run into<br>
> problems like pip trying to overwrite system libraries.<br>
><br>
> I would aswell recommend virtualbox with linux as a superior choice.<br>
> ><br>
> > Satish<br>
> ><br>
><br>
> Probably the best choice. Even then, some can't run virtual machines (I<br>
> can't at work), and OS X is a lesser evil than a Windows machine.<br>
><br>
> As Jed points out, manual installation is difficult to maintain. Fixing<br>
> a package manager is my best path forward (not getting a different job);<br>
> they're not perfect, but they won't get better unless people work on<br>
> them. I agree with Matt that most of this discussion is ideology.<br>
<br>
</div>Matt know hows to debug/fix and workarround issues if they come up :)<br>
<br>
The primary source of contention here is 'which gfortran' to<br>
recommend.<br>
<br>
If folks on petsc lists can support MacPorts and Homebrew - I can<br>
update the FAQ accordingly [with the 3 options listed]<br></blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
thanks,<br>
Satish<br>
</blockquote></div><br>Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Geoff<br clear="all"><div><br></div>-- <br><div dir="ltr"><span></span>Geoffrey Oxberry, Ph.D., E.I.T.<br><a href="mailto:goxberry@gmail.com" target="_blank">goxberry@gmail.com</a><br>
<span></span></div>
</div></div>