[MacPorts] #34562: Py32-numpy universal variant won't install after Macports upgrade to 2.1.0
#34562: Py32-numpy universal variant won't install after Macports upgrade to 2.1.0 -------------------------------------+-------------------------------------- Reporter: david.w.watson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Keywords: | Port: py32-numpy -------------------------------------+-------------------------------------- After Macports upgrade to 2.1.0 and 2.1.1, my py32-numpy install was reported as broken, even though it worked prior to the macports 2.1.0 update. Macports tried to fix it, but failed. Finally got it installed without the universal variant. Universal variant still won't install. By the way, the same macports 2.1.0 update also completely broke my Root install so that I had no choice but to remove it. -- Ticket URL: <https://trac.macports.org/ticket/34562> MacPorts <http://www.macports.org/> Ports system for Mac OS
#34562: Py32-numpy universal variant won't install after Macports upgrade to 2.1.0 -------------------------------------+-------------------------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Keywords: | Port: py32-numpy -------------------------------------+-------------------------------------- Changes (by macsforever2000@…): * owner: macports-tickets@… => dh@… * cc: dh@…, openmaintainer@… (removed) Comment: It is not useful to Cc openmaintainer. FYI, ROOT works fine for me in Macports 2.1.1. You should file a separate ticket for it if you want that looked at. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#34562: Py32-numpy universal variant won't install after Macports upgrade to 2.1.0 -------------------------------------+-------------------------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Keywords: | Port: py32-numpy -------------------------------------+-------------------------------------- Comment(by jmr@…): From the log it looks like the variants being used are +atlas +gcc46 +universal? (It makes it easier if you mention this up front.) -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#34562: Py32-numpy universal variant won't install after Macports upgrade to 2.1.0 -------------------------------+------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Resolution: | Keywords: Port: py32-numpy | -------------------------------+------------------- Changes (by ram@…): * cc: ram@… (removed) -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#34562: py-numpy universal variant destroot failure -------------------------------+------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Resolution: | Keywords: Port: py-numpy | -------------------------------+------------------- Changes (by ryandesign@…): * cc: michaelld@…, macports1@…, poorsod@…, mojca@…, david.t.kerns@…, matthew.alexander.fraser@…, cmutel@…, mr.mcox@…, mark.chilenski@…, charlie.ellison01@…, bczapp@…, jeremyhu@…, chmitchell@…, chief1983@… (added) * port: py32-numpy => py-numpy Comment: Has duplicates #37240, #38721, #38750, #40037, #41114. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: py-numpy universal variant destroot failure -------------------------------+------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Resolution: | Keywords: Port: py-numpy | -------------------------------+------------------- Comment (by chief1983@…): I don't know how 41114 is a duplicate, since this ticket is 18 months old, and this issue only just cropped in py27-numpy in the 1.7.1_1 release. I had the universal variant of 1.7.1_0 installed just fine. I did recently upgrade Xcode to 5.0.1, and the error in my log seemed to be a clang linking issue. I wonder if the issue the reporter of 41114 and/or I are seeing is related to a new change in Xcode5 or py27-numpy@1.7.1_1. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: py-numpy universal variant destroot failure -------------------------------+------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Resolution: | Keywords: Port: py-numpy | -------------------------------+------------------- Comment (by david.w.watson@…): This issue is with py27-numpy@1.7.1_1. I am running 10.8.5 with Xcode 4.6.3, but my py27-numpy is compiled with Macports 4.7 compiler. py27_numpy 1.7.1_0 compiled and installed just fine. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: py-numpy universal variant destroot failure -------------------------------+------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Resolution: | Keywords: Port: py-numpy | -------------------------------+------------------- Comment (by jeremyhu@…): Replying to [comment:5 chief1983@…]:
I don't know how #41114 is a duplicate, since this ticket is 18 months old, and this issue only just cropped in py27-numpy in the 1.7.1_1 release. I had the universal variant of 1.7.1_0 installed just fine.
Yes, something external to py-numpy caused this between when 1.7.0_0 was released and when 1.7.0 was just revbumped.
Edit: I suppose the log errors do look similar though. But what would keep causing this issue to crop up after not happening for so long?
It *HAS* been happening for a long time, but you got lucky in that you had 1.7.0_0 installed before this bug affected you. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: py-numpy universal variant destroot failure -------------------------------+------------------- Reporter: david.w.watson@… | Owner: dh@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.1.1 Resolution: | Keywords: Port: py-numpy | -------------------------------+------------------- Changes (by jeremyhu@…): * priority: Normal => High -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: py-numpy universal variant destroot failure -------------------------------+----------------------------- Reporter: david.w.watson@… | Owner: jmr@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+----------------------------- Changes (by jeremyhu@…): * owner: dh@… => jmr@… * component: ports => base * port: py-numpy => * milestone: => MacPorts Future Comment: py-numpy workaround in r113172 The issue is that base seems to have stopped setting CC et al in destroot.env -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:12> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot -------------------------------+----------------------------- Reporter: david.w.watson@… | Owner: jmr@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+----------------------------- -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:13> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot -------------------------------+----------------------------- Reporter: david.w.watson@… | Owner: jmr@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+----------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: Replying to [comment:12 jeremyhu@…]:
The issue is that base seems to have stopped setting CC et al in destroot.env
I'm not aware that base ever set CC et al anytime other than the configure phase. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot -------------------------------+----------------------------- Reporter: david.w.watson@… | Owner: jmr@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+----------------------------- Comment (by jeremyhu@…): Replying to [comment:14 ryandesign@…]:
Replying to [comment:12 jeremyhu@…]:
The issue is that base seems to have stopped setting CC et al in destroot.env
I'm not aware that base ever set CC et al anytime other than the configure phase.
Then I'm curious how this (or other ports which cache build environments to invalidate and rebuild) worked in the past. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:15> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot -------------------------------+----------------------------- Reporter: david.w.watson@… | Owner: jmr@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+----------------------------- Comment (by jmr@…): Replying to [comment:12 jeremyhu@…]:
py-numpy workaround in r113172 It doesn't look like that would actually fix +universal, as the archflags are being queried before the universal variant is declared.
-- Ticket URL: <https://trac.macports.org/ticket/34562#comment:16> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot -------------------------------+----------------------------- Reporter: david.w.watson@… | Owner: jmr@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+----------------------------- Comment (by jmr@…): Replying to [comment:15 jeremyhu@…]:
Then I'm curious how this (or other ports which cache build environments to invalidate and rebuild) worked in the past. Presumably by setting destroot.env the same as build.env.
-- Ticket URL: <https://trac.macports.org/ticket/34562#comment:17> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot -------------------------------+-------------------------------- Reporter: david.w.watson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+-------------------------------- Changes (by jmr@…): * owner: jmr@… => macports-tickets@… -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:18> MacPorts <http://www.macports.org/> Ports system for OS X
#34562: CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot -------------------------------+-------------------------------- Reporter: david.w.watson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: MacPorts Future Component: base | Version: 2.1.1 Resolution: | Keywords: Port: | -------------------------------+-------------------------------- Comment (by michaelld@…): Setting all of these variables during destroot would, I would guess, positively impact only a very small subset of all ports; and, it might negatively impact any number of ports. In my experience, this subset contains a bunch of Python ports such as SciPy and NumPy, but I'm sure there are other, non-Python ports too which require at least a few of these. That said, if I look at all of the ports I maintain or will be shortly, maybe 5% of them actually require these flags. I'd prefer to not have to deal with these flags otherwise, since they might impact the install of currently well-working ports; flags are used internally in strange, sometimes unexpected ways, such as what I found out yesterday about not including LD archflags during configure in qt4-mac, because qmake somehow internalizes them (and, I looked through the qmake source code and can't figure out where it is). So, my vote is to require including these on a port-by-port basis, not globally; I'd rather have to opt-in than opt-out. -- Ticket URL: <https://trac.macports.org/ticket/34562#comment:19> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts