Unwanted PPC build in setuptools

[Chris Fonnesbecck]

Is there any way of convincing setuptools to *not* build for PPC? For
some reason, it tries to build a universal binary by default:

g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk ...etc

Which results in errors:

ld warning: in /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/Python.framework/Versions/4.3.0/lib/libz.dylib,
file is not of required architecture
ld: in /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/Python.framework/Versions/4.3.0/lib/libz.1.dylib,
file is not of required architecture for architecture ppc

I have no interest in building universals -- how can I switch this
off? I already tried putting "-arch i386" in my LDFLAGS, but to no
avail.

Thanks,
cf
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Ronald Oussoren]

On 19 Oct, 2009, at 22:47, Chris Fonnesbeck wrote:

> Is there any way of convincing setuptools to *not* build for PPC? For
> some reason, it tries to build a universal binary by default:
>
> g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/
> MacOSX10.4u.sdk ...etc
>
> Which results in errors:
>
> ld warning: in /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/
> Python.framework/Versions/4.3.0/lib/libz.dylib,
> file is not of required architecture
> ld: in /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/
> Python.framework/Versions/4.3.0/lib/libz.1.dylib,
> file is not of required architecture for architecture ppc
>
> I have no interest in building universals -- how can I switch this
> off? I already tried putting "-arch i386" in my LDFLAGS, but to no
> avail.

Add ['-arch', 'i386'] to both extra_compile_args and extra_link args  
of the Extension objects.

BTW. The path's in the error-messages above are fishy, there shouldn't  
be a '4.3.0' version in Python.framework.

Ronald

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Robert Kern-2]

On 2009-10-19 15:59 PM, Ronald Oussoren wrote:

>
> On 19 Oct, 2009, at 22:47, Chris Fonnesbeck wrote:
>
>> Is there any way of convincing setuptools to *not* build for PPC? For
>> some reason, it tries to build a universal binary by default:
>>
>> g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk ...etc
>>
>> Which results in errors:
>>
>> ld warning: in
>> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/Python.framework/Versions/4.3.0/lib/libz.dylib,
>>
>> file is not of required architecture
>> ld: in
>> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/Python.framework/Versions/4.3.0/lib/libz.1.dylib,
>>
>> file is not of required architecture for architecture ppc
>>
>> I have no interest in building universals -- how can I switch this
>> off? I already tried putting "-arch i386" in my LDFLAGS, but to no
>> avail.

Edit /Library/Frameworks/.../lib/python2.5/config/Makefile to remove the
occurrences of "-arch ppc" if you never want to build PPC versions of stuff
again. More recent versions of EPD should have that done already.

> Add ['-arch', 'i386'] to both extra_compile_args and extra_link args of
> the Extension objects.

Will that get rid of the pre-existing "-arch ppc" flags?

> BTW. The path's in the error-messages above are fishy, there shouldn't
> be a '4.3.0' version in Python.framework.

I presume he's using the Enthought Python Distribution (disclosure: I work for
Enthought), which does have such a version number. It's basically a
not-entirely-palatable hack to make sure that users can install and uninstall
EPD in order to try it out without breaking their previously installed Pythons.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Chris Fonnesbecck]

On Tue, Oct 20, 2009 at 10:20 AM, Robert Kern <robert.kern@...> wrote:
> I presume he's using the Enthought Python Distribution (disclosure: I work
> for Enthought), which does have such a version number. It's basically a
> not-entirely-palatable hack to make sure that users can install and
> uninstall EPD in order to try it out without breaking their previously
> installed Pythons.

Thanks for the advice. I was indeed using Enthought. I am just going
to go ahead and upgrade, and see what that does.

cf

--
Chris Fonnesbeck
Department of Mathematics and Statistics
PO Box 56, University of Otago
Dunedin, New Zealand
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Ronald Oussoren]

On 19 Oct, 2009, at 23:20, Robert Kern wrote:

> On 2009-10-19 15:59 PM, Ronald Oussoren wrote:
>>
>> On 19 Oct, 2009, at 22:47, Chris Fonnesbeck wrote:
>>
>>> Is there any way of convincing setuptools to *not* build for PPC?  
>>> For
>>> some reason, it tries to build a universal binary by default:
>>>
>>> g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/
>>> MacOSX10.4u.sdk ...etc
>>>
>>> Which results in errors:
>>>
>>> ld warning: in
>>> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/
>>> Python.framework/Versions/4.3.0/lib/libz.dylib,
>>>
>>> file is not of required architecture
>>> ld: in
>>> /Developer/SDKs/MacOSX10.4u.sdk/Library/Frameworks/
>>> Python.framework/Versions/4.3.0/lib/libz.1.dylib,
>>>
>>> file is not of required architecture for architecture ppc
>>>
>>> I have no interest in building universals -- how can I switch this
>>> off? I already tried putting "-arch i386" in my LDFLAGS, but to no
>>> avail.
>
> Edit /Library/Frameworks/.../lib/python2.5/config/Makefile to remove  
> the occurrences of "-arch ppc" if you never want to build PPC  
> versions of stuff again. More recent versions of EPD should have  
> that done already.

Patching the installation is evil.

>
>> Add ['-arch', 'i386'] to both extra_compile_args and extra_link  
>> args of
>> the Extension objects.
>
> Will that get rid of the pre-existing "-arch ppc" flags?

Yes.  Distutils assumes that you know what you're doing when you  
specify a -arch flag and strips all existing -arch flags from the  
default flags. Likewise for -isysroot, if you specify that the  
existing one will be removed automaticly.

>
>> BTW. The path's in the error-messages above are fishy, there  
>> shouldn't
>> be a '4.3.0' version in Python.framework.
>
> I presume he's using the Enthought Python Distribution (disclosure:  
> I work for Enthought), which does have such a version number. It's  
> basically a not-entirely-palatable hack to make sure that users can  
> install and uninstall EPD in order to try it out without breaking  
> their previously installed Pythons.

Wouldn't it be better to use '--with-framework-name', IIRC I  
introduced that in 2.6:

        ./configure --enable-framework --with-framework-name=EPD

This will create a framework named 'EPD.framework' instead of  
'Python.framework'.

Ronald



_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Dave Peterson-4]

Ronald Oussoren wrote:

>
> On 19 Oct, 2009, at 23:20, Robert Kern wrote:
>
>> I presume he's using the Enthought Python Distribution (disclosure: I
>> work for Enthought), which does have such a version number. It's
>> basically a not-entirely-palatable hack to make sure that users can
>> install and uninstall EPD in order to try it out without breaking
>> their previously installed Pythons.
>
> Wouldn't it be better to use '--with-framework-name', IIRC I
> introduced that in 2.6:
>
>     ./configure --enable-framework --with-framework-name=EPD
>
> This will create a framework named 'EPD.framework' instead of
> 'Python.framework'.

(I also work for Enthought)

EPD is still using Python 2.5 as its base, though we expect to be on 2.6
shortly.

I'm not clear on what the name of the framework effects.   Would you be
able to install pre-built binary distributions, built against an "EPD"
framework, into a "Python" framework?  And vice-versa?   If not, then
this probably isn't a usable solution for us.


-- Dave

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Robert Kern-2]

On 2009-10-21 14:59 PM, Ronald Oussoren wrote:
>
> On 19 Oct, 2009, at 23:20, Robert Kern wrote:

>> Edit /Library/Frameworks/.../lib/python2.5/config/Makefile to remove
>> the occurrences of "-arch ppc" if you never want to build PPC versions
>> of stuff again. More recent versions of EPD should have that done
>> already.
>
> Patching the installation is evil.

I would agree that patching the *code* is evil, but the Makefile is really just
a datastore for the default configuration information for distutils. If you know
what you're doing, I say feel free. distutils doesn't give us another way to
change this default configuration.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Ronald Oussoren]

On 21 Oct, 2009, at 22:48, Robert Kern wrote:

> On 2009-10-21 14:59 PM, Ronald Oussoren wrote:
>>
>> On 19 Oct, 2009, at 23:20, Robert Kern wrote:
>
>>> Edit /Library/Frameworks/.../lib/python2.5/config/Makefile to remove
>>> the occurrences of "-arch ppc" if you never want to build PPC  
>>> versions
>>> of stuff again. More recent versions of EPD should have that done
>>> already.
>>
>> Patching the installation is evil.
>
> I would agree that patching the *code* is evil, but the Makefile is  
> really just a datastore for the default configuration information  
> for distutils. If you know what you're doing, I say feel free.  
> distutils doesn't give us another way to change this default  
> configuration.

