CC, CXX, OBJC, LDFLAGS, CFLAGS, CXXFLAGS, OBJCFLAGS should be set during destroot

[watsodw]

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.

[mf2k (Frank Schima)]

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.

[jmroot (Joshua Root)]

From the log it looks like the variants being used are +atlas +gcc46 +universal? (It makes it easier if you mention this up front.)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicates #37240, #38721, #38750, #40037, #41114.

[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.

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?

[mr.mcox@…]

Cc Me!

[mr.mcox@…]

Cc Me!

[larryv (Lawrence Velázquez)]

Cc Me!

[watsodw]

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.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to 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.

[jeremyhu (Jeremy Huddleston Sequoia)]

py-numpy workaround in r113172

The issue is that base seems to have stopped setting CC et al in destroot.env

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ryandesign@…:

Replying to 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.

[jmroot (Joshua Root)]

Replying to 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.

[jmroot (Joshua Root)]

Replying to 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.

[michaelld (Michael Dickens)]

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.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Between r130565, r143449, and r143452, I believe this issue has been resolved.
The default value of python.consistent_destroot can easily be set to no if desired.

[barracuda156]

We are back to the similar problem, essentially: build system does not pick right compiler: #68908