Opened 8 years ago

Closed 7 years ago

#51250 closed defect (fixed)

py-numpy: Build failure with +atlas and version 1.11.0_0

Reported by: mf2k (Frank Schima) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: dh@…, stromnov (Andrey Stromnov), petrrr, skymoo (Adam Mercer), shapovalow@…, dliessi (Davide Liessi), EJFielding (Eric Fielding), mark.chilenski@…, astrofitz (Michael Fitzgerald), Veence (Vincent), larryv (Lawrence Velázquez), posita (Matt Bogosian), captainproton1971 (Captain Proton), astroboylrx (Rixin Li)
Port: py-numpy

Description

I'm trying to update both py35-numpy and py27-numpy to the latest version 1.11.0_0 but neither build for me. I'm attaching the log for py35-numpy.

Here are the variants I am using:

$ port installed py35-numpy
The following ports are currently installed:
  py35-numpy @1.10.4_0+atlas+gcc5 (active)

Attachments (2)

main.log (164.6 KB) - added by mf2k (Frank Schima) 8 years ago.
patch-numpy_rpath.diff (1.3 KB) - added by michaelld (Michael Dickens) 7 years ago.

Download all attachments as: .zip

Change History (31)

Changed 8 years ago by mf2k (Frank Schima)

Attachment: main.log added

comment:1 Changed 8 years ago by mf2k (Frank Schima)

It looks like the error could be:

:info:build ld: unknown option: -rpath=/opt/local/lib

comment:2 Changed 8 years ago by michaelld (Michael Dickens)

Well that's just ducky. I tested for default variants as well as +openblas (I don't have atlas installed, and use OpenBLAS instead); let me test for +gcc5 & see what comes of it.

comment:3 Changed 8 years ago by mf2k (Frank Schima)

It appears that the atlas variant is the problem. It built fine for me without it.

$ port installed py35-numpy
The following ports are currently installed:
  py35-numpy @1.11.0_0+gcc5 (active)

comment:4 Changed 8 years ago by michaelld (Michael Dickens)

Agreed. I just tested with +gcc5 +gfortran and +gcc5 +gfortran +openblas, and both worked. I don't have atlas installed. Maybe you can figure out the issue? Maybe it's some commit since the prior release that added in the rpath stuff?

comment:5 Changed 8 years ago by mf2k (Frank Schima)

This stuff is way over my head. All I know is that +atlas worked with the previous version of numpy.

comment:6 Changed 8 years ago by mf2k (Frank Schima)

Summary: py-numpy: Build failure updating to version 1.11.0_0py-numpy: Build failure with +atlas and version 1.11.0_0

comment:7 Changed 8 years ago by michaelld (Michael Dickens)

OK. I'll get atlas installed & try to figure out what's going on. No promises on timing.

comment:8 Changed 8 years ago by stromnov (Andrey Stromnov)

Cc: stromnov@… added

Cc Me!

comment:9 Changed 8 years ago by michaelld (Michael Dickens)

The issue seems to be that when +atlas is specified, the linker use is MacPorts' "ld" ($preifx/bin/ld), which supports the rpath syntax "-rpath PATH" whereas GNU linkers support the syntax "-rpath=PATH". Thus, I'm guessing when using +atlas on 10.9 and newer (libc++), GCC will use MacPorts "ld" whereas on 10.8 and prior (libstdc++), it will use GCC's linker -- just a guess, since I can't easily test. I think just patching the specific files to use " " instead of "=" will work for most folks. But, who knows? I've no idea why 1.10.4 worked by 1.11.0 does not. This "rpath" stuff didn't change, so it's the consequence of an indirect change. I'll attach a patch here for folks to try, when I get a chance.

Last edited 8 years ago by michaelld (Michael Dickens) (previous) (diff)

comment:10 Changed 8 years ago by petrrr

Cc: petr@… added

Cc Me!

comment:11 Changed 8 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:12 Changed 8 years ago by bkappes@…