Could you file a bug for this at bugs.python.org?  Any need to edit  
files in sys.prefix is IMHO a bug, it should be possible to configure  
this in a setup.cfg file or ~/.pydistutils.cfg.

Ronald

>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a  
> harmless enigma
> that is made terrible by our own mad attempt to interpret it as  
> though it had
> an underlying truth."
>  -- Umberto Eco
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@...
> http://mail.python.org/mailman/listinfo/pythonmac-sig

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Ronald Oussoren]

On 21 Oct, 2009, at 22:14, Dave Peterson wrote:

> Ronald Oussoren wrote:
>>
>> On 19 Oct, 2009, at 23:20, Robert Kern wrote:
>>
>>> I presume he's using the Enthought Python Distribution  
>>> (disclosure: I work for Enthought), which does have such a version  
>>> number. It's basically a not-entirely-palatable hack to make sure  
>>> that users can install and uninstall EPD in order to try it out  
>>> without breaking their previously installed Pythons.
>>
>> Wouldn't it be better to use '--with-framework-name', IIRC I  
>> introduced that in 2.6:
>>
>>    ./configure --enable-framework --with-framework-name=EPD
>>
>> This will create a framework named 'EPD.framework' instead of  
>> 'Python.framework'.
>
> (I also work for Enthought)
>
> EPD is still using Python 2.5 as its base, though we expect to be on  
> 2.6 shortly.
>
> I'm not clear on what the name of the framework effects.   Would you  
> be able to install pre-built binary distributions, built against an  
> "EPD" framework, into a "Python" framework?  And vice-versa?   If  
> not, then this probably isn't a usable solution for us.

Extensions are not linked to the framework, extensions build for a  
Python.framework should therefore work unchanged in a EPD.framework.  
That said, I haven't checked yet if 3th party tools work with a  
renamed Python framework, I know that py2app hardcodes the name  
Python.framework and IIRC virtualenv does the same.

Both could and should be changed, and that's something on my todo list  
for various reasons. One of which is that I want to have side-by-side  
installs of a couple of build variations of Python on my machine.

Ronald

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Robert Kern-2]

On 2009-10-22 07:02 AM, Ronald Oussoren wrote:

>
> On 21 Oct, 2009, at 22:14, Dave Peterson wrote:
>
>> Ronald Oussoren wrote:
>>>
>>> On 19 Oct, 2009, at 23:20, Robert Kern wrote:
>>>
>>>> I presume he's using the Enthought Python Distribution (disclosure:
>>>> I work for Enthought), which does have such a version number. It's
>>>> basically a not-entirely-palatable hack to make sure that users can
>>>> install and uninstall EPD in order to try it out without breaking
>>>> their previously installed Pythons.
>>>
>>> Wouldn't it be better to use '--with-framework-name', IIRC I
>>> introduced that in 2.6:
>>>
>>> ./configure --enable-framework --with-framework-name=EPD
>>>
>>> This will create a framework named 'EPD.framework' instead of
>>> 'Python.framework'.
>>
>> (I also work for Enthought)
>>
>> EPD is still using Python 2.5 as its base, though we expect to be on
>> 2.6 shortly.
>>
>> I'm not clear on what the name of the framework effects. Would you be
>> able to install pre-built binary distributions, built against an "EPD"
>> framework, into a "Python" framework? And vice-versa? If not, then
>> this probably isn't a usable solution for us.
>
> Extensions are not linked to the framework, extensions build for a
> Python.framework should therefore work unchanged in a EPD.framework.
> That said, I haven't checked yet if 3th party tools work with a renamed
> Python framework, I know that py2app hardcodes the name Python.framework
> and IIRC virtualenv does the same.
>
> Both could and should be changed, and that's something on my todo list
> for various reasons. One of which is that I want to have side-by-side
> installs of a couple of build variations of Python on my machine.

It would be great to see more support for alternative framework names. It would
be a much better alternative. There are also other packages, primary non-Python
ones like VTK, that still expect Python.framework. With enough effort, I assume
we can make them work, though. At the time we did this, the version number
change seemed like an easier alternative. It tends to only generate a couple of
"WTF?" moments rather than real problems, and we are the ones who usually get
the support emails.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig