[MacPorts] #42676: py27-scipy @0.13.3_0: import scipy.linalg fails with Symbol not found: _acc_cdotc_sub__

[MacPorts]

#42676: py27-scipy @0.13.3_0: import scipy.linalg fails with Symbol not found:
_acc_cdotc_sub__
-----------------------------+--------------------
  Reporter:  andre.girard@…  |      Owner:  sean@…
      Type:  defect          |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.2.1
Resolution:                  |   Keywords:
      Port:  py-scipy        |
-----------------------------+--------------------

Comment (by Peter.Danecek@…):

 Note that I had no problems before (not sure but probably installed the
 binary package), but trying to reproduce problems of colleges. So, I too
 some time and did various test on my machine:

 {{{
 Retina, 15-inch, Early 2013
 2.7 GHz Intel Core i7
 OS X 10.8.5 (12F45)
 Xcode 4.6.2
 Build version 4H1003
 MacPorts 2.2.1
 }}}

 Summary:

 1. With the binary packages all seems to works just fine: all tests pass
 or kownfail;
 2. Build from source (atlas was active): compiles well, but test bombs. It
 looks like the build is using atlas library even if variant +atlas is
 **not** requested;
 3. Build from source, after atlas is deactivated: compiles well, but test
 show the same behavior as reported here, symbol `_acc_cdotc_sub__ `
 unresolved.
 4. Build from source, now atlas activated again and build with `+atlas`
 variant: testing shows same behavior as 2.

 So my preliminary conclusions:

 (1) The binary packages still works for me (and probably for most others,
 but not all). However, source builds are broken and have the reported
 problem (not sure if this is generally true, or only in some cases).
 Therefore, I would assume that the "solution" to use `+gcc48` (default
 variant) instead of `+gcc47` or any other compiler, is **not** really
 related to the compiler choice. Instead, this caused the binary package to
 be fetched instead of building from source (which is broken).

 (2) There are two **unrelated** issues with **ATLAS**:
 * If atlas is activated, scipy **always** builds against atlas, ignoring
 whether `+atlas` variant is requested or not; However, if it is not
 requested the dependency is not registered correctly;
 * `scipy` build against atlas (w and w/o the `+atlas` variant) is broken
 at least on some platforms;

 I propose to stick with problem (1) here, and I will file a independent
 ticket for problems (2).


 Now back to problem (1):

 We would need to understand why py-scipy builds correctly on the buildbot,
 and fails on other machines. Is it on all or only on some? What is the
 difference what causes this.

 The build is from `04-Feb-2014`. r117983 only adds py34 subport and this
 was build `25-Mar-2014`;
 Would it still build correctly on the bot? Or might this be a regression?
 r117037 could be relevant here (no revision bump) or some change in base?
 Are there any relevant ones?

 Any possibility to test this without overwriting the current binary
 package?

-- 
Ticket URL: <https://trac.macports.org/ticket/42676#comment:25>
MacPorts <http://www.macports.org/>
Ports system for OS X