python26 fails to build 64-bit

[nerdling (Jeremy Lavergne)]

Build failures for undefined symbols and Python.framework being the wrong architecture.

Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2" &&
 /usr/bin/make all MAKE="/usr/bin/make CC=/usr/bin/gcc-4.2" " returned error 2
Command output: if test ""; then \
                /usr/bin/gcc-4.2 -o Python.framework/Versions/2.6/Python  -dynamiclib \
                        -isysroot "" \                        -all_load libpython2.6.a -Wl,-single_module \
                        -install_name /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Python \
                        -compatibility_version 2.6 \
                        -current_version 2.6; \
        else \
                /usr/bin/libtool -o Python.framework/Versions/2.6/Python -dynamic  libpython2.6.a \
                         -lSystem -lSystemStubs -arch_only i386 -install_name /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Python -compatibility_version 2.6 -current_version 2.6 
;\
        fi
/usr/bin/install -c -d -m 755  \
                Python.framework/Versions/2.6/Resources/English.lproj/usr/bin/install -c -m 644 Mac/Resources/framework/Info.plist \
                Python.framework/Versions/2.6/Resources/Info.plist
ln -fsn 2.6 Python.framework/Versions/Current
ln -fsn Versions/Current/Python Python.framework/Python
ln -fsn Versions/Current/Headers Python.framework/Headers
ln -fsn Versions/Current/Resources Python.framework/Resources
/usr/bin/gcc-4.2 -L/opt/local/lib -arch x86_64 -u _PyMac_Error Python.framework/Versions/2.6/Python -o python.exe \
                        Modules/python.o \
                         -ldl      
ld: warning: in Python.framework/Versions/2.6/Python, file is not of required architecture
Undefined symbols:
  "_PyMac_Error", referenced from:
  "_Py_Main", referenced from:
      _main in python.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1

[nerdling (Jeremy Lavergne)]

port -d isntall python26 (stderr)

[nerdling (Jeremy Lavergne)]

port -d install python26 (stdout)

[kentk@…]

Cc Me!

[kentk@…]

patch that forces 10.5 sdk instead of 10.6

[kentk@…]

I was blocked by this, so I figured out a workaround at least. I'm attaching it as a patch.

Build with +universal

[mike@…]

I tried installing python26 using kentk's patch, but didn't have any luck. Attaching the output...

[mike@…]

output of sudo port -dv install python26 +universal +darwin_10 with kentk's patch applied to portfile

[mike@…]

Cc Me!

[kentk@…]

You don't have to specify +darwin_10, that happens automagically. I can see in the log that it complains about a lot of dependencies not being +universal. I started over with my installation, but you might want to just do upgrade --enforce-variants on them.

Not sure if that is the actual problem, but its something at least...

[mike@…]

that worked, thanks!

[tobypeterson]

fwiw, the change in python26_snowleopard.patch is not an acceptable long-term solution

[kentk@…]

I agree. Got any idea what the actual problem is?

[blb@…]

There can be only one (assignee).

[alexguo@…]

Cc Me!

[robin@…]

Cc Me!

[lstoll@…]

Cc Me!

[wiml@…]

Oddly enough I have successfully installed python26 @2.6.2_3+universal on SnowLeopard. I don't remember if I had to do anything in particular to get it to properly build i386+x86_64 fat.

[tamyrvoll@…]

Cc Me!

[john+macports@…]

Cc Me!

[joshua_anderson@…]

Cc Me!

[huahang.liu@…]

Cc Me!

[faisal.moledina@…]

Cc Me!

[tomvons@…]

fwiw, this built fine on my 32 bit Snow Leopard (Core Duo MBP), but will not build in x64.

[tomvons@…]

Cc Me!

[benjaminkreeger@…]

Replying to tomvons@…:

fwiw, this built fine on my 32 bit Snow Leopard (Core Duo MBP), but will not build in x64.

This would not build on my Snow Leopard install. I'm running the 32-bit kernel (my EFI is 32-bit) but system extensions were running in 64-bit. It's in iMac4,1 (pretty sure it's 4,1).

From what I remember trying it on my aluminum MacBook, it didn't work there, either. Are your system extensions running in 32-bit?

[benjaminkreeger@…]

Cc Me!

[tomvons@…]

Replying to benjaminkreeger@…:

From what I remember trying it on my aluminum MacBook, it didn't work there, either. Are your system extensions running in 32-bit?

Yes, it's a Core Duo (1,1 MBP) which doesn't support x64

[jmroot (Joshua Root)]

It appears that python also needs some extra persuasion to respect the selected build_arch.

[m@…]

It fails during staging with +universal too. (x64mbp)

[m@…]

Cc Me!

[blb@…]

Cc reporter of dup #20841.

[dizzyd@…]

Cc Me!

[mattias@…]

Ok I have found the problem, the bug is an upstream bug in python and the problem is line 461 in the Makefile for python, it looks something like this:

-lSystem -lSystemStubs -arch_only i386 -install_name $(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK) -compatibility_version $(V     ERSION) -current_version $(VERSION) ;

This means libtool is instructed to ONLY accept a python.o file in the i386 binary format, while what we are compiling is a x86_64 binary. If you change that line to:

-lSystem -lSystemStubs -arch_only x86_64 -install_name $(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK) -compatibility_version $(V     ERSION) -current_version $(VERSION) ;

However this will not solve it all, it will break things as I now get this error from macports:

running install_egg_info
Writing //opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/Python-2.6.2-py2.6.egg-info
ln -fs "../../../Python" "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.a"
cd Mac && /usr/bin/make CC=/usr/bin/gcc-4.2 installmacsubtree DESTDIR="/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot"
Creating directory /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools
DYLD_FRAMEWORK_PATH=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2:  ../python.exe ./scripts/cachersrc.py -v /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools
Traceback (most recent call last):
  File "./scripts/cachersrc.py", line 44, in <module>
    main()
  File "./scripts/cachersrc.py", line 41, in main
    os.path.walk(dir, handler, (verbose, force))
  File "../Lib/posixpath.py", line 224, in walk
    func(arg, top, names)
  File "./scripts/cachersrc.py", line 23, in handler
    macresource.open_pathname(os.path.join(dirname, fn), verbose=verbose)
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2/Lib/plat-mac/macresource.py", line 81, in open_pathname
    refno = Res.FSpOpenResFile(pathname, 1)
AttributeError: 'module' object has no attribute 'FSpOpenResFile'
make[1]: *** [installmacsubtree] Error 1
make: *** [frameworkinstallmaclib] Error 2

    while executing
"command_exec destroot"
    (procedure "portdestroot::destroot_main" line 2)
    invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for python26): org.macports.activate org.macports.destroot org.macports.install
Error: The following dependencies failed to build: python26
Error: Status 1 encountered during processing.

Also changed the configure.args section in the Portfile to include "--with-universal-archs=64-bit"

I will continue to look into this.

[mattias@…]

Patch for "Makefile.pre" to make libtool accept x86_64 as an architecture.

[mattias@…]

Patch for "Makefile.pre" to make libtool accept x86_64 as an architecture.

[mattias@…]

Sorry, did post the patch in the wrong format.

[xmitchx@…]

Cc Me!

[blb@…]

Cc reporter of dup #20870.

[shrift@…]

Cc Me!

[tannhaus@…]

Cc Me!

[tharant@…]

Cc Me!

[hkroger@…]

Cc Me!

[michael@…]

Cc Me!

[sjcjonker@…]

Cc Me!

[macports@…]

Cc Me!

[thedoobs@…]

Cc Me!

[skymoo (Adam Mercer)]

Cc Me!

[dmitrykichenko@…]

Cc Me!

[treaves@…]

This really shouldn't be low priority, as it causes many, many other ports to not install, due to the ridicules way Ports refuses to allow for the system python to be used. I don't give a damn about Ports python, but I do use GnuCash. Why on Earth building GnuCash requires Python to be built is a good question, but it does.

[mattias@…]

Replying to treaves@…:

This really shouldn't be low priority, as it causes many, many other ports to not install, due to the ridicules way Ports refuses to allow for the system python to be used. I don't give a damn about Ports python, but I do use GnuCash. Why on Earth building GnuCash requires Python to be built is a good question, but it does.

Also, alot of stuff are depending on stuff that depends on something, that in some weird way depends on python.

[mattias@…]

Ok. after investigating this further one way to solve this is to rewrite the portfile to detect which arch the machine is running and patch the makefile.pre.in accordingly. This is a bit of work with tho.

The other way would be to build a universal binary with both i386 and x86_64 as that would sidestep that check altogether, also this would probably be pretty easy to do.

Anyone else got anything?

[nerdling (Jeremy Lavergne)]

Snow Leopard has shipped and this is holding up a lot of ports.

[mattias@…]

Cc Me!

[mattias@…]

Cc Me!

[mattias@…]

Replying to mattias@…:

Ok. after investigating this further one way to solve this is to rewrite the portfile to detect which arch the machine is running and patch the makefile.pre.in accordingly. This is a bit of work with tho.

The other way would be to build a universal binary with both i386 and x86_64 as that would sidestep that check altogether, also this would probably be pretty easy to do.

Anyone else got anything?

Also the reason for this is, even that Snowleopard is optimised for 64bit, there is some old core duo's (32-bit processors, early macbooks) that can run snow leopard in 32-bit mode.

[gerald.gutierrez@…]

Cc Me!

[pkutzner+macports@…]

Cc Me!

[xmitchx@…]

Replying to mattias@…:

Ok. after investigating this further one way to solve this is to rewrite the portfile to detect which arch the machine is running and patch the makefile.pre.in accordingly. This is a bit of work with tho.

The other way would be to build a universal binary with both i386 and x86_64 as that would sidestep that check altogether, also this would probably be pretty easy to do.

Anyone else got anything?

I think the best thing to do at this time would be to get a solution in that works right away without being too "hacky." (So able to be sustained over time). The latter solution, the easy one, sounds best to me since the worst that happens in this case is that its double the size due to being universal but this shouldn't negatively affect anyone.

The former solution seems silly to do if there is an easier one (the latter one) instead.

[mattias@…]

Replying to xmitchx@…:

I think the best thing to do at this time would be to get a solution in that works right away without being too "hacky." (So able to be sustained over time). The latter solution, the easy one, sounds best to me since the worst that happens in this case is that its double the size due to being universal but this shouldn't negatively affect anyone.

The former solution seems silly to do if there is an easier one (the latter one) instead.

Yep. This is why I want to take it up to discussion. Who knows, somebody else might have an even better solution to this. :)

Found a python bug that might be of interest: ​http://bugs.python.org/issue6245

[macports@…]

The +universal trick worked for me.

[huahang.liu@…]

Replying to macports@…:

The +universal trick worked for me.

What's your machine?

[gerald.gutierrez@…]

+universal did not work for me. Failed to build the Nav module.

Macbook4,1 Darwin mmma 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386

[treaves@…]

Mine is a a MacBookPro. Not newest, but not too old.

[erik.labianca@…]

Cc Me!

[huahang.liu@…]

Replying to treaves@…:

Mine is a a MacBookPro. Not newest, but not too old.

Can you please check your "Model Identifier" by clicking Apple Icon on the top left side of your menu bar -> About This Mac -> More Info...?

For example mine is MacBookPro5,1.

Thanks!

[huahang.liu@…]

Replying to gerald.gutierrez@…:

+universal did not work for me. Failed to build the Nav module.

Macbook4,1 Darwin mmma 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386

Mine is MacBookPro5,1. And the +universal trick doesn't work for me...

[erik.labianca@…]

I have MacBook PRo 5,3

Darwin grendel.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386

The +universal doesn't work for me, although it grinds for quite some time before noticing that it can't link correctly. I can supply the log if anyone is interested.

[issaco@…]

Cc Me!

[luis.beca@…]

Cc Me!

[treaves@…]

Replying to huahang.liu@…:

Replying to treaves@…:

Mine is a a MacBookPro. Not newest, but not too old.

Can you please check your "Model Identifier" by clicking Apple Icon on the top left side of your menu bar -> About This Mac -> More Info...?

For example mine is MacBookPro5,1.

Thanks!

MacBookPro3,1

[blb@…]

Upstream report is ​issue 6802.

[benjaminkreeger@…]

Replying to erik.labianca@…:

I have MacBook PRo 5,3

Darwin grendel.local 10.0.0 Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386 i386

The +universal doesn't work for me, although it grinds for quite some time before noticing that it can't link correctly. I can supply the log if anyone is interested.

Likewise, it screeches to a halt because it can't build Nav, and I used +universal on my MacBook5,1.

[brianm@…]

Cc Me!

[david@…]

Cc Me!

[macports@…]

Cc Me!

[albert.veli@…]

Cc Me!

[albert.veli@…]

A summary (on a Mac mini).

No flags gives the "file is not of required architecture" error.

Patching Makefile.pre with "-arch_only x86_64" gives:

File "./scripts/cachersrc.py", line 23, in handler
    macresource.open_pathname(os.path.join(dirname, fn), verbose=verbose)
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2/Lib/plat-mac/macresource.py", line 81, in open_pathname
    refno = Res.FSpOpenResFile(pathname, 1)
AttributeError: 'module' object has no attribute 'FSpOpenResFile'

and +universal gives:

Traceback (most recent call last):
  File "./scripts/BuildApplet.py", line 15, in <module>
    import EasyDialogs
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/EasyDialogs.py", line 34, in <module>
    import Nav
ImportError: No module named Nav

Additionally bad is that failure to build python26 blocks gtk2 and almost all programs I use depends on gtk2 :(

[julien.lusson@…]

Cc Me!

[me@…]

Cc Me!

[mattias@…]

Replying to albert.veli@…:

A summary (on a Mac mini).

No flags gives the "file is not of required architecture" error.

Patching Makefile.pre with "-arch_only x86_64" gives:

File "./scripts/cachersrc.py", line 23, in handler
    macresource.open_pathname(os.path.join(dirname, fn), verbose=verbose)
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2/Lib/plat-mac/macresource.py", line 81, in open_pathname
    refno = Res.FSpOpenResFile(pathname, 1)
AttributeError: 'module' object has no attribute 'FSpOpenResFile'

and +universal gives:

Traceback (most recent call last):
  File "./scripts/BuildApplet.py", line 15, in <module>
    import EasyDialogs
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/EasyDialogs.py", line 34, in <module>
    import Nav
ImportError: No module named Nav

Additionally bad is that failure to build python26 blocks gtk2 and almost all programs I use depends on gtk2 :(

+universal will fail because we are trying to link among other things ncursesw that is built only as x86_64, and then linking stuff against it for other architectures will fail.

[randyoo@…]

Cc Me!

[macports@…]

@albert.veli: you need to remove "import Nav" from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2/Lib/plat-mac/EasyDialogs.py see #20870

[macports@…]

Cc Me!

[albert.veli@…]

Replying to macports@…:

@albert.veli: you need to remove "import Nav" from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2/Lib/plat-mac/EasyDialogs.py see #20870

Thanks, it worked!

In short. Install zlib and python26 with +universal. After python26 fails, patch EasyDialogs.py as described above and compile again.

[rmsfisher@…]

Cc Me!

[fmaillet@…]

Cc Me!

[mattias@…]

Replying to macports@…:

@albert.veli: you need to remove "import Nav" from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python26/work/Python-2.6.2/Lib/plat-mac/EasyDialogs.py see #20870

This is _NOT_ a good solution, as it will break things in the long term.

[macports@…]

I don't know a lot about python (but various macports that I need require it), but ​http://docs.python.org/whatsnew/2.6.html says the Nav module is deprecated and will be removed in python 3.0.

[mattias@…]

Replying to macports@…:

I don't know a lot about python (but various macports that I need require it), but ​http://docs.python.org/whatsnew/2.6.html says the Nav module is deprecated and will be removed in python 3.0.

It will be removed in python 3.0, that is correct. However, as python 2.6 is a transitional package it means stuff is still using it. The reason to make it deprecated now is to make it a smoother transition to 3.0.

[andy@…]

Cc Me!

[macports.org@…]

Cc Me!

[jlaurila@…]

Cc Me!

[mattias@…]

After some experimenting I have had a conclusion that this is not something we can solve. I did a workaround for this bug by creating my own version of the "arch" command, the bug is in that python relies on this command to decide how to build certain things.

The function of the arch command is to report which architecture we are running, as the kernel is running in i386 mode, while the userland is (mostly) 64bit it get things wrong.

When I created my own version to correct this, I have found out we can't build a framework on snowleopard as there are things deep within the Python modules that require two things:

1. Deprecated system frameworks in general
2. Stuff from the Carbon framework that is not even included.

This will pretty much be unresolvable for the time being, without help from the python community. I will report my findings upstream to them.

[huahang.liu@…]

Replying to mattias@…:

After some experimenting I have had a conclusion that this is not something we can solve. I did a workaround for this bug by creating my own version of the "arch" command, the bug is in that python relies on this command to decide how to build certain things.

The function of the arch command is to report which architecture we are running, as the kernel is running in i386 mode, while the userland is (mostly) 64bit it get things wrong.

When I created my own version to correct this, I have found out we can't build a framework on snowleopard as there are things deep within the Python modules that require two things:

1. Deprecated system frameworks in general
2. Stuff from the Carbon framework that is not even included.

This will pretty much be unresolvable for the time being, without help from the python community. I will report my findings upstream to them.

I even believe that "arch", "uname -m" and "uname -p", they should all emit x86_64 rather than i386 on Snow Leopard. I reported this as a bug on Apple's Bug Reporter site here at:

​https://bugreport.apple.com/

Please search for "Problem ID: 6969481".

[mattias@…]

Replying to huahang.liu@…:

Replying to mattias@…:

After some experimenting I have had a conclusion that this is not something we can solve. I did a workaround for this bug by creating my own version of the "arch" command, the bug is in that python relies on this command to decide how to build certain things.

The function of the arch command is to report which architecture we are running, as the kernel is running in i386 mode, while the userland is (mostly) 64bit it get things wrong.

When I created my own version to correct this, I have found out we can't build a framework on snowleopard as there are things deep within the Python modules that require two things:

1. Deprecated system frameworks in general
2. Stuff from the Carbon framework that is not even included.

This will pretty much be unresolvable for the time being, without help from the python community. I will report my findings upstream to them.

I even believe that "arch", "uname -m" and "uname -p", they should all emit x86_64 rather than i386 on Snow Leopard. I reported this as a bug on Apple's Bug Reporter site here at:

​https://bugreport.apple.com/

Please search for "Problem ID: 6969481".

rdar://problem/6969481

Bug reports are not public, so we can't view them on the rdar site.

[xgutter@…]

Cc Me!

[brian.cunnie@…]

Cc Me!

[blb@…]

Cc reporter of dup #20940.

[xmitchx@…]

The upstream bug now has a patch reportedly fixing the issue: ​http://bugs.python.org/issue6802

The patch hasn't been merged in yet but hopefully this means a solution is near.

[mf2k (Frank Schima)]

Cc Me!

[michael@…]

Cc Me!

[skymoo (Adam Mercer)]

apply patch from upstream ticket 6802

[skymoo (Adam Mercer)]

debug build log following application of patch from upstream ticket 6802

[skymoo (Adam Mercer)]

Applying that patch enables the build to go further but then it fails with the error:

Failed to find the necessary bits to build these modules:
bsddb185           dl                 imageop         
linuxaudiodev      ossaudiodev        spwd            
sunaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses            _curses_panel      Nav

I've attached the full build log and a patch that updates the Portfile to apply the upstream patch and runs autoreconf to rebuild configure.

[macosforge@…]

Cc Me!

[deepu.sudhakar@…]

Cc Me!

[nicos_pavlov@…]

Cc Me!

[jan@…]

Cc Me!

[andreas@…]

Cc Me!

[andreas@…]

Im trying to build python26 on snow leopard aswell but my macports cant even build all dependencies.

Im getting this issue instead: ​http://trac.macports.org/ticket/20799

So my question is, how do you guys build python26 without tcl and tk?

[nyteshade@…]

Cc Me!

[nyteshade@…]

Sounds to me like the biggest problem to solve here is to make Ports correctly realize there is another version already installed. The worst part is that there is a version of 2.6 pre-installed and Port is too stupid to notice.

This affects many things. Same thing could be said for apache2, not just python. We need ports to not just build for the sake of building.

[andreas@…]

That cant be the problem. Then we would have had the same problem with building python25 on leopard.

[nerdling (Jeremy Lavergne)]

Replying to nyteshade@…:

Sounds to me like the biggest problem to solve here is to make Ports correctly realize there is another version already installed.

The system-provided components tend to be out of date so I don't think it's that great of an idea to bother trying to include them.

[julian@…]

Cc Me!

[posco2k5@…]

Cc Me!

[posco2k5@…]

Replying to ram@…:

Applying that patch enables the build to go further but then it fails with the error:

Failed to find the necessary bits to build these modules:
bsddb185           dl                 imageop         
linuxaudiodev      ossaudiodev        spwd            
sunaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses            _curses_panel      Nav

I've attached the full build log and a patch that updates the Portfile to apply the upstream patch and runs autoreconf to rebuild configure.

From the patch author on the upstream issue's page:

"NOTE2: the patch is for the trunk (2.7), I'll port the patch to the other branches (2.6, 3.2 and 3.1) after testing it on 10.5."

So that could be the reason for the failures? Maybe the 2.6 port will fix things.

[scooper@…]

Cc Me!

[avs@…]

Cc Me!

[xellos@…]

Cc Me!

[ok@…]

Cc Me!

[macports.b@…]

Cc Me!

[hong.rich@…]

Cc Me!

[tkiermaier@…]

Cc Me!

[james.mcbride+trac_ext@…]

Cc Me!

[jacobu@…]

Cc Me!

[smibrahim@…]

Cc Me!

[julio@…]

Cc Me!

[ed@…]

Cc Me!

[ricsmo@…]

Cc Me!

[elias-macports@…]

Cc Me!

[contact@…]

Cc Me!

[lorenbruns@…]

Cc Me!

[sebsto@…]

Cc Me!

[michal@…]

Cc Me!

[tomjmalone@…]

Cc Me!

[enderash@…]

Cc Me!

[tehcog (tehcog)]

Cc Me!

[kiwi.2008@…]

Cc Me!

[mike@…]

Cc Me!

[macports@…]

Cc Me!

[pck-macports@…]

Cc Me!

[joshmoz@…]

Cc Me!

[msaeed999@…]

Cc Me!

[gerald.gutierrez@…]

Now, with the bug logged at python.org and a patch available, what happens next and when will python26 build normally again?

[djspiewak@…]

Cc Me!

[alan.macports.sp@…]

Cc Me!

[kurtjaeke@…]

Cc Me!

[alan.macports.sp@…]

Cc Me!

[bonoba@…]

Cc Me!

[alan.macports.sp@…]

Debug build after application of upstream-6802.diff - fails during install (differs from python26.log)

[alan.macports.sp@…]

It appears for me, after applying upstream-6802.diff to trunk (which is identical to the 1.8 release) Portfile. The build fails during install while trying to run cachersrc.py. There is some google juice mentioning that this isn't needed potentially on 64-bit architectures? I did not follow the terse comments on this matter. Near as I can tell this is related to ​http://bugs.python.org/issue4165 (at least the same error pops up in their build failure).

I am building on a MacBook2,1 with svn trunk ports (after trying 1.8).

[bts@…]

Cc Me!

[lhunath@…]

Cc Me!

[monty19@…]

Cc Me!

[oliver@…]

Cc Me!

[mark@…]

Cc Me!

[ron@…]

Cc Me!

[StephenRhein@…]

Cc Me!

[tomvons@…]

Cc Me!

[brett@…]

Can those that got it to build see if you have the _locale module. Mine appears to be missing

[joey@…]

Cc Me!

[scott@…]

Cc Me!

[mark@…]

Python 2.6 currently, as is, won't be able to build nicely under 64-bit environments for MacOSX, due to the plat_mac libraries using a variety of Carbon APIs, that were completely removed in the transition to 64-bit. I started to cleanup macresources.py which called a deprecated resource fork Carbon call, and then attempted to call a newer one incorrectly. With that out of the way, I thought I was done. Then, applesingle.py complained about yet another deprecated Carbon call, FSSGet. After reading through the Mac OS 10.6 update for Carbon API ( ​http://developer.apple.com/mac/library/documentation/Carbon/Conceptual/Carbon64BitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40004381-CH1-SW1) many of the API calls I was seeing in the plat-mac directory have been deprecated. And it looks like a gargantuan effort to update these libraries.

And Python 2.6.2 is currently broken in ignoring even "--host=i686-apple-darwin10 --target=i686-apple-darwin10 --with-universal-archs=32-bit", it still attempts to build x86_64 objects at times, and even doing EXTRA_CFLAGS="-m32", two parts of the Makefile ignore this completely.

However, I was able to alter these by hand, continue doing "make", and build and install Python 2.6.2 by hand.

I updated the issue for the Python developers ( ​http://bugs.python.org/issue6802) and will have a patch shortly for both MacPorts and the Python guys. For right now, it seems the only way to get Python on Snow Leopard for 64-bit capable machines is to compile Python in 32-bit mode.

[blb@…]

Cc reporter of dup #21015.

[nyteshade@…]

Replying to mark@…:

Can you attach the patch(es) and some simple instructions on how to apply them (for mac ports noobs who are familiar with standard configure, make, make install techniques but not masters thereof)?

I'd really appreciate it. Not being able to make it build is causing me a slow down. Barring that can you show me how I can pause a sudo port install command long enough to make the changes myself and then let it continue in a way that mac ports is happy?

[andreas@…]

Cc Me!

[andreas@…]

just use the python 2.6 that ships with snow lep. Use it with virtualenv and virtualenvwrapper so you dont need to clutter your system install.

[nyteshade@…]

Sorry for being a noob, can you explain to me how those work? If I can really use the system python with mac ports and use that as an existing dependency I'd be super happy.

[nox@…]

See ​http://www.opensource.apple.com/source/python/python-44/2.6/fix/ for potential fixes

[sjcjonker@…]

Cc Me!

[lpackham@…]

Replying to andreas@…:

just use the python 2.6 that ships with snow lep. Use it with virtualenv and virtualenvwrapper so you dont need to clutter your system install.

That does not fix the problem. It's more that people like to use the macports py26-* stuff and also things like Mercurial depend on it. VirtualEnv's don't solve anything really. This in itself needs fixing.

Not sure I like the idea of it being entirely 32-bit, surely that causes problems with Apache/mod_wsgi/mod_python etc.

Is there anyway of retrofitting what Apple did for the system install of Python?

[lpackham@…]

Cc Me!

[mark@…]

Replying to lpackham@…:

Replying to andreas@…:

just use the python 2.6 that ships with snow lep. Use it with virtualenv and virtualenvwrapper so you dont need to clutter your system install.

That does not fix the problem. It's more that people like to use the macports py26-* stuff and also things like Mercurial depend on it. VirtualEnv's don't solve anything really. This in itself needs fixing.

Not sure I like the idea of it being entirely 32-bit, surely that causes problems with Apache/mod_wsgi/mod_python etc.

Is there anyway of retrofitting what Apple did for the system install of Python?

Looking over it, it's pretty hacky and involved. And they had to do some weird stuff to get Carbon 32-bit support, as seen by:

##---------------------------------------------------------------------
# python.exe was made 32-bit to build the carbon and tk stuff, and was
# then copied to Python.app.  We restore all its architectures.
##---------------------------------------------------------------------
restore-64-bit:
	install $(SYMROOT)/python.exe $(DSTROOT)$(PAMACOS)/Python

Be nice if Apple could have worked with the Python guys to integrate these changes. Sigh.

[lpackham@…]

Cc Me!

[lpackham@…]

Cc Me!

[lpackham@…]

I would be happy to not compile in the tk/carbon stuff - I use the MacPorts python for development stuff - so would be more than happy to let that side of it go. But there's no variants to disable it.

[mikkel@…]

Replying to lpackham@…:

I would be happy to not compile in the tk/carbon stuff - I use the MacPorts python for development stuff - so would be more than happy to let that side of it go. But there's no variants to disable it.

I'll second that. I have no need for any of it.

[treaves@…]

Replying to lpackham@…:

Replying to andreas@…:

just use the python 2.6 that ships with snow lep. Use it with virtualenv and virtualenvwrapper so you dont need to clutter your system install.

That does not fix the problem. It's more that people like to use the macports py26-* stuff and also things like Mercurial depend on it. VirtualEnv's don't solve anything really. This in itself needs fixing.

No, people do not like to use the macports python (and perl, and ...); they are forced to. Art least fink gives the option to use the system installed one or the fink one. MacPorts should learn a thing or two. And that excuse about broken versions Apple ships is just not accurate, or relevant.

[nerdling (Jeremy Lavergne)]

Replying to treaves@…:

No, people do not like to use the macports python (and perl, and ...); they are forced to.

I happen to enjoy having versions of python that are newer than the ones Apple distributes; it allowed me to program in python26 prior to Snow Leopard.

[lpackham@…]

Replying to snc@…:

Replying to treaves@…:

No, people do not like to use the macports python (and perl, and ...); they are forced to.

I happen to enjoy having versions of python that are newer than the ones Apple distributes; it allowed me to program in python26 prior to Snow Leopard.

What he said. I don't want to be stuck on 2.6.1 for the rest of SL's life. I happen to be doing dev on 26 and 31 - both of which are in MacPorts. I prefer using MacPorts python for versioning reasons, as well as the fact that I want random stuff littering the path - look at the poor Ruby people. They upgraded to SL and they're having no end of trouble with Apple's built in Ruby because of .dylib's compiled for extensions under Leopard no longer working.

Regardless - the bug is registered upstream. Python can't be compiled on OSX - that in itself is a bug.

[lpackham@…]

Just to add to the person saying "use virtualenv" - that doesn't work either. Hangs on virtualenv creation (sorry to pollute this bug - but aides usefulness for people coming here via Google).

[macports.org@…]

Replying to lpackham@…:

Just to add to the person saying "use virtualenv" - that doesn't work either. Hangs on virtualenv creation (sorry to pollute this bug - but aides usefulness for people coming here via Google).

Virtualenv 1.3.3 is broken indeed on SL, you need to run -dev (1.3.4b).

Go to ​http://bitbucket.org/ianb/virtualenv/, in the top right corner hover over "get source", download an archive, unpack, setup.py install and venv will be back.

[aubonbeurre@…]

Cc Me!

[kalin.f@…]

Cc Me!

[treaves@…]

Replying to snc@…:

Replying to treaves@…:

No, people do not like to use the macports python (and perl, and ...); they are forced to.

I happen to enjoy having versions of python that are newer than the ones Apple distributes; it allowed me to program in python26 prior to Snow Leopard.

You're - for some reason - confusing CAN use MacPorts with MUST use MacPorts. Don't.

[benjaminkreeger@…]

Come on, people. This isn't a chat room; this is a bug report for why MacPorts' Python26 won't build under Snow Leopard.

If you're upset about being forced to use MacPorts' build of Python, do it somewhere else. There are places for such things, and this isn't one of them. Let's at least make an attempt to stay on topic.

[lpackham@…]

Adds a +no_tikinter variant - does what it says on the tin

[lpackham@…]

Last post says +notikinter - I mean +no_tkinter obviously. Basically allows you to use the patch from upstream and have a "working" Python 2.6 that can't do any user interface stuff.

[aimail-macports@…]

Cc Me!

[macports@…]

Cc Me!

[nox@…]

Why a variant? tkinter cannot be build on SL for the moment, so let's not build it on SL for the moment.

[macports@…]

Cc Me!

[wojtekcz (Wojciech Czarnowski)]

Cc Me!

[xellos@…]

Replying to lpackham@…:

Last post says +notikinter - I mean +no_tkinter obviously. Basically allows you to use the patch from upstream and have a "working" Python 2.6 that can't do any user interface stuff.

Were you able to also install python compiled this way? I applied the patch from upstream and your patch with +no_tkinter variant and python does compile all right, but fails at installing to destroot. The error is the usual one - no attribute "FSpOpenResFile" in "cachersrc.py" script.

[flabot@…]

Cc Me!

[chairos@…]

Cc Me!

[lpackham@…]

Replying to xellos@…:

Replying to lpackham@…:

Last post says +notikinter - I mean +no_tkinter obviously. Basically allows you to use the patch from upstream and have a "working" Python 2.6 that can't do any user interface stuff.

Were you able to also install python compiled this way? I applied the patch from upstream and your patch with +no_tkinter variant and python does compile all right, but fails at installing to destroot. The error is the usual one - no attribute "FSpOpenResFile" in "cachersrc.py" script.

No, I went one step further and removed all the stuff under Mac/ that is deprecated and for removal in 3.0/3.1 (which is why python31 is able to build without much effort compared to this). My view was that if it's deprecated, I'll just remove it so I can get on.

[Veence (Vincent)]

Replying to lpackham@…:

Replying to xellos@…:

Replying to lpackham@…:

Last post says +notikinter - I mean +no_tkinter obviously. Basically allows you to use the patch from upstream and have a "working" Python 2.6 that can't do any user interface stuff.

Were you able to also install python compiled this way? I applied the patch from upstream and your patch with +no_tkinter variant and python does compile all right, but fails at installing to destroot. The error is the usual one - no attribute "FSpOpenResFile" in "cachersrc.py" script.

No, I went one step further and removed all the stuff under Mac/ that is deprecated and for removal in 3.0/3.1 (which is why python31 is able to build without much effort compared to this). My view was that if it's deprecated, I'll just remove it so I can get on.

It seems a reasonable course. I myself tried to compile on a MacBook unibody late 2008 (MacBook 5,1: no different from MacBookPro, but I cannot get a 64-bit working kernel, for whatever unknown reason) with Snow, universal variant, it fails while installing the Nav module/extension:

ImportError: No module named Nav
make[1]: *** [install_BuildApplet] Error 1
make: *** [frameworkinstallapps] Error 2

with Nav depending on the old, 32-bit QuickTime framework (should be changed for the new, 64-bit QTKit).

[mcamou@…]

Cc Me!

[ruud@…]

Cc Me!

[gtaylor@…]

Cc Me!

[xellos@…]

This will not help resolve the issue described here, but it might help a lot of people like myself, so I'm posting anyway.

If you're not interested in using pything 2.6 specifically, but instead macports compile it for you, because it's a dependency of a dependency of something you need, you might very well try to install gtk-doc and gnome-doc-utils with +python25 variants they offer. Those two ports are required by a lot of stuff and might be the only thing that blocks you from that killer app of yours. There are other ports with +python25 variant. You might look them up if those two won't bring you luck.

[aaraines@…]

Cc Me!

[bretthoerner@…]

Cc Me!

[bretthoerner@…]

Replying to lpackham@…:

Replying to xellos@…:

Replying to lpackham@…:

Last post says +notikinter - I mean +no_tkinter obviously. Basically allows you to use the patch from upstream and have a "working" Python 2.6 that can't do any user interface stuff.

Were you able to also install python compiled this way? I applied the patch from upstream and your patch with +no_tkinter variant and python does compile all right, but fails at installing to destroot. The error is the usual one - no attribute "FSpOpenResFile" in "cachersrc.py" script.

No, I went one step further and removed all the stuff under Mac/ that is deprecated and for removal in 3.0/3.1 (which is why python31 is able to build without much effort compared to this). My view was that if it's deprecated, I'll just remove it so I can get on.

Can you explain how you did this? Was it another Portfile patch or did you change stuff in the working directory? I'd love to just get mine working for now and don't care about Tk.

[lpackham@…]

From the upstream bug ​http://bugs.python.org/issue6802#msg92211 :

Author: Ronald Oussoren (ronaldoussoren)

My current plan is to fix this issue, and the issue of 64-bit universal 
builds on SL in the weekend. 

BTW. I'm not planning to fix this for 2.5 and 2.4, AFAIK both are no 
maintained beyond critical security patches.

So it looks like it'll be getting fixed upstream quite soon.

[stromnov (Andrey Stromnov)]

Cc Me!

[cronuxs@…]

Cc Me!

[TimothyC.Lee@…]

Cc Me!

[ksaito11+macport@…]

Cc Me!

[melanochaitus@…]

Cc Me!

[rob@…]

Cc Me!

[alex_a_bordeaux@…]

Cc Me!

[paolopal@…]

Cc Me!

[mike-savory]

Cc Me!

[james.herdman@…]

Cc Me!

[takashi@…]

Cc Me!

[antonin@…]

Cc Me!

[tommccullough-tenica]

Cc Me!

[lorne@…]

Cc Me!

[peterl@…]

Cc Me!

[jmroot (Joshua Root)]

r57086

[circlej1@…]

Replying to jmr@…:

r57086

it builds now, but does not activate for me:

--->  Attempting to fetch Python-2.6.2.tar.bz2 from http://distfiles.macports.org/python26
--->  Verifying checksum(s) for python26
--->  Extracting python26
--->  Applying patches to python26
--->  Configuring python26
--->  Building python26
--->  Staging python26 into destroot
--->  Installing python26 @2.6.2_4+darwin
--->  Activating python26 @2.6.2_4+darwin
Error: Target org.macports.activate returned: Image error: /Applications/MacPorts/Python 2.6/Build Applet.app/Contents/Info.plist already exists and does not belong to a registered port.  Unable to activate port python26.
Error: The following dependencies failed to build: xorg-libs xorg-libxcb python26 xorg-libpthread-stubs xorg-xcb-proto libxml2 xorg-libxkbfile xorg-libxkbui xorg-xcb-util
Error: Status 1 encountered during processing.

this is from a clean install / build (removed entire /opt tree and tried "port install blt").

[circlej1@…]

Cc Me!

[Veence (Vincent)]

Replying to jmr@…:

r57086

Nice guess, but wrong :

port -v build python26 (+universal in variants.conf)
[...]
--->  Building python26
/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 -c -arch ppc -arch i386 -isysroot /  -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include -I/usr/pkg/include -I/usr/pkg/include/ncurses  -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c

!!!! My selected universal archs are 'x86_64 i386' !

[jaques@…]

Just tried it out, builds all right and activates fine from a clean install of macports (removed /opt/local), but took it for a little spin and got this:

>>> from ctypes import sizeof, c_voidp 
>>> sizeof(c_voidp) 

8

It's not 32-bit python, unfortunately. I really want to compile 32-bit python so I can use pyglet (which relies on Carbon calls), in the future it might be nice to have a 32-bit variant for libraries which aren't compatible 64-bit python yet.

[jicheu@…]

Cc Me!

[jrminter@…]

Built and activated for me on a clean install of Macports too. Not sure why it failed before...

[antonin@…]

Cc Me!

[alan.macports.sp@…]

Cc Me!

[tobypeterson]

Leave this bug alone; it is fixed - other bugs (for example, +universal bs) should be new tickets.

[circlej1@…]

Cc Me!

[mikkel@…]

Replying to jaques@…:

Just tried it out, builds all right and activates fine from a clean install of macports (removed /opt/local), but took it for a little spin and got this:

>>> from ctypes import sizeof, c_voidp 
>>> sizeof(c_voidp) 

8

It's not 32-bit python, unfortunately. I really want to compile 32-bit python so I can use pyglet (which relies on Carbon calls), in the future it might be nice to have a 32-bit variant for libraries which aren't compatible 64-bit python yet.

In that case you'll probably have to compile Python manually or use an earlier version.

[james.mcbride+trac_ext@…]

Without clearing out /opt/local , initially it would build for me but failed in staging. Calling

port clean --all all

fixed the install issue it ran into while staging.

[ernest@…]

Cc Me!

[teddy@…]

Cc Me!

[orez.org@…]

Cc Me!

[orez.org@…]

Cc Me!

[orez.org@…]

Cc Me!