Apologies ahead for not knowing the proper way to do this, but I moved into the build directory for py27-numpy and ran:

grep -R "rpath=" * | grep -v "Binary file" | awk -F':' '{print $1}' | xargs sed -i.bkp -E 's/rpath=/rpath /g'

as Michael suggests, replacing "rpath=" with "rpath ". Subsequent upgrade of py27-numpy was successful.

I'm sorry I'm unable to put together a more robust fix.

comment:13 Changed 8 years ago by shapovalow@…

Cc: shapovalow@… added

Cc Me!

comment:14 Changed 8 years ago by dliessi (Davide Liessi)

Cc: davide.liessi@… added

Cc Me!

comment:15 Changed 8 years ago by dliessi (Davide Liessi)

Same error on 10.6.8.

comment:16 Changed 8 years ago by josephsacco

The same rpath issue exists when building py[27|34]-numpy on a G4-based PPC running OSX 10.5.8 using +atlas and +gcc49.

The two errant files are

./numpy/distutils/fcompiler/gnu.py

and

./numpy/distutils/fcompiler/intel.py [not relevant for PPC's, but the same issue]

Replacing "rpath=" with "rpath " in these files allows numpy to build.

Constructing a patch is simple. Knowing what to add to the Portfile is another issue that I will defer to people like Michael who actually understand this stuff.

-Joseph

comment:17 Changed 8 years ago by EJFielding (Eric Fielding)

Cc: Eric.J.Fielding@… added

Cc Me!

comment:18 Changed 8 years ago by EJFielding (Eric Fielding)

I have been using the +atlas variant with py27-numpy for a long time, but got the same error after upgrading to 1.11.0. I forget now why I was using +atlas, so I switched to +openblas and it now builds OK.

comment:19 Changed 8 years ago by mark.chilenski@…

Cc: mark.chilenski@… added

Cc Me!

comment:20 Changed 8 years ago by astrofitz (Michael Fitzgerald)

Cc: astrofitz@… added

Cc Me!

comment:21 Changed 8 years ago by mf2k (Frank Schima)

Cc: vince@… added

Cc'ing atlas maintainer for possible comment.

comment:22 Changed 8 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

comment:23 Changed 8 years ago by posita (Matt Bogosian)

Cc: mtb19@… added

Cc Me!

comment:24 Changed 8 years ago by stromnov (Andrey Stromnov)

comment:25 Changed 8 years ago by captainproton1971 (Captain Proton)

Cc: captainproton1971@… added

Cc Me!

comment:26 Changed 7 years ago by astroboylrx (Rixin Li)

Cc: astroboylrx@… added

Cc Me!

Changed 7 years ago by michaelld (Michael Dickens)

Attachment: patch-numpy_rpath.diff added

comment:27 Changed 7 years ago by michaelld (Michael Dickens)

This issue is related to #1419.

I just attached a patch for NumPy that should fix this build error. It should work on at least 10.9 and newer (libc++). I don't have a 10.[6-8] box around for testing (libstdc++ via GCC 4.2.1). I did verify that the rpath setting works on a modern Linux box running GCC 4.9 ("-Wl,-rpath -Wl,"/R/P/A/T/H", where "/R/P/A/T/H" is the actual desired rpath, in ""s to allow for spaces in directory names).

Could others please test & verify? You'll need to do roughly the following (assuming the patch is in ~/Downloads/patch-numpy_rpath.diff):

pushd $(port dir py27-numpy)
sudo patch -p0 < ~/Downloads/patch-numpy_rpath.diff
sudo port upgrade py27-numpy

assuming that works, then do:

sudo patch -R -p0 < ~/Downloads/patch-numpy_rpath.diff

comment:28 Changed 7 years ago by seanfarley (Sean Farley)

Yep, this patch fixes it for me. I would say go ahead and push it.

comment:29 Changed 7 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

OK. done in r153885.

Note: See TracTickets for help on using tickets.