[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I've committed a fix in r82272 (2.7), r82273 (3.2), r82274 (2.6), r82273 (3.1)

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> compile error

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren  added the comment:
> 
> That (/usr/local/src) explains why I haven't been able to reproduce the 
> problem, that worried me a little.
> 
> W.r.t. to the SDK:
> 
> 1) You don't have to use an SDK: use 
> 
>  configure --enable-universalsdk=/  MACOSX_DEPLOYMENT_TARGET=10.5
> 
>   (or whatever target you wish to support)

Well, we want to build universal binaries, so we do need the SDK.

> 2) The SDK should only affect system files, that is anything in /System
>and /usr (except for /usr/local). /Library is not part of the SDK
>and is not affected by SDK settings.

Sorry, I should have written /System/Library/. You find Tcl
in /System/Library, but not in
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/

Anyway, this doesn't appear to matter, since setup.py picks up the
files from a different dir: /System/Library/Frameworks/Tk.framework
and that is included in the SDK.

As I said: The fix makes the build work, so it's good enough for
now. In the future all this may will have to be revisited.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

That (/usr/local/src) explains why I haven't been able to reproduce the 
problem, that worried me a little.

W.r.t. to the SDK:

1) You don't have to use an SDK: use 

 configure --enable-universalsdk=/  MACOSX_DEPLOYMENT_TARGET=10.5

  (or whatever target you wish to support)

2) The SDK should only affect system files, that is anything in /System
   and /usr (except for /usr/local). /Library is not part of the SDK
   and is not affected by SDK settings.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren  added the comment:
> 
> I don't agree that there must be an option to fall back to system provided 
> libs. The point of using an SDK is to avoid doing that because you might end 
> up with a binary that won't work on an earlier version of the OS (the OpenSSL 
> one is an example of that).

If you don't and the SDK doesn't include the files Python is looking
for, then the build will fail, so I don't see an improvement in not
doing so ;-)

Also note that a user may not have a require to be able to use the
built Python on some previous version of the OS.

Note that if you use MacPorts it's fairly common to use e.g.
use their Tcl version for Python which resides in /Library
as well.

The SDK logic should not redirect such paths to the SDK were they
don't exist.

> I agree that the documentation/comments should be extended to not that 
> additional work would be needed when we start looking for files that aren't 
> headers or libraries.
> 
> BTW. I still don't quite understand why the build did fail for you in the 
> first place. Is your source tree in /usr/local as well?

Yes, we build and install from /usr/local/src - as is standard for
Unix platforms. I know that Mac OS X is different in some way, but
at least the Mac ports collection uses the same approach.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I don't agree that there must be an option to fall back to system provided 
libs. The point of using an SDK is to avoid doing that because you might end up 
with a binary that won't work on an earlier version of the OS (the OpenSSL one 
is an example of that).

I agree that the documentation/comments should be extended to not that 
additional work would be needed when we start looking for files that aren't 
headers or libraries.

BTW. I still don't quite understand why the build did fail for you in the first 
place. Is your source tree in /usr/local as well?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren  added the comment:
> 
> The search code must look in the SDK and not fall back on looking into the 
> system to avoid finding new headers and libraries when trying to build using 
> an older SDK on a newer system.

Right, but at least there should be an option to fall back to
the system provided libs. This is currently not the case.

The code would need some refactoring to make this possible,
though, e.g. a combined version of the SDK functions you added
to return the corrected path instead of just True/False.

> I don't think this is a problem at the moment, but it could be in the future. 
> 
> The reason I added the SDK support code was that Snow Leopard contained a 
> newer version of the OpenSSL libraries and the Python build picked up version 
> information from the system version of OpenSSL instead of the SDK, and that 
> resulted in a disfunctional build (IIRC hashlib was incomplete and that 
> caused numerous test failures).
> 
> Falling back to looking in the current system would be needed when looking 
> for a file that isn't a header of library, but AFAIK we don't do that in 
> setup.py.

I guess you should at least add a note pointing to this potential future
problem to the code and perhaps also reference this ticket.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The search code must look in the SDK and not fall back on looking into the 
system to avoid finding new headers and libraries when trying to build using an 
older SDK on a newer system.

I don't think this is a problem at the moment, but it could be in the future. 

The reason I added the SDK support code was that Snow Leopard contained a newer 
version of the OpenSSL libraries and the Python build picked up version 
information from the system version of OpenSSL instead of the SDK, and that 
resulted in a disfunctional build (IIRC hashlib was incomplete and that caused 
numerous test failures).

Falling back to looking in the current system would be needed when looking for 
a file that isn't a header of library, but AFAIK we don't do that in setup.py.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren  added the comment:
> 
> What I don't quite understand is why the build fails for you but passes for 
> me. What configure flags did you use?

I posted the configure options in the first message on this ticket.

The failure appears to be due to the fact that we run and install
our software in /usr/local (which is the standard we use on all
Unix systems).

> This version should fare better:
> 
> def is_macosx_sdk_path(path):
> """
> Returns True if 'path' can be located in an OSX SDK
> """
> return (path.startswith('/usr/') and not path.startswith('/usr/local')) 
> or path.startswith('/System/')

With this variant, the build works correctly, however, see below...

> This explicitly tests for paths that must be in the SDK:
> 
> * Anything in /System is owned by the system, and should be fetched
>   through the SDK
> * Likewise for anything in /usr that isn't in /usr/local
>  
> IMHO anyone that installs additional libraries in /usr/lib, or 
> /System/Libraries/Frameworks is confused at best, and we shouldn't even try 
> to support that.

...wouldn't it be better to check whether the SDK does indeed provide
the path in question and only then redirect to the SDK path instead
of the normal system one ?

I'm not sure whether these will ever be needed by Python,
but it would certainly make the function more robust:

There are quite a few things in /usr/lib that you don't find in
the SDK usr/lib/ dir. For /System the situation is even more obvious:
the SDK version only has these entries:

# ls -l /Developer/SDKs/MacOSX10.4u.sdk/System/Library/
total 0
drwxr-xr-x 3 root  wheel   102 Oct 27  2007 CFMSupport
drwxr-xr-x92 root  wheel  3128 Oct 27  2007 Frameworks
drwxr-xr-x 3 root  wheel   102 Oct 27  2007 Printers
drwxr-xr-x   123 root  wheel  4182 Oct 27  2007 PrivateFrameworks

whereas the OS directory has dozens of entries.

> The repository contains an simpler (but in hindsight too simple) version 
> because ${SDKROOT}/usr/local/lib is a symlink to the real /usr/local/lib. 
> That works fine when looking for libraries, but not when looking for other 
> files (such as headers).

Right, but really only that link. SDK also doesn't contain any links
for the missing /System/Library directories.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

What I don't quite understand is why the build fails for you but passes for me. 
What configure flags did you use?

This version should fare better:

def is_macosx_sdk_path(path):
"""
Returns True if 'path' can be located in an OSX SDK
"""
return (path.startswith('/usr/') and not path.startswith('/usr/local')) or 
path.startswith('/System/')

This explicitly tests for paths that must be in the SDK:

* Anything in /System is owned by the system, and should be fetched
  through the SDK
* Likewise for anything in /usr that isn't in /usr/local
 
IMHO anyone that installs additional libraries in /usr/lib, or 
/System/Libraries/Frameworks is confused at best, and we shouldn't even try to 
support that.


The repository contains an simpler (but in hindsight too simple) version 
because ${SDKROOT}/usr/local/lib is a symlink to the real /usr/local/lib. That 
works fine when looking for libraries, but not when looking for other files 
(such as headers).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren  added the comment:
> 
> Marc-Andre: what version of Xcode do you use? (the version in the About menu 
> of Xcode.app).

We have Xcode 2.5 and all updates on the machine. Python 2.6 and
older versions compile just fine.

The changes you added for the SDK builds in Python 2.7 made the problem
appear.

What I don't understand is why you are redirecting files under
/usr to the SDK virtual root dir. We install all the local
builds under /usr/local/ and as result, the build itself
also happens under a /usr path.

The function definition appears to be a bit coarse in this respect:

def is_macosx_sdk_path(path):
"""
Returns True if 'path' can be located in an OSX SDK
"""
return path.startswith('/usr/') or path.startswith('/System/')

I believe that this function should really only return True if
the path in question does exists in the SDK virtual root.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Marc-Andre: what version of Xcode do you use? (the version in the About menu of 
Xcode.app).

I'm getting clean builds with '--enable-universalsdk' on OSX 10.4.11 (PPC) with 
Xcode 2.5 (the last Xcode for OSX 10.4). That is, all extension build, except 
for the ones grouped with '_bsddb' in your initial message (and that's 
expected).  Furthermore all tests passed.

I had one oddity in the tests: make test prints "Warning -- sys.path was 
modified by test_site". I don't get this warning on OSX 10.6.

BTW. universal builds work fine on OSX 10.6, that's how I do most of my 
development.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I'll fire up my 10.4 system to further investigate this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9046] Python 2.7rc2 doesn't build on Mac OS X 10.4

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Sorry, my bad. The system in question is a 10.4 Tiger system.

--
title: Python 2.7rc2 doesn't build on Mac OS X 10.3 -> Python 2.7rc2 doesn't 
build on Mac OS X 10.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com