With a 64-bit debug non-framework builds of the trunk and py3k, on OS X 10.6, I'm consistently getting the following failure in test_platform:

trunk dickinsm$ ./python.exe Lib/test/regrtest.py -uall test_platform
test_platform
[18064 refs]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/dickinsm/python/svn/trunk/Lib/platform.py", line 1017, in architecture
    import struct
  File "/Users/dickinsm/python/svn/trunk/Lib/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
[17485 refs]
test test_platform failed -- Traceback (most recent call last):
  File "/Users/dickinsm/python/svn/trunk/Lib/test/test_platform.py", line 24, in test_architecture_via_symlink
    self.assertEqual(get(real), get(link))
AssertionError: Tuples differ: ("('64bit', '')\n", None) != ('', None)

First differing element 0:
('64bit', '')



- ("('64bit', '')\n", None)
+ ('', None)

1 test failed:
    test_platform
[36722 refs]

This test seems to trigger an issue in site.py, adding '-v' to the code that starts the interpreter in test_platform.py gives the following output (amongst a lot more text that doesn't seem to be relevant):

'import site' failed; traceback:
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/python-trunk/build/../Lib/site.py", line 530, in <module>
    main()
  File "/Users/ronald/Projects/python/python-trunk/build/../Lib/site.py", line 509, in main
    addbuilddir()
  File "/Users/ronald/Projects/python/python-trunk/build/../Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/Users/ronald/Projects/python/python-trunk/Lib/sysconfig.py", line 577, in get_platform
    cfgvars = get_config_vars()
  File "/Users/ronald/Projects/python/python-trunk/Lib/sysconfig.py", line 402, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/ronald/Projects/python/python-trunk/Lib/sysconfig.py", line 255, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/local/lib/python2.7/config/Makefile (No such file or directory)


The root cause is that test_architecture_via_symlink starts python through a symlink, and that confuses the sysconfig module because that tries to detect if it is running in the build tree by looking for a file relative to sys.executable, without resolving symlinks.

A simple patch to sysconfig seems to fix the issue:

-_PROJECT_BASE = abspath(os.path.dirname(sys.executable))
+_PROJECT_BASE = abspath(os.path.dirname(os.path.realpath(sys.executable)))

(also attached as a proper patch).

I'm adding tarek because he added Lib/sysconfig.py.

Tarek: could you please review the patch?

I am seeing the same problem with 32-bit on OS X 10.5:

euclid:trunk minge$ ./python.exe Lib/test/regrtest.py -uall test_platform
test_platform
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/minge/Work/Languages/python/trunk/Lib/platform.py", line 1017, in architecture
    import struct
  File "/Users/minge/Work/Languages/python/trunk/Lib/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
test test_platform failed -- Traceback (most recent call last):
  File "/Users/minge/Work/Languages/python/trunk/Lib/test/test_platform.py", line 24, in test_architecture_via_symlink
    self.assertEqual(get(real), get(link))
AssertionError: Tuples differ: ("('32bit', '')\n", None) != ('', None)

First differing element 0:
('32bit', '')



- ("('32bit', '')\n", None)
+ ('', None)

1 test failed:
    test_platform


The proposed patch seems reasonable.  I verified that it fixed the problem for 10.5.

I'd expect more failures, the failure is caused by the way the sysconfig module calculates the root of the installation, and whether or not it is running in the source tree.

Tarek: could you please review sysconfig.patch?

Looking at the code, the whole approach to finding the project base appears to be very fragile.

I'd suggest to use a landmark file for finding the project base, say "Modules/main.c", and a function which searches all directories on the os.path.realpath(sys.executable) for this landmark file in order to determine the correct project directory (or none in case Python was not called from a Python build binary).

The special cases for PC builds could then be removed.

I'm closing this issue because a patch simular to the attached patch was applied in r78835 and the issue therefore fixed.