unixccompiler.py should deal with env in linker

[edwardmoy]

BPO	1158005
Nosy	@loewis, @jackjansen

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2005-03-14.14:41:36.000>
created_at = <Date 2005-03-07.00:42:09.000>
labels = ['library']
title = 'unixccompiler.py should deal with env in linker'
updated_at = <Date 2005-03-14.14:41:36.000>
user = 'https://bugs.python.org/edwardmoy'

bugs.python.org fields:

activity = <Date 2005-03-14.14:41:36.000>
actor = 'jackjansen'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Distutils']
creation = <Date 2005-03-07.00:42:09.000>
creator = 'edwardmoy'
dependencies = []
files = []
hgrepos = []
issue_num = 1158005
keywords = []
message_count = 8.0
messages = ['24484', '24485', '24486', '24487', '24488', '24489', '24490', '24491']
nosy_count = 3.0
nosy_names = ['loewis', 'jackjansen', 'edwardmoy']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1158005'
versions = ['Python 2.3']

[edwardmoy]

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

[loewis]

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

[edwardmoy]

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

[loewis]

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?

[edwardmoy]

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.

[loewis]

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.

[edwardmoy]

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.

[jackjansen]

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.