Commit Graph

4 Commits

Author SHA1 Message Date
Ronald Oussoren 2a4ab81633 Fix for issue #7998: pythonw didn't work when --with-framework-name was
specified
2010-03-07 09:04:06 +00:00
Ronald Oussoren a55af9a9db - Issue #7658: Ensure that the new pythonw executable works on OSX 10.4
- Issue #7714: Use ``gcc -dumpversion`` to detect the version of GCC on
  MacOSX.

- Make configure look for util.h as well as libutil.h. The former
  is the header file that on OSX contains the defition of openpty.

  (Needed to compile for OSX 10.4 on OSX 10.6)

- Use the correct definition of CC to compile the pythonw executable
2010-01-17 16:25:57 +00:00
Ronald Oussoren 92919a66d2 Issue #6834: replace the implementation for the 'python' and 'pythonw' executables on OSX.
The previous implementation used execv(2) to run the real interpreter, which means that
you cannot use the arch(1) tool to select the architecture you want to use for a
universal build because that only affects the python/pythonw wrapper and not the actual
interpreter.

The new version uses posix_spawnv with a number of OSX-specific options that ensure that
the real interpreter is started using the same CPU architecture as the wrapper, and that
means that 'arch -ppc python' now actually works.

I've also changed the way that the wrapper looks for the framework: it is now linked to
the framework rather than hardcoding the framework path. This should make it easier to
provide pythonw support in tools like virtualenv.
2009-12-24 13:30:58 +00:00
Ronald Oussoren 8ec9f866c0 Move Mac/OSX/Tools one level up 2006-06-07 18:57:44 +00:00