Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#20284 closed defect (fixed)

python26 fails to build 64-bit

Reported by: nerdling (Jeremy L) Owned by: blb@…
Priority: High Milestone:
Component: ports Version: 1.8.0
Keywords: LP64 Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), kentk@…, mike@…, alexguo@…, robin@…, lstoll@…, tamyrvoll@…, john+macports@…, joshua_anderson@…, huahang.liu@…, faisal.moledina@…, benjaminkreeger@…, m@…, andrius.laikina@…, dizzyd@…, xmitchx@…, treaves@…, shrift@…, tannhaus@…, tharant@…, hkroger@…, macports@…, thedoobs@…, skymoo (Adam Mercer), gerald.gutierrez@…, pkutzner+macports@…, erik.labianca@…, issaco@…, luis.beca@…, brianm@…, david@…, macports@…, albert.veli@…, julien.lusson@…, me@…, randyoo@…, macports@…, rmsfisher@…, fmaillet@…, andy@…, macports.org@…, jlaurila@…, xgutter@…, brian.cunnie@…, conradwt (Conrad Taylor), mf2k (Frank Schima), macosforge@…, deepu.sudhakar@…, nicos_pavlov@…, jan@…, nyteshade@…, julian@…, posco2k5@…, scooper@…, avs@…, xellos@…, ok@…, macports.b@…, hong.rich@…, tkiermaier@…, james.mcbride+trac_ext@…, jacobu@…, smibrahim@…, julio@…, ed@…, ricsmo@…, elias-macports@…, contact@…, lorenbruns@…, sebsto@…, michal@…, tomjmalone@…, enderash@…, tehcog (tehcog), kiwi.2008@…, mike@…, macports@…, pck-macports@…, joshmoz@…, msaeed999@…, djspiewak@…, kurtjaeke@…, bonoba@…, bts@…, lhunath@…, monty19@…, oliver@…, mark@…, ron@…, joey@…, scott@…, macportscom@…, nox@…, lpackham@…, aubonbeurre@…, kalin.f@…, aimail-macports@…, macports@…, macports@…, wojtekcz (Wojciech Czarnowski), flabot@…, chairos@…, mcamou@…, ruud@…, gtaylor@…, aaraines@…, bretthoerner@…, stromnov (Andrew Stromnov), whoburg@…, cronuxs@…, TimothyC.Lee@…, ksaito11+macport@…, melanochaitus@…, rob@…, alex_a_bordeaux@…, paolopal@…, mike-savory, james.herdman@…, takashi@…, thomas.mccullough@…, lorne@…, peterl@…, jmroot (Joshua Root), jicheu@…, antonin@…, alan.macports.sp@…, ernest@…, teddy@…, orez.org@…
Port: python26

Description

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

Attachments (10)

python26_debug.err (10.6 KB) - added by nerdling (Jeremy L) 10 years ago.
port -d isntall python26 (stderr)
python26_debug.out (48.4 KB) - added by nerdling (Jeremy L) 10 years ago.
port -d install python26 (stdout)
python26_snowleopard.patch (538 bytes) - added by kentk@… 10 years ago.
patch that forces 10.5 sdk instead of 10.6
python-install.txt.gz (69.2 KB) - added by mike@… 10 years ago.
output of sudo port -dv install python26 +universal +darwin_10 with kentk's patch applied to portfile
Makefile.pre.patch (1012 bytes) - added by mattias@… 10 years ago.
Patch for "Makefile.pre" to make libtool accept x86_64 as an architecture.
makefile.pre.patch (752 bytes) - added by mattias@… 10 years ago.
Patch for "Makefile.pre" to make libtool accept x86_64 as an architecture.
upstream-6802.diff (2.4 KB) - added by skymoo (Adam Mercer) 10 years ago.
apply patch from upstream ticket 6802
python26.log (167.0 KB) - added by skymoo (Adam Mercer) 10 years ago.
debug build log following application of patch from upstream ticket 6802
python-patch.log (857.1 KB) - added by alan.macports.sp@… 10 years ago.
Debug build after application of upstream-6802.diff - fails during install (differs from python26.log)
no_tkintervariant.diff (484 bytes) - added by lpackham@… 10 years ago.
Adds a +no_tikinter variant - does what it says on the tin

Download all attachments as: .zip

Change History (243)

Changed 10 years ago by nerdling (Jeremy L)

Attachment: python26_debug.err added

port -d isntall python26 (stderr)

Changed 10 years ago by nerdling (Jeremy L)

Attachment: python26_debug.out added

port -d install python26 (stdout)

comment:1 Changed 10 years ago by nerdling (Jeremy L)

Keywords: snowleopard added

comment:2 Changed 10 years ago by kentk@…

Cc: kentk@… added

Cc Me!

Changed 10 years ago by kentk@…

Attachment: python26_snowleopard.patch added

patch that forces 10.5 sdk instead of 10.6

comment:3 Changed 10 years ago by kentk@…

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

Build with +universal

comment:4 Changed 10 years ago by mike@…

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

Changed 10 years ago by mike@…

Attachment: python-install.txt.gz added

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

comment:5 Changed 10 years ago by mike@…

Cc: mike@… added

Cc Me!

comment:6 Changed 10 years ago by 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...

comment:7 Changed 10 years ago by mike@…

that worked, thanks!

comment:8 Changed 10 years ago by tobypeterson

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

comment:9 Changed 10 years ago by kentk@…

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

comment:10 Changed 10 years ago by blb@…

Cc: mcalhoun@… added
Owner: changed from blb@… to blb@…

There can be only one (assignee).

comment:11 Changed 10 years ago by alexguo@…

Cc: alexguo@… added

Cc Me!

comment:12 Changed 10 years ago by robin@…

Cc: robin@… added

Cc Me!

comment:13 Changed 10 years ago by lstoll@…

Cc: lstoll@… added

Cc Me!

comment:14 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by tamyrvoll@…

Cc: tamyrvoll@… added

Cc Me!

comment:16 Changed 10 years ago by john+macports@…

Cc: john+macports@… added

Cc Me!

comment:17 Changed 10 years ago by joshua_anderson@…

Cc: joshua_anderson@… added

Cc Me!

comment:18 Changed 10 years ago by huahang.liu@…

Cc: huahang.liu@… added

Cc Me!

comment:19 Changed 10 years ago by faisal.moledina@…

Cc: faisal.moledina@… added

Cc Me!

comment:20 Changed 10 years ago by tomvons@…

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

comment:21 Changed 10 years ago by tomvons@…

Cc: tomvons@… added

Cc Me!

comment:22 in reply to:  20 ; Changed 10 years ago by 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?

comment:23 Changed 10 years ago by benjaminkreeger@…

Cc: benjaminkreeger@… added

Cc Me!

comment:24 in reply to:  22 Changed 10 years ago by 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

comment:25 Changed 10 years ago by jmroot (Joshua Root)

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

comment:26 in reply to:  25 Changed 10 years ago by m@…

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

comment:27 Changed 10 years ago by m@…

Cc: m@… added

Cc Me!

comment:28 Changed 10 years ago by blb@…

Cc: andrius.laikina@… added

Cc reporter of dup #20841.

comment:29 Changed 10 years ago by dizzyd@…

Cc: dizzyd@… added

Cc Me!

comment:30 Changed 10 years ago by 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.

Changed 10 years ago by mattias@…

Attachment: Makefile.pre.patch added

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

Changed 10 years ago by mattias@…

Attachment: makefile.pre.patch added

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

comment:31 Changed 10 years ago by mattias@…

Sorry, did post the patch in the wrong format.

comment:32 Changed 10 years ago by xmitchx@…

Cc: xmitchx@… added

Cc Me!

comment:33 Changed 10 years ago by blb@…

Cc: treaves@… added

Cc reporter of dup #20870.

comment:34 Changed 10 years ago by shrift@…

Cc: shrift@… added

Cc Me!

comment:35 Changed 10 years ago by tannhaus@…

Cc: tannhaus@… added

Cc Me!

comment:36 Changed 10 years ago by tharant@…

Cc: tharant@… added

Cc Me!

comment:37 Changed 10 years ago by hkroger@…

Cc: hkroger@… added

Cc Me!

comment:38 Changed 10 years ago by michael@…

Cc: michael@… added

Cc Me!

comment:39 Changed 10 years ago by sjcjonker@…

Cc: sjcjonker@… added

Cc Me!

comment:40 Changed 10 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:41 Changed 10 years ago by thedoobs@…

Cc: thedoobs@… added

Cc Me!

comment:42 Changed 10 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:43 Changed 10 years ago by dmitrykichenko@…

Cc Me!

comment:44 Changed 10 years ago by 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.

comment:45 in reply to:  44 Changed 10 years ago by 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.

comment:46 Changed 10 years ago by 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?

comment:47 Changed 10 years ago by nerdling (Jeremy L)

Priority: LowHigh

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

comment:48 Changed 10 years ago by mattias@…

Cc: mattias@… added

Cc Me!

comment:49 Changed 10 years ago by mattias@…

Cc: mattias@… removed

Cc Me!

comment:50 in reply to:  46 Changed 10 years ago by 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.

comment:51 Changed 10 years ago by gerald.gutierrez@…

Cc: gerald.gutierrez@… added

Cc Me!

comment:52 Changed 10 years ago by pkutzner+macports@…

Cc: pkutzner+macports@… added

Cc Me!

comment:53 in reply to:  46 ; Changed 10 years ago by 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.

comment:54 in reply to:  53 Changed 10 years ago by 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

comment:55 Changed 10 years ago by macports@…

The +universal trick worked for me.

comment:56 in reply to:  55 Changed 10 years ago by huahang.liu@…

Replying to macports@…:

The +universal trick worked for me.

What's your machine?

comment:57 Changed 10 years ago by 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

comment:58 Changed 10 years ago by treaves@…

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

comment:59 Changed 10 years ago by erik.labianca@…

Cc: erik.labianca@… added

Cc Me!

comment:60 in reply to:  58 ; Changed 10 years ago by 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!

comment:61 in reply to:  57 Changed 10 years ago by 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...

comment:62 Changed 10 years ago by 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.

comment:63 Changed 10 years ago by issaco@…

Cc: issaco@… added

Cc Me!

comment:64 Changed 10 years ago by luis.beca@…

Cc: luis.beca@… added

Cc Me!

comment:65 in reply to:  60 Changed 10 years ago by 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

comment:66 Changed 10 years ago by blb@…

Upstream report is issue 6802.

comment:67 in reply to:  62 Changed 10 years ago by 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.

comment:68 Changed 10 years ago by brianm@…

Cc: brianm@… added

Cc Me!

comment:69 Changed 10 years ago by david@…

Cc: david@… added

Cc Me!

comment:70 Changed 10 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:71 Changed 10 years ago by albert.veli@…

Cc: albert.veli@… added

Cc Me!

comment:72 Changed 10 years ago by 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 :(

comment:73 Changed 10 years ago by julien.lusson@…

Cc: julien.lusson@… added

Cc Me!

comment:74 Changed 10 years ago by me@…

Cc: me@… added

Cc Me!

comment:75 in reply to:  72 Changed 10 years ago by 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.

comment:76 Changed 10 years ago by randyoo@…

Cc: randyoo@… added

Cc Me!

comment:77 Changed 10 years ago by 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

comment:78 Changed 10 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:79 in reply to:  77 Changed 10 years ago by 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.

comment:80 Changed 10 years ago by rmsfisher@…

Cc: rmsfisher@… added

Cc Me!

comment:81 Changed 10 years ago by fmaillet@…

Cc: fmaillet@… added

Cc Me!

comment:82 in reply to:  77 Changed 10 years ago by 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.

comment:83 Changed 10 years ago by 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.

comment:84 in reply to:  83 Changed 10 years ago by 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.

comment:85 Changed 10 years ago by andy@…

Cc: andy@… added

Cc Me!

comment:86 Changed 10 years ago by macports.org@…

Cc: macports.org@… added

Cc Me!

comment:87 Changed 10 years ago by jlaurila@…

Cc: jlaurila@… added

Cc Me!

comment:88 Changed 10 years ago by 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.

comment:89 in reply to:  88 ; Changed 10 years ago by 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".

comment:90 in reply to:  89 Changed 10 years ago by 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.

comment:91 Changed 10 years ago by xgutter@…

Cc: xgutter@… added

Cc Me!

comment:92 Changed 10 years ago by brian.cunnie@…

Cc: brian.cunnie@… added

Cc Me!

comment:93 Changed 10 years ago by blb@…

Cc: conradwt@… added

Cc reporter of dup #20940.

comment:94 Changed 10 years ago by 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.

comment:95 Changed 10 years ago by mf2k (Frank Schima)

Cc: macsforever2000@… added

Cc Me!

comment:96 Changed 10 years ago by michael@…

Cc: michael@… removed

Cc Me!

Changed 10 years ago by skymoo (Adam Mercer)

Attachment: upstream-6802.diff added

apply patch from upstream ticket 6802

Changed 10 years ago by skymoo (Adam Mercer)

Attachment: python26.log added

debug build log following application of patch from upstream ticket 6802

comment:97 Changed 10 years ago by 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.

comment:98 Changed 10 years ago by macosforge@…

Cc: macosforge@… added

Cc Me!

comment:99 Changed 10 years ago by deepu.sudhakar@…

Cc: deepu.sudhakar@… added

Cc Me!

comment:100 Changed 10 years ago by nicos_pavlov@…

Cc: nicos_pavlov@… added

Cc Me!

comment:101 Changed 10 years ago by jan@…

Cc: jan@… added

Cc Me!

comment:102 Changed 10 years ago by andreas@…

Cc: andreas@… added

Cc Me!

comment:103 Changed 10 years ago by 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?

comment:104 Changed 10 years ago by nyteshade@…

Cc: nyteshade@… added

Cc Me!

comment:105 Changed 10 years ago by 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.

comment:106 Changed 10 years ago by andreas@…

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

comment:107 in reply to:  105 Changed 10 years ago by nerdling (Jeremy L)

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.

comment:108 Changed 10 years ago by julian@…

Cc: julian@… added

Cc Me!

comment:109 Changed 10 years ago by posco2k5@…

Cc: posco2k5@… added

Cc Me!

comment:110 in reply to:  97 Changed 10 years ago by 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.

comment:111 Changed 10 years ago by scooper@…

Cc: scooper@… added

Cc Me!

comment:112 Changed 10 years ago by avs@…

Cc: avs@… added

Cc Me!

comment:113 Changed 10 years ago by xellos@…

Cc: xellos@… added

Cc Me!

comment:114 Changed 10 years ago by ok@…

Cc: ok@… added

Cc Me!

comment:115 Changed 10 years ago by macports.b@…

Cc: macports.b@… added

Cc Me!

comment:116 Changed 10 years ago by hong.rich@…

Cc: hong.rich@… added

Cc Me!

comment:117 Changed 10 years ago by tkiermaier@…

Cc: tkiermaier@… added

Cc Me!

comment:118 Changed 10 years ago by james.mcbride+trac_ext@…

Cc: james.mcbride+trac_ext@… added

Cc Me!

comment:119 Changed 10 years ago by jacobu@…

Cc: jacobu@… added

Cc Me!

comment:120 Changed 10 years ago by smibrahim@…

Cc: smibrahim@… added

Cc Me!

comment:121 Changed 10 years ago by julio@…

Cc: julio@… added

Cc Me!

comment:122 Changed 10 years ago by ed@…

Cc: ed@… added

Cc Me!

comment:123 Changed 10 years ago by ricsmo@…

Cc: ricsmo@… added

Cc Me!

comment:124 Changed 10 years ago by elias-macports@…

Cc: elias-macports@… added

Cc Me!

comment:125 Changed 10 years ago by contact@…

Cc: contact@… added

Cc Me!

comment:126 Changed 10 years ago by lorenbruns@…

Cc: lorenbruns@… added

Cc Me!

comment:127 Changed 10 years ago by sebsto@…

Cc: sebsto@… added

Cc Me!

comment:128 Changed 10 years ago by michal@…

Cc: michal@… added

Cc Me!

comment:129 Changed 10 years ago by tomjmalone@…

Cc: tomjmalone@… added

Cc Me!

comment:130 Changed 10 years ago by enderash@…

Cc: enderash@… added

Cc Me!

comment:131 Changed 10 years ago by tehcog (tehcog)

Cc: brewerleece@… added

Cc Me!

comment:132 Changed 10 years ago by kiwi.2008@…

Cc: kiwi.2008@… added

Cc Me!

comment:133 Changed 10 years ago by mike@…

Cc: mike@… added

Cc Me!

comment:134 Changed 10 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:135 Changed 10 years ago by pck-macports@…

Cc: pck-macports@… added

Cc Me!

comment:136 Changed 10 years ago by joshmoz@…

Cc: joshmoz@… added

Cc Me!

comment:137 Changed 10 years ago by msaeed999@…

Cc: msaeed999@… added

Cc Me!

comment:138 Changed 10 years ago by gerald.gutierrez@…

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

comment:139 Changed 10 years ago by djspiewak@…

Cc: djspiewak@… added

Cc Me!

comment:140 Changed 10 years ago by alan.macports.sp@…

Cc: alan.macports.sp@… added

Cc Me!

comment:141 Changed 10 years ago by kurtjaeke@…

Cc: kurtjaeke@… added

Cc Me!

comment:142 Changed 10 years ago by alan.macports.sp@…

Cc: alan.macports.sp@… removed

Cc Me!

comment:143 Changed 10 years ago by bonoba@…

Cc: bonoba@… added

Cc Me!

Changed 10 years ago by alan.macports.sp@…

Attachment: python-patch.log added

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

comment:144 Changed 10 years ago by 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).

comment:145 Changed 10 years ago by bts@…

Cc: bts@… added

Cc Me!

comment:146 Changed 10 years ago by lhunath@…

Cc: lhunath@… added

Cc Me!

comment:147 Changed 10 years ago by monty19@…

Cc: monty19@… added

Cc Me!

comment:148 Changed 10 years ago by oliver@…

Cc: oliver@… added

Cc Me!

comment:149 Changed 10 years ago by mark@…

Cc: mark@… added

Cc Me!

comment:150 Changed 10 years ago by ron@…

Cc: ron@… added

Cc Me!

comment:151 Changed 10 years ago by StephenRhein@…

Cc Me!

comment:152 Changed 10 years ago by tomvons@…

Cc: tomvons@… removed

Cc Me!

comment:153 Changed 10 years ago by brett@…

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

comment:154 Changed 10 years ago by joey@…

Cc: joey@… added

Cc Me!

comment:155 Changed 10 years ago by scott@…

Cc: scott@… added

Cc Me!

comment:156 Changed 10 years ago by 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.

comment:157 Changed 10 years ago by blb@…

Cc: macportscom@… added

Cc reporter of dup #21015.

comment:158 in reply to:  156 Changed 10 years ago by 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?

comment:159 Changed 10 years ago by andreas@…

Cc: andreas@… removed

Cc Me!

comment:160 Changed 10 years ago by 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.

comment:161 Changed 10 years ago by 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.

comment:162 Changed 10 years ago by nox@…

Cc: nox@… added

comment:163 Changed 10 years ago by sjcjonker@…

Cc: sjcjonker@… removed

Cc Me!

comment:164 in reply to:  160 ; Changed 10 years ago by 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?

comment:165 Changed 10 years ago by lpackham@…

Cc: lpackham@… added

Cc Me!

comment:166 in reply to:  164 Changed 10 years ago by 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.

comment:167 Changed 10 years ago by lpackham@…

Cc: lpackham@… removed

Cc Me!

comment:168 Changed 10 years ago by lpackham@…

Cc: lpackham@… added

Cc Me!

comment:169 Changed 10 years ago by 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.

comment:170 in reply to:  169 Changed 10 years ago by 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.

comment:171 in reply to:  164 ; Changed 10 years ago by 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.

comment:172 in reply to:  171 ; Changed 10 years ago by nerdling (Jeremy L)

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.

comment:173 in reply to:  172 Changed 10 years ago by 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.

comment:174 Changed 10 years ago by 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).

comment:175 in reply to:  174 Changed 10 years ago by 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.

comment:176 Changed 10 years ago by aubonbeurre@…

Cc: aubonbeurre@… added

Cc Me!

comment:177 Changed 10 years ago by kalin.f@…

Cc: kalin.f@… added

Cc Me!

comment:178 in reply to:  172 Changed 10 years ago by 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.

comment:179 Changed 10 years ago by 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.

Changed 10 years ago by lpackham@…

Attachment: no_tkintervariant.diff added

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

comment:180 Changed 10 years ago by 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.

comment:181 Changed 10 years ago by aimail-macports@…

Cc: aimail-macports@… added

Cc Me!

comment:182 Changed 10 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:183 Changed 10 years ago by nox@…

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

comment:184 Changed 10 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:185 Changed 10 years ago by wojtekcz (Wojciech Czarnowski)

Cc: wcz@… added

Cc Me!

comment:186 in reply to:  180 ; Changed 10 years ago by 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.

comment:187 Changed 10 years ago by flabot@…

Cc: flabot@… added

Cc Me!

comment:188 Changed 10 years ago by chairos@…

Cc: chairos@… added

Cc Me!

comment:189 in reply to:  186 ; Changed 10 years ago by 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.

comment:190 in reply to:  189 Changed 10 years ago by 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).

comment:191 Changed 10 years ago by mcamou@…

Cc: mcamou@… added

Cc Me!

comment:192 Changed 10 years ago by ruud@…

Cc: ruud@… added

Cc Me!

comment:193 Changed 10 years ago by gtaylor@…

Cc: gtaylor@… added

Cc Me!

comment:194 Changed 10 years ago by 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.

comment:195 Changed 10 years ago by aaraines@…

Cc: aaraines@… added

Cc Me!

comment:196 Changed 10 years ago by bretthoerner@…

Cc: bretthoerner@… added

Cc Me!

comment:197 in reply to:  189 Changed 10 years ago by 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.

comment:198 Changed 10 years ago by 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.

comment:199 Changed 10 years ago by stromnov (Andrew Stromnov)

Cc: stromnov@… added

Cc Me!

comment:200 Changed 10 years ago by tobypeterson

Cc: whoburg@… added

comment:201 Changed 10 years ago by cronuxs@…

Cc: cronuxs@… added

Cc Me!

comment:202 Changed 10 years ago by TimothyC.Lee@…

Cc: TimothyC.Lee@… added

Cc Me!

comment:203 Changed 10 years ago by ksaito11+macport@…

Cc: ksaito11+macport@… added

Cc Me!

comment:204 Changed 10 years ago by melanochaitus@…

Cc: melanochaitus@… added

Cc Me!

comment:205 Changed 10 years ago by rob@…

Cc: rob@… added

Cc Me!

comment:206 Changed 10 years ago by alex_a_bordeaux@…

Cc: alex_a_bordeaux@… added

Cc Me!

comment:207 Changed 10 years ago by paolopal@…

Cc: paolopal@… added

Cc Me!

comment:208 Changed 10 years ago by mike-savory

Cc: msavory@… added

Cc Me!

comment:209 Changed 10 years ago by james.herdman@…

Cc: james.herdman@… added

Cc Me!

comment:210 Changed 10 years ago by takashi@…

Cc: takashi@… added

Cc Me!

comment:211 Changed 10 years ago by antonin@…

Cc Me!

comment:212 Changed 10 years ago by thomas.mccullough@…

Cc: thomas.mccullough@… added

Cc Me!

comment:213 Changed 10 years ago by lorne@…

Cc: lorne@… added

Cc Me!

comment:214 Changed 10 years ago by peterl@…

Cc: peterl@… added

Cc Me!

comment:215 Changed 10 years ago by jmroot (Joshua Root)

Cc: jmr@… added
Keywords: LP64 added; snowleopard removed
Resolution: fixed
Status: newclosed
Summary: python26 fails to build on 10.6python26 fails to build 64-bit

comment:216 in reply to:  215 Changed 10 years ago by 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").

comment:217 Changed 10 years ago by circlej1@…

Cc: circlej1@… added

Cc Me!

comment:218 in reply to:  215 Changed 10 years ago by Veence (Vincent)

Resolution: fixed
Status: closedreopened

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' !

comment:219 Changed 10 years ago by 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.

comment:220 Changed 10 years ago by jicheu@…

Cc: jicheu@… added

Cc Me!

comment:221 Changed 10 years ago by jrminter@…

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

comment:222 Changed 10 years ago by antonin@…

Cc: antonin@… added

Cc Me!

comment:223 Changed 10 years ago by alan.macports.sp@…

Cc: alan.macports.sp@… added

Cc Me!

comment:224 Changed 10 years ago by tobypeterson

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

comment:225 Changed 10 years ago by tobypeterson

Resolution: fixed
Status: reopenedclosed

comment:226 Changed 10 years ago by circlej1@…

Cc: circlej1@… removed

Cc Me!

comment:227 in reply to:  219 Changed 10 years ago by 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.

comment:228 Changed 10 years ago by 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.

comment:229 Changed 10 years ago by ernest@…

Cc: ernest@… added

Cc Me!

comment:230 Changed 10 years ago by teddy@…

Cc: teddy@… added

Cc Me!

comment:231 Changed 10 years ago by orez.org@…

Cc: orez.org@… added

Cc Me!

comment:232 Changed 10 years ago by orez.org@…

Cc: orez.org@… removed

Cc Me!

comment:233 Changed 10 years ago by orez.org@…

Cc: orez.org@… added

Cc Me!

Note: See TracTickets for help on using tickets.