Intermittent failures building Python modules: unable to execute -DNDEBUG

[wiml@…]

I'm not sure what's going on here. In all cases, quitting 'port' and restarting it and reissuing the 'install' command succeeds. But one time in five or so, building a Python-based port fails, apparently because it's set $CC to an empty string or something like that:

[var/root] > install py25-tkinter
--->  Building py25-tkinter with target build
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py25-tkinter/work/Python-2.5.1/Modules" && /opt/local/bin/python2.5 setup.py build " returned error 1
Command output: running build
running build_ext
building '_tkinter' extension
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DWITH_APPINIT=1 -I/opt/local/include -I/opt/local/include/python2.5 -c _tkinter.c -o build/temp.macosx-10.3-i386-2.5/_tkinter.o
unable to execute -DNDEBUG: No such file or directory
error: command '-DNDEBUG' failed with exit status 1

Error: Status 1 encountered during processing.
[var/root] > ^D
Goodbye
root@slowpoke# /opt/local/bin/port                                                                                                                                                      ~
MacPorts 1.600
Entering interactive mode... ("help" for help, "quit" to quit)
[var/root] > install py25-tkinter
--->  Building py25-tkinter with target build
--->  Staging py25-tkinter into destroot
--->  Installing py25-tkinter 2.5.1_0
--->  Activating py25-tkinter 2.5.1_0
--->  Cleaning py25-tkinter
[var/root] > ^D

It's not the same port(s) each time, seems to be random.

Leopard 10.5.1/9B18, MacPorts 1.600, freshly installed and updated.

[jmr@…]

Some sort of race in setuptools perhaps?

[raimue@…]

Has duplicate #14542.

[afb@…]

It seems that those python ports are expecting $CC to be set in build as well as in configure, and fall back to random values such as "" or "cc" or "/usr/bin/gcc-4.0" when it isn't. This probably also explains why rerunning the build sometimes succeeds, if something else was adding a $CC to the environment that can be picked up as a lucky guess second time.

Supposedly base wants to be enhanced to support CC in non-configure builds ?

Workaround meanwhile is adding build.env="CC=gcc" while building the port.

[renatoc@…]

I can also confirm this bug, while trying to install gtk2 and dependencies. I only noted this problem after uninstalling MacPorts (like stated in the !FAQ) and installing it again.

Anyway, I worked around this by setting

 extra_env       CC

in macports.conf

[florian.ebeling@…]

This is really an annoying issue, and it persists in trunk. Has anybody looked into this already?

[florian.ebeling@…]

Cc Me!

[jmr@…]

Replying to florian.ebeling@gmail.com:

This is really an annoying issue, and it persists in trunk. Has anybody looked into this already?

See this ML thread. It appears to be a bug in the environment handling in Leopard's Tcl.

[spambox@…]

I can confirm this attempting to build deluge.

--->  Building py25-hashlib with target build
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py25-hashlib/work/Python-2.5.2/Modules" && /opt/local/bin/python2.5 setup.py build " returned error 1
Command output: running build
running build_ext
building '_hashlib' extension
creating build
creating build/temp.macosx-10.3-i386-2.5
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt/local/include -I/opt/local/include/python2.5 -c _hashopenssl.c -o build/temp.macosx-10.3-i386-2.5/_hashopenssl.o
unable to execute -DNDEBUG: No such file or directory
error: command '-DNDEBUG' failed with exit status 1

Reissuing the port install deluge command built py25-hashlib fine the second time.

[afb@…]

Workaround implemented in r36722

[macports@…]

I'm still getting these errors (#15608 #15609 #15612), is r36722 in the current release (MacPorts 1.6 + port selfupdate)?

[jmr@…]

Replying to macports@henrik.synth.no:

is r36722 in the current release (MacPorts 1.6 + port selfupdate)?

No, that's why this ticket isn't closed.

[blb@…]

Cc Me!

[tolsen@…]

Cc Me!

[pub1@…]

Cc Me!

[brunogirin@…]

Cc Me!

[macports@…]

Cc Me!

[Ricardo.Cordeiro@…]

Cc Me!

[lars@…]

Cc Me!

[peter.arrenbrecht@…]

Cc Me!

[peter.arrenbrecht@…]

Cc Me!

[vpribish@…]

Cc Me!

[iacanay@…]

Cc Me!

[sirpete@…]

Cc Me!

[jmr@…]

This is still not completely fixed in trunk @ r40402. I just ran port upgrade outdated, which upgraded two ports, first ImageMagick and then py25-numpy. The latter failed with a classic env bug error: sh: -fno-strict-aliasing: command not found, and succeeded after a clean.

[terry@…]

Cc Me!

[fhwi93ne@…]

Cc Me!

[dhelder@…]

Cc Me!

[blb@…]

Since there's still at least one edge case (around python modules), placing in the 1.7.0 milestone so we can deal with it for that.

[ram@…]

Cc Me!

[blb@…]

This should now be finally fixed as of r41603, fortunately nethack and python modules were quite good at hitting this bug so gave good test cases; both now build quite smoothly in testing, but failed every time without the fix.

[afb@…]

Replying to blb@…:

This should now be finally fixed as of r41603, fortunately nethack and python modules were quite good at hitting this bug so gave good test cases; both now build quite smoothly in testing, but failed every time without the fix.

Were you able to actually add it to the test case too ?

http://trac.macports.org/browser/trunk/base/src/pextlib1.0/tests/unsetenv.tcl

[blb@…]

Replying to afb@…:

Were you able to actually add it to the test case too ?

Test case for this added in r41638.

The issue where info exists env(somevar) returned true even after unsetenv somevar fixed in r41639.