[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker

[SourceForge.net]

Bugs item #1158005, was opened at 2005-03-06 16:42
Message generated for change (Comment added) made by edwardmoy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Moy (edwardmoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: unixccompiler.py should deal with env in linker

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 23:34

Message:
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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-03-09 15:58

Message:
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.

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 15:22

Message:
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.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-03-09 15:03

Message:
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?

----------------------------------------------------------------------

Comment By: Edward Moy (edwardmoy)
Date: 2005-03-09 13:42

Message:
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++.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-03-08 07:08

Message:
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)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470