[Ifeffit] Demeter under El Capitan

[Matt Newville]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://millenia.cars.aps.anl.gov/pipermail/ifeffit/attachments/20151112/9625a83b/attachment.html>