Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#43083 closed defect (invalid)

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

Reported by: petrrr Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: seanfarley (Sean Farley), michaelld (Michael Dickens)
Port: py-scipy

Description

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

Attachments (2)

py27-scipy.main.log (218.3 KB) - added by petrrr 10 years ago.
py27-scipy+atlas.main.log (265.8 KB) - added by petrrr 10 years ago.
log from a build with +atlas variant

Download all attachments as: .zip

Change History (14)

Changed 10 years ago by petrrr

Attachment: py27-scipy.main.log added

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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?

comment:4 Changed 10 years ago by 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.

Changed 10 years ago by petrrr

Attachment: py27-scipy+atlas.main.log added

log from a build with +atlas variant

comment:5 Changed 10 years ago by petrrr

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

comment:6 Changed 10 years ago by seanfarley (Sean Farley)

Resolution: invalid
Status: newclosed

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.

comment:7 in reply to:  6 ; Changed 10 years ago by 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 ?

comment:8 in reply to:  7 ; Changed 10 years ago by 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

comment:9 Changed 10 years ago by 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.

comment:10 in reply to:  8 Changed 10 years ago by 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.

comment:11 in reply to:  9 Changed 10 years ago by 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.

comment:12 Changed 10 years ago by ned-deily (Ned Deily)

See open issue #34763.

Note: See TracTickets for help on using tickets.