[Ifeffit] Demeter under El Capitan

George Sterbinsky GeorgeSterbinsky at u.northwestern.edu
Thu Nov 12 19:59:44 CST 2015


Hi Matt,

I am just guessing here, but Zack and Manuel both mention installing
XQuartz, whereas you mention installing xorg-server. While Demeter should
work with either, perhaps on the new OS there is a problem installing
Demeter with xorg-server and one has to go with xQuartz. Have you tried
installing xQuartz or following Zack's instructions exactly? That is
installing xQuartz and not installing xorg-server at all?

George

On Thu, Nov 12, 2015 at 2:00 PM, Zack Gainsforth <zackg at berkeley.edu> wrote:

> Hi Matt,
>
> I have to agree it is a real annoyance to have to rebuild from scratch —
> and no there isn’t any great reason why that is better.  I’ve always chimed
> to myself “a macports version is better than no version” whenever I get an
> arcane fail message from macports.
>
> In the worst case, mac users can always run demeter from within a virtual
> machine (VMware, Parallels or VirtualBox).
>
> On the other hand, there is a method of using macports to produce a dmg
> (mac install file).  I have never used it, but the command goes like:
>
> sudo port mdmg demeter
>
> https://guide.macports.org/chunked/using.binaries.html
>
> My guess is that there would be a bit of development to make that work,
> but it is worth looking into.  Then, we build it once for each new version
> and release a dmg.
>
> Zack
>
> On Nov 12, 2015, at 10:53 AM, Matt Newville <newville at cars.uchicago.edu>
> wrote:
>
> Hi Manuel,
>
>
> On Thu, Nov 12, 2015 at 3:45 AM, Muñoz Manuel <
> manuel.munoz at ujf-grenoble.fr> wrote:
>
>> Dear all,
>>
>> Thank you for your feedbacks.
>>
>> After several attempts, I was finally successful with the installation of
>> Demeter. I attach a log file summarizing the different steps I experienced
>> (and a screenshot of the main window). I guess step 2 and 5 would have been
>> enough:
>> xcode-select --install
>> sudo port install demeter
>>
>> Indeed, several hours were required for the whole installation procedure
>> (more than 9 hours, but my internet connection is quite slow at home...).
>>
>> I can now execute athena from the terminal, and apparently it works fine.
>> However, I observe a strange behavior : After athena is running, I must
>> click once on the terminal window before the main menus are active in
>> Demeter (File, Group, Energy, etc.). But when we know that, it’s ok.
>>
>> And the most important, I don’t have any graphical window to display the
>> spectra. Would you have any suggestion? (Xquartz and Aquaterm are already
>> installed on my computer).
>>
>> Thank you again for your help!
>> Manuel
>>
>>
>
> That's great that it worked for you.
>
> I tried again with a completely fresh install of MacPorts, starting a few
> days ago, and again, it did not work for me.  To be clear, I have Xcode and
> command-line tools (as from  xcode-select --install ) installed, and can
> compile and build many programs.
>
> Starting with installing the latest MacPorts package, the initial
>
>   ~> sudo port -v selfupdate
>
> works fine. Similar to what you saw,
>
>   ~> sudo port install xorg-server
>
> also works, but takes at least 8 hours.  Really.    For me
>
>   ~> sudo port install demeter
>
> took about two days of running close to full time,  And it failed.  As I
> mentioned earlier, the demeter package depends on llvm, libgcc, gcc4.9 and
> gcc5.2 all of which must be built FROM SOURCE, which is completely, utterly
> stupid.  Really, this alone pretty much convinces me that MacPorts is not a
> good solution for distributing Athena for Mac OS X.  More later.   Anyway
> building all these compilers and effectively building an isolated BSD
> user-space from source did work, and most of the dependencies and perl
> modules correctly installed.
>
> What failed to install was perl-5.22-pdl.  This gave a compilation error
> using some GSL component.  I uninstalled the gsl port, successfully
> installed the rest of the perl modules, and got the point where
>
>   ~> sudo port -v install demeter
>
> reports
>   --->  Computing dependencies for demeter....
>   --->  Dependencies to be installed: p5.22-pdl gsl p5.22-pdl-stats
>
> That is, all other required components (including the wxPerl package) were
> installed.   GSL (2.0) does install, but p5.22-pdl fails with with
>
> ==========================
> ...
> /usr/bin/clang -c
> "-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-pdl/p5.22-pdl/work/PDL-2.013/Basic/Core"
> -I/opt/local/include -pipe -Os -fno-common -DPERL_DARWIN
> -I/opt/local/include -fno-strict-aliasing -fstack-protector-strong
> -I/opt/local/include -arch x86_64 -O3   -DVERSION=\"2.013\"
> -DXS_VERSION=\"2.013\"
> "-I/opt/local/lib/perl5/5.22/darwin-thread-multi-2level/CORE"   ELLINT.c
> ELLINT.xs:1736:159: error: too many arguments to function call, expected
> 4, have 5
> GSLERR(gsl_sf_ellint_D_e,((phi_datap)[0] PDL_COMMENT("ACCESS()")
> ,(k_datap)[0] PDL_COMMENT("ACCESS()") ,(n_datap)[0] PDL_COMMENT("ACCESS()")
> ,GSL_PREC_DOUBLE,&r))
>
> ~~~~~~~~~~~~~~~~~
> ^~
> ./../gslerr.h:5:37: note: expanded from macro 'GSLERR'
> #define GSLERR(x,y) if ((status = x y)) {snprintf(buf,200,"Error in %s:
> %s", #x, gsl_strerror(status));barf("%s", buf);}
>                                     ^
> /opt/local/include/gsl/gsl_sf_ellint.h:84:1: note: 'gsl_sf_ellint_D_e'
> declared here
> int gsl_sf_ellint_D_e(double phi, double k, gsl_mode_t mode, gsl_sf_result
> * result);
> ^
> 1 error generated.
> ==========================
>
> I could not find anything about this with simple searches on the MacPorts
> or PDL sites, but haven't looked in great detail.
> I haven't looked in great detail at what might workaround or solve this
> issue.
>
> As I've said before, I find the "install from source" nature of MacPorts
> to be very problematic, and believe we cannot use this approach.  Telling
> users to set aside 3 days to install Athena and Artemis just doesn't seem
> reasonable, and that assumes that it works.
>
> A main feature of Mac OS X is that it is highly controlled.  Binary
> compatibility should be (and usually is) no problem for a known version of
> OS X.  Thus, the fact that MacPorts EVER installs from source is really
> hard for me to understand -- this is exactly the case where it is least
> necessary.  That demeter requires 3 separate C compilers to be installed
> (in addition to the predictable vendor-supplied compiler already available
> with the system) is very weird.   I don't understand why this is necessary.
>
> I've looked into using Brew or CitrusPerl, but getting modern versions of
> these to work with wxPerl seems challenging.  I've tried to figure out what
> MacPorts does to install wxPerl that the others don't, but have had a
> difficult time figuring out where the MacPorts Portfiles actually are.
> Like I said, I haven't looked into this in great detail, but MacPorts is
> not very transparent.  I'm also trying to assess using Brew (which,
> conveniently installs binaries, but inconveniently uses /usr/local instead
> of its own folder) or other options for Larch.
>
> Suggestions on the best way to do these things would be greatly
> appreciated.
>
> --Matt Newville
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>
>
>
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20151112/7b4eeaa9/attachment.html>


More information about the Ifeffit mailing list