py27-scipy @0.13.3: fails to build on OS X 10.7

[petrrr]

I was trying to install software depending on py27-scipy and found a issue with py27-scipy.

The port was first installed as binary packages but failed the rev-upgrade test and triggered a source build which fails.

The attached main.log is from a clean source build.

Xcode 4.6.3
Build version 4H1503

[ryandesign (Ryan Carsten Schmidt)]

Out of curiosity, what is /opt/local/bin/gfortran, what port installed it, what version is it? Because the port seems to want to use gcc48's gfortran, but if /opt/local/bin/gfortran is something different, that might be a problem.

[petrrr]

Right now, I cannot say for sure because I have no access to that system. For what I'd assume gcc48 was installed as dependency of some other port which requires Fortran and gfortran is set to that. Will check this as soon as I get to the machine again.

[petrrr]

@ryandesign: You are probably deferring to ​L3537 from main.log, right? I checked with my colleague the setup gfortran setup and there seems be nothing strange.

/opt/local/bin/gfortran points to -> /opt/local/bin/gfortran-mp-4.8. The link was created by the port select mechanism:

port select gcc
Available versions for gcc:
	gcc42
	llvm-gcc42
	mp-gcc48 (active)
	none

It is the fortran compiler used normally, is in the $PATH, all normal here.

However I guess, the real problem is more related to ​L3571, that is numpy.distutils expects a non existing environment variable FARCHFLAGS and the exception is not handled.

But why: (1) The binary package is not valid? (2) This problem occurs only on the given system?

[petrrr]

After uninstalling all dependencies I was able to get a binary install, which does not trigger a rebuild. Was also able to install py27-obspy depending on this, but get run-time errors when testing (​http://test.obspy.org/13478/).

Will report on the scipy tests as soon as I have them available, but I guess there will be quite some errors.

[petrrr]

log from a build with +atlas variant

[petrrr]

I attached a main.log from a build with +atlas variant requested. The problem looks identical.

[seanfarley (Sean Farley)]

Unless I am missing something, this is invalid because you are mixing python packages from the system which isn't supported in MacPorts. It seems you have numpy installed into: /Library/Python/2.7/site-packages/numpy-override.

[petrrr]

Replying to sean@…:

Unless I am missing something, this is invalid because you are mixing python packages from the system which isn't supported in MacPorts. It seems you have numpy installed into: /Library/Python/2.7/site-packages/numpy-override.

Sean, I am not sure I understand your comment completely.

Now, that you are pointing to it I see the reference to system /Library as well, but I have no idea how it is tight in.

You are stating "invalid because you are mixing python packages from the system". But I do not see what I am doing wrong or at least I am not doing this intentionally. When I get to the machine, I will check the content of /Library/Python/2.7/site-packages/. But to my understanding, as long as I use MacPort, this content should be ignored, but apparently it is no.

So why this ticket is invalid ?

[seanfarley (Sean Farley)]

Replying to Peter.Danecek@…:

Replying to sean@…:

Unless I am missing something, this is invalid because you are mixing python packages from the system which isn't supported in MacPorts. It seems you have numpy installed into: /Library/Python/2.7/site-packages/numpy-override.

Sean, I am not sure I understand your comment completely.

Now, that you are pointing to it I see the reference to system /Library as well, but I have no idea how it is tight in.

You are stating "invalid because you are mixing python packages from the system". But I do not see what I am doing wrong or at least I am not doing this intentionally. When I get to the machine, I will check the content of /Library/Python/2.7/site-packages/. But to my understanding, as long as I use MacPort, this content should be ignored, but apparently it is no.

So why this ticket is invalid ?

I can understand your confusion. MacPorts can't (yet?) sandbox itself from having its subprocesses access things outside /opt/local (or where ever MacPorts is installed). So, lots of configure and python scripts try to find everything it can on the system. In this case, someone on the machine installed a package outside of MacPorts that contains numpy. This package is interfering with the build of scipy. Basically, it is equivalent to installing something into /usr/local,

​https://trac.macports.org/wiki/FAQ#usrlocal

[petrrr]

Thanks Sean, your understanding is clear now

I knew there could arise issues from installing libs in System paths like /usr/local. But honestly I did not think this applies to Python as well. I assumed the correct "site-packages" to use is determined by the interpreter you are actually calling, and for a py27 subport I would have expected it to be python2.7 from Macports. And I you would like to use packages at other locations, these would need to be tight in explicitly.

For the rest: It is very probable that the machine is quite messy, there were Python versions, related links and variables all over. I purges some of this stuff, but for sure not all.

[neverpanic (Clemens Lang)]

Replying to sean@…:

MacPorts can't (yet?) sandbox itself from having its subprocesses access things outside /opt/local (or where ever MacPorts is installed).

It will gain that ability in 2.3 with trace mode, but that has to be activated manually using port -t.

[seanfarley (Sean Farley)]

Replying to Peter.Danecek@…:

Thanks Sean, your understanding is clear now

I knew there could arise issues from installing libs in System paths like /usr/local. But honestly I did not think this applies to Python as well. I assumed the correct "site-packages" to use is determined by the interpreter you are actually calling, and for a py27 subport I would have expected it to be python2.7 from Macports. And I you would like to use packages at other locations, these would need to be tight in explicitly.

For the rest: It is very probable that the machine is quite messy, there were Python versions, related links and variables all over. I purges some of this stuff, but for sure not all.

Unfortunately, that assumption is wrong. As cal mentioned above, you can try port -t when MacPorts 2.3 comes out (or install from a trunk checkout). The safer (though, more tedious) approach would be to clean this system thoroughly. The usual suspects are:

• /usr/local
• Ruby packages
• Python packages
• Haskell packages

Sometimes, you can use the pkg command to determine what packages were installed previously. Good luck.

[ned-deily (Ned Deily)]

See open issue #34763.