When the linker command begins with env, plus some environment 
settings, and when the target is c++, the modified linker command 
should place the c++ command in the proper place, which is not the 
first element of the linker array.

The following seems to be fix the problem:

--- unixccompiler.py.orig       2004-08-29 09:45:13.000000000 -0700
+++ unixccompiler.py    2005-03-06 16:36:05.000000000 -0800
@@ -172,7 +172,12 @@
                 else:
                     linker = self.linker_so[:]
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
+                    i = 0
+                    if os.path.basename(linker[0]) == "env":
+                        i = 1
+                        while '=' in linker[i]:
+                            i = i + 1
+                    linker[i] = self.compiler_cxx[0]
                 self.spawn(linker + ld_args)
             except DistutilsExecError, msg:
                 raise LinkError, msg

Logged In: YES 
user_id=21627

Can you please give a specific example of what you did, what
you expected to happen, and what happened instead (precise
error messages, etc)?

Logged In: YES 
user_id=1233904

I was trying to build wxPython on Mac OS X.  Without the change, it would 
compile all .c files, then when it tried to link, it would execute a command that 
looked like:

g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ...

and fail.  This is because it overwrote "env" with "g++".  It needs to skip the 
env and its arguments, and replace (in this case) the c++.

Logged In: YES 
user_id=21627

Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come
from? I cannot find it in the Python build process or
distutils. So if it is in the wxPython setup.py, it sure
must be a bug in that setup.py, no?

Logged In: YES 
user_id=1233904

I don't know the internal of python all that well, but I know that python (and 
perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the 
link command, because this environment variable is required to enable the 
dynamic lookup symbol resolution feature in the linker (used with two-level 
namespaces).  This is all rather Mac OS X specific, but I'm assuming since 
the python distributed with Mac OS X does this, that wxWidgets is picking 
that up and doing the same thing, as it should.

Logged In: YES 
user_id=21627

Can you find out where it does pick it up *from*, please?
Search the distutils and config directories of Python, and
the wxWindows directories for clues; also print your env.

Logged In: YES 
user_id=1233904

OK, looks like my problem was with 2.3.4, so I made that patch.  Now that 
2.3.5 is out, I didn't notice that this patch doesn't seem to be necessary 
anymore.  Sorry for wasting your time.

Logged In: YES 
user_id=45365

Indeed, 2.3.5 (and 2.4.1) were patched wrt. the 
MACOSX_DEPLOYMENT_TARGET environment specifically to address 
this problem.