moab on mac

[gidden]

trying to build and test with moab currently leads to a linking error on macs. note that a full suite of build scripts and run specs exist in the repo, for which ubuntu passes and mac does not.

[gidden]

note that dagmc-ci does not test on macs

[scopatz]

That explains some things...

[gidden]

I've done a little more digging and found the following:

• a similar problem in the HDF5 listserv here
  • it appears that there is something specific to macs called cctools that may not be up to date (it's not clear why that would cause hdf5 linking to fail)
• it is possible to download the source for 10.8 here
  • however, they only provide a makefile with no configure script (at first glance), which I'm betting is pre-configured to be root-installable

I need to move on to bigger and better things (i.e., cyclus, research, pyne transmute, and graduating), so I'll leave this issue for the next intrepid CIer.

[gidden]

Hi @scopatz, @crbates. I started this issue a few days ago and thought we should continue any/all discussion here. Let me know if you'd still prefer the listserv.

I've been able to confirm the same error using HDF5-1.8.11 and the latest MOAB: http://submit-1.batlab.org/nmi-runs/gidden/2014/03/gidden_submit-1.batlab.org_1394492557_24936/userdir/nmi:x86_64_MacOSX8/remote_pre_declare.err

I still see the runlib error, i.e.,

++ make install
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5CS.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5Dmpio.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5Fmpi.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5FDdirect.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5FDmpi.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5FDmpio.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5FDmpiposix.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5MFdbg.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5Obogus.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5Smpio.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5TS.o) has no symbols
ranlib: file: /Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/hdf5-1.8.11/../install/lib/libhdf5.a(H5Zszip.o) has no symbols

There's also another (possibly related?) error:

libtool: link: warning: `/Volumes/MacintoshHD2/condor/slot1/dir_70963/userdir/moab-4.6.2/../install/lib/libhdf5.la' seems to be moved

[scopatz]

There's also another (possibly related?) error:

Ahhh This might do it. Shared objects on Macs are not relocatable without some amount of hell. Weird that we are not seeing this for cyclus, et al. So this might be a red herring.

[scopatz]

I actually have no clue what is going on here. Maybe we can try on my laptop today and bring it up with MOAB directly.

[crbates]

This looks like it's an hdf5 build issue to me. I just re-built moab pytaps and pyne on my machine with moab support without any issues (I am on 10.9 though I don't think thats the issue here).

[gidden]

So I follow the exact same strategy that we follow in cyclus, i.e., make an install directory and copy that install directory for fast builds. It's not clear to me why this passes for cyclus and fails for pyne..

On Tue, Mar 11, 2014 at 9:13 AM, Cameron Bates notifications@github.comwrote:

This looks like it's an hdf5 build issue to me. I just re-built moab pytaps and pyne with moab support without any issues (I am on 10.9 though I don't think thats the issue here).

Reply to this email directly or view it on GitHubhttps://github.com/pyne/pyne-ci/issues/2#issuecomment-37299416 .

Matthew Gidden Ph.D. Candidate, Nuclear Engineering The University of Wisconsin -- Madison Ph. 225.892.3192

[gidden]

Not to mention that the slow builds are failing. The only thing wonky there is that the install directory gets copied in the middle of the build process.

On Tue, Mar 11, 2014 at 9:21 AM, Matthew Gidden gidden@wisc.edu wrote:

So I follow the exact same strategy that we follow in cyclus, i.e., make an install directory and copy that install directory for fast builds. It's not clear to me why this passes for cyclus and fails for pyne..

On Tue, Mar 11, 2014 at 9:13 AM, Cameron Bates notifications@github.comwrote:

This looks like it's an hdf5 build issue to me. I just re-built moab pytaps and pyne with moab support without any issues (I am on 10.9 though I don't think thats the issue here).

Reply to this email directly or view it on GitHubhttps://github.com/pyne/pyne-ci/issues/2#issuecomment-37299416 .

Matthew Gidden Ph.D. Candidate, Nuclear Engineering The University of Wisconsin -- Madison Ph. 225.892.3192

Matthew Gidden Ph.D. Candidate, Nuclear Engineering The University of Wisconsin -- Madison Ph. 225.892.3192

[crbates]

I think without install_name_tool fun times you might have problems doing that.

[gidden]

Here is an example with a straight build with the most recent hdf5 (1.8.11) and moab, no copying. I'm officially stumped.

[gidden]

ok, so as a final word:

• moab needed to be built as its latest rc'ed release
• the dyld_fallback_library_path needed to be update (I thought I had done this some time ago, but the moab-specific fast build didn't get the same treatment as the 3 other builds... sigh)

[scopatz]

So is that a sigh of relief? Does it work?!