Ronald Oussoren added the comment:
Why does you patch test for -mno-fused-madd? If it isn't actually needed
for something I'd rather not have that logic in the configure file,
determining which bits of that file are actually needed for supported
OS-es is hard enough as it is.
-Wno-long
Ronald Oussoren added the comment:
jyasskin: could you test apple_gcc_flags.diff? That's a version of your
patch where configure tests if GCC supports -Wno-long-double and -no-
cpp-precomp.
NOTE: the patch doesn't update configure, you'll have to run autoconf
after applying it.
NOTE2
Changes by Ronald Oussoren:
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1779871
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman
Changes by Ronald Oussoren:
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1779871
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman
Ronald Oussoren ronaldousso...@mac.com added the comment:
On 27 Nov, 2010, at 0:42, Terry J. Reedy wrote:
Terry J. Reedy tjre...@udel.edu added the comment:
Is this a duplicate of other issues (close?)?
I don't know yet.
Is this an Apple problem beyond our control (close?)?
This might
Ronald Oussoren ronaldousso...@mac.com added the comment:
Ned: I was thinking of Issue6075
The patch in that issue needs work, IIRC I was pretty sure at the time that the
patch was too large and changed more code that it should have.
Sadly enough I have barely had time to do any open-source
New submission from Ronald Oussoren ronaldousso...@mac.com:
I just noticed that distutils creates an egg-info for the stdlib while
installing Python.
This definitely happens for Python 2.7 and Python 3.2 (both framework builds on
OSX).
In lib-dynload there is and egg-info file: Python-2.7.1
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9227
Ronald Oussoren ronaldousso...@mac.com added the comment:
Ned: why does the patch change the signature of close_all_callback?
-def close_all_callback(self, event):
+def close_all_callback(self, *args, **kwds):
--
___
Python tracker rep
Ronald Oussoren ronaldousso...@mac.com added the comment:
UTF-8 works on SuSE Enterprise Linux 9 and 10 as well.
BTW, neither UTF8 nor UTF-8 work on HPUX 10. That platform requires spelling it
as utf8.
This sadly enought means that this code doesn't work on HPUX 10:
locale.setlocale
Ronald Oussoren ronaldousso...@mac.com added the comment:
Ned: never mind the command callback has a different signature than a
keybinding.
Committed the patch for 3.2 in r87119.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ronald Oussoren ronaldousso...@mac.com added the comment:
The patch binds the menu to Ctrl-Button-1 (that is, the way you open context
menu's on OSX systems with a single button), however rightclick still doens't
work (but does an X11-style paste operation).
I propose adding an explicit
Ronald Oussoren ronaldousso...@mac.com added the comment:
Merged to 3.1.x in r87120, merged to 2.7. in r87121.
Ned: thanks for looking into this, doubly so because Tk-on-OSX is involved.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
Ronald Oussoren ronaldousso...@mac.com added the comment:
Fixed in r87122.
Thanks you.
--
resolution: - accepted
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ronald Oussoren ronaldousso...@mac.com added the comment:
(reopening to ensure glyph's message doesn't get lost)
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8084
Ronald Oussoren ronaldousso...@mac.com added the comment:
Yet another prove of how much Tk sucks on OSX.
I'm not too happy about only binding Ctrl+button-1, because users will expect
that this is means that button-2 works as well. But if we cannot disable the
default button-2 binding we'll
Ronald Oussoren ronaldousso...@mac.com added the comment:
Oops, 's/prove/proof/'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10404
Ronald Oussoren ronaldousso...@mac.com added the comment:
I agree with Martin that this is a tricky one.
The file is problematic because it is invalid XML[1], however Apple's tools are
perfectly happy to proces the file and as Mitchell notes plistlib exists to
interoperate with Apple's plist
New submission from Ronald Oussoren ronaldousso...@mac.com:
I ran into this issue while debugging why py2app doesn't work with python
3.2rc2. The reason seems to be a regression w.r.t. having the stdlib inside a
zipfile.
Note that I haven't tested this without going through py2app yet
Ronald Oussoren ronaldousso...@mac.com added the comment:
The python32.zip file generated by py2app contains both files from the stdlib
and application files. I cannot avoid haveing non-ascii filenames when a
python package contains data files that have such names.
The patch in Issue10972
Ronald Oussoren ronaldousso...@mac.com added the comment:
Data files can be anything that can be a data-file in a setuptools/distribute
setup.py file. Note that #10972 isn't necessary when python32.zip is build
using the zipfile module, _encodeFilenameFlags uses either ASCII or UTF-8
Ronald Oussoren ronaldousso...@mac.com added the comment:
Michael: Why must the subprocess started by IDLE be in 32-bit mode if we'd run
IDLE in 32-bit mode? AFAIK there is no technical reason to do so.
Not that running IDLE in 32-bit mode is an option, it wouldn't fix the issue by
itself
Ronald Oussoren ronaldousso...@mac.com added the comment:
On 25 Jan, 2011, at 13:41, Michael Foord wrote:
Michael Foord mich...@voidspace.org.uk added the comment:
Ronald: The subprocess also uses Tkinter (right?) so would also require
32bit.
Not AFAIK. I'm pretty sure I've had a 3
Ronald Oussoren ronaldousso...@mac.com added the comment:
Use:
configure ...[other args]... MACOSX_DEPLOYMENT_TARGET=10.5
(or 10.6 when you're on a 10.6 system)
This will build using the deployment target you mention, and will automaticly
include the readline module using Apple's
Ronald Oussoren ronaldousso...@mac.com added the comment:
I'm -0 on removing extras. Having extra's at this location makes it easier to
discover them.
Adding a link to the documention is a good idea, it makes the documentation
easier to use without starting IDLE.
Adding an uninstall option
Ronald Oussoren ronaldousso...@mac.com added the comment:
Can you provide a script that shows the problem? Without such a script it will
be hard to reproduce, and fix, this problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ronald Oussoren ronaldousso...@mac.com added the comment:
'make install' works for me as well (OSX 10.6, configure
--prefix=/tmp/python32).
Could you attach the output of make install, with some luck there will be a
clear indication of why the install doesn't work on your machine
New submission from Ronald Oussoren:
Py_Finalize cleans up the thread state by first calling _PyGILState_Fini
and then calling PyInterpreterState_Clear. The latter can cause user
code to run, which could use the GILState API and this then causes a
crash.
The attached file 'threads.py' causes
Ronald Oussoren added the comment:
I don't have a patch. I don't even know enough of the threading
infrastructure to know if this really a bug or if it is a bug in my
code.
I'll work on a patch this weekend, if changing the order of calls to
PyGILState_Fini and PyInterpreterState_Clear
Ronald Oussoren added the comment:
The attached patch fixes the crash, but I haven't verified if the patch
is actually correct.
With this patch some PyThread API's are called after PyInterpreterState_Clear
and I don't know if it is valid to do so. All
unittests pass fine on OSX though
Ronald Oussoren added the comment:
This is not a mac-specific issue, the script happens to be mac-specific
because that's how I found the issue.
Amaury's patch adds a unittest that reproduces the problem in a
platform-indepenent way using ctypes.
The _PyGILState_Fini function might cause
Ronald Oussoren added the comment:
This issue is fixed in the trunk and python2.5 branch.
To work around this issue with the 2.5.1 source tree you have to set
MACOSX_DEPLOYMENT_TARGET when configuring python:
../configure insert-args-here MACOSX_DEPLOYMENT_TARGET=10.3
(the value 10.3
New submission from Ronald Oussoren:
The scriptlet below hangs (as expected) but is also not interuptable by
Ctrl+C, at least on Linux and Mac OS X:
from Queue import Queue, Empty, Full
q = Queue()
q.get(True)
This is due to Threading.Condition.wait not being interuptable
Ronald Oussoren added the comment:
The change in the trunk seems like a good backport candidate, it fixes
an issue with float conversion on OSX compared to other platforms.
That said, I don't like the patch. This makes the current behaviour of
converting float NaN's to 0 the defined behaviour
New submission from Ronald Oussoren:
test_decimal fails on Mac OS X 10.3 when using Python 2.5.2c1. I haven't
tested other python versions. The same test passes on OSX 10.4 and 10.5
(both on Intel and PPC machines), this was done using the same binaries
(the Python.org build for 2.5.2c1
Ronald Oussoren added the comment:
I did an upgrade install on the OSX 10.3. Doing a clean install removes
the problem.
I'm therefore closing this issue as invalid. Sorry about the noise.
--
resolution: - invalid
status: open - closed
__
Tracker
Ronald Oussoren added the comment:
OSX installer is lame. The only way to work around this is to have pre-
and/or post-install hooks that remove the stdlib (but not site-
packages).
As this only affects the unittests I don't think this is worth the
problem right now. Especially because I have
Ronald Oussoren added the comment:
That's a good idea. I'll try to get this into the installer before 2.5.2
is actually released.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2114
Ronald Oussoren [EMAIL PROTECTED] added the comment:
Unassigned as I'm unlikely to work on this.
BTW. My guess guess would be that this is an issue with Tk, not IDLE.
--
assignee: ronaldoussoren -
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Ronald Oussoren ronaldousso...@mac.com added the comment:
The issue is indeed gone in HEAD. I've also verified the other 3 active
branches.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep
Ronald Oussoren ronaldousso...@mac.com added the comment:
The attached version should fix the issue found by Stefan. I'm going to do
builds on OSX as well as Linux before committing though.
--
Added file: http://bugs.python.org/file17316/issue7724-v3.patch
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've verified that HEAD for both 3.1 and 3.2 build fine now, hence this issue
can be closed.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
assignee: - ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8455
Ronald Oussoren ronaldousso...@mac.com added the comment:
It prefer if it were clear why these tests fail (but don't have time to look
into this at the moment). That is, I don't mind if the tests get disabled on
darwin, but only if there is a documented reason for it because otherwise
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've filed an issue for this in the Tcl/Tk tracker:
https://sourceforge.net/tracker/?func=detailaid=3002320group_id=10894atid=110894
(Assuming that this is the canonical tracker for the Tcl/Tk project, it was the
first hit in google
Ronald Oussoren ronaldousso...@mac.com added the comment:
BTW. Another way of testing, assuming you have two accounts: use 'su -
otheraccount' to get a shell session as another user then try to start tk using:
import Tkinter
root = Tkinter.Tk()
This will currently crash the interpreter due
Ronald Oussoren ronaldousso...@mac.com added the comment:
The attached patch is a first start at working around the crash. With this
patch I can use Tk without a crash:
import Tkinter
Tkinter.Tk()
Sun May 16 12:11:08 Rivendell.local python.exe[55984] Error: kCGErrorFailure:
Set a breakpoint
Ronald Oussoren ronaldousso...@mac.com added the comment:
Something I forgot to mention: the patch introduces _tkinter.m to enable
compiling the _tkinter extension as Objective-C code. The compiler also
supports passing -x objective-c to compile _tkinter.c in Objective-C mode,
but this flag
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
assignee: - ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5766
Ronald Oussoren ronaldousso...@mac.com added the comment:
One way to fix this: is to always recreate MANIFEST when an explicit
MANIFEST.in file exists, as in the attached patch.
(The patch is not perfect: I'd rename template_newer before committing)
--
keywords: +needs review, patch
New submission from Ronald Oussoren ronaldousso...@mac.com:
Output of test_distutils on a older SuSE Linux system:
FAILED (errors=1, skipped=5)
Traceback (most recent call last):
File ../Lib/test/test_distutils.py, line 18, in module
test_main()
File ../Lib/test/test_distutils.py, line
Ronald Oussoren ronaldousso...@mac.com added the comment:
$ compress --version
compress - sharutils 4.2c
And yes, this is jucky behavior. Most systems shouldn't be affected by this
because sharutils isn't used a lot these days.
--
___
Python
Ronald Oussoren ronaldousso...@mac.com added the comment:
Tk has a different tracker than tcl itself, the upstream issue is now
https://sourceforge.net/tracker/?func=detailaid=3002484group_id=12997atid=112997
--
___
Python tracker rep
Ronald Oussoren ronaldousso...@mac.com added the comment:
I'd also skip the test, this is not a bug in Python but a broken compress
executable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8730
Ronald Oussoren ronaldousso...@mac.com added the comment:
The --user directory for framework installs of python on OSX has changed from a
subdirectory of ~/.local to a subdirectory ~/Library. As described in the NEWS
file:
- Issue #8084: PEP 370 now conforms to system conventions
Ronald Oussoren ronaldousso...@mac.com added the comment:
Shridar: that is correct a framework install will not look in ~/.local, but
only in ~/Library/Python/2.7 (there is an install scheme in distutils that
describes the exact layout).
Technically the name Python subdirectory
Ronald Oussoren ronaldousso...@mac.com added the comment:
The patch somewhat works, in that it makes test_py3kwarn pass but I'd add more
filterwarning calls:
filterwarnings(ignore, .*the icglue module is removed,
DeprecationWarning)
filterwarnings(ignore
New submission from Ronald Oussoren ronaldousso...@mac.com:
It would be nice if the binary installer supported both Tk 8.4 and Tk 8.5: the
former is present on all current versions of OSX as part of the system, the
latter is the only one that is supported in 64-bit code on OSX 10.6.
A number
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
assignee: ronaldoussoren -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8798
Ronald Oussoren ronaldousso...@mac.com added the comment:
The root cause of this test failure is that test_macos runs before
test_py3kwarn.
That causes MacOS to be imported before test_py3k runs and that results in not
raising the py3k warning by the time test_py3kwarn runs.
I propose
Ronald Oussoren ronaldousso...@mac.com added the comment:
The pythonw executable always uses execv on OSX 10.4 because posix_spawnv isn't
available there.
A possibly significant change is the value of argv[0] as passed to the
Python.app executable.
Could you check if this patch fixes
Ronald Oussoren ronaldousso...@mac.com added the comment:
Note that the subject is not entirely correct: the framework install is a
framework install, but the python commandline doesn't behave like an
application bundle.
--
priority: normal - high
stage: - needs patch
Ronald Oussoren ronaldousso...@mac.com added the comment:
Thanks for testing.
I've applied the patch (with some additional documentation) in r81649 (2.7) and
r81650 (3.2). Other versions are not affected.
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've applied a new version of the patch in r81662.
I'll be monitoring the buildbot farm to ensure that any issues that might crop
up get fixed ASAP.
--
___
Python tracker rep
Ronald Oussoren ronaldousso...@mac.com added the comment:
Patchs looks file, although the 'None' branch might be a bit too fancy. I
haven't found a spec either, and therefore your code is probably the safest way
to deduce a mask.
--
assignee: - ronaldoussoren
nosy: +ronaldoussoren
Ronald Oussoren ronaldousso...@mac.com added the comment:
2.7 and 3.x use the SystemConfiguration framework (through the _scproxy
extension)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8883
Ronald Oussoren ronaldousso...@mac.com added the comment:
Ported to 3.2 in r81673.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7724
Ronald Oussoren ronaldousso...@mac.com added the comment:
Committed for 2.6 in r81674
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7724
Ronald Oussoren ronaldousso...@mac.com added the comment:
And for 3.1 in r81677.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7724
Ronald Oussoren ronaldousso...@mac.com added the comment:
I haven't looked at the actual test yet, but the filesystem encoding on OSX is
UTF-8.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8965
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
nosy: -ronaldoussoren
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8142
___
___
Python
Ronald Oussoren ronaldousso...@mac.com added the comment:
This is no longer a problem, I cannot reproduce the issue with the current
trunk.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've fixed this issue for the 3.2 branch in r81999.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8577
Ronald Oussoren ronaldousso...@mac.com added the comment:
Sigh. test.test_distutils behaves different when run through regrtest than when
run directly.
I have a fix, but am running an extended test cycle before committing (that is,
both with and without srcdir==builddir
Ronald Oussoren ronaldousso...@mac.com added the comment:
This should be fixed in r82005, this passes all tests both with and without
srcdir==builddir
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8577
Ronald Oussoren ronaldousso...@mac.com added the comment:
Tarek: I'm not 100% that all my changes in Lib/distutils were backported to
3.1. This last patch definitely wasn't, but isn't also isn't relevant for 3.1.
--
___
Python tracker rep
Ronald Oussoren ronaldousso...@mac.com added the comment:
I'll fire up my 10.4 system to further investigate this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9046
Ronald Oussoren ronaldousso...@mac.com added the comment:
A patch to fix this issue would be appreciated. However, there is are two
reasons why _tkinter is build for 32-bit architectures only:
1) Apple didn't ship a 64-bit Tk until OSX 10.6, and that is Tk 8.5 while
earlier releases of the OS
Ronald Oussoren ronaldousso...@mac.com added the comment:
The mac-related code in urllib is correct, it uses the SystemConfiguration
framework on MacOSX to get the proxy settings. That said, the code in _scproxy
is not entirly correct, it makes the wrong assumption w.r.t. the value
Ronald Oussoren ronaldousso...@mac.com added the comment:
This should be fixed with r82149.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8446
Ronald Oussoren ronaldousso...@mac.com added the comment:
I've applied my patch in r82150, which fixes the issue for me in the trunk.
I'll merge the patch into the other branches if this does indeed fix the
buildbot issue.
--
___
Python tracker rep
Ronald Oussoren ronaldousso...@mac.com added the comment:
Odd, unless someone already checked in a fix on the trunk.
I currently have a clean test run on the trunk on OSX 10.6.4 (intel). I haven't
checked this on my 10.5 VM yet.
--
___
Python
Ronald Oussoren ronaldousso...@mac.com added the comment:
Stefan: we already new that, see msg105018.
This issue was closed as fixed because the uuid module contains a workaround
for this issue (by not using the broken C API on OSX 10.6).
It seems that OSX 10.5.8 and 10.4 is also affected
Ronald Oussoren ronaldousso...@mac.com added the comment:
Bill, please test the patch below on a 10.5 system:
Index: Lib/uuid.py
===
--- Lib/uuid.py (revision 82148)
+++ Lib/uuid.py (working copy)
@@ -416,7 +416,7 @@
import
Ronald Oussoren ronaldousso...@mac.com added the comment:
scott:
* Which OSX version are you using?
* Which Python are you using?
- What is the value of sys.prefix?
- How did you install it?
* Does 'import readline' work?
--
___
Python
Ronald Oussoren ronaldousso...@mac.com added the comment:
Pavel: does the problem also happen with newer versions of Python?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8938
Ronald Oussoren ronaldousso...@mac.com added the comment:
Sigh.
-isysroot was added to CPPFLAGS because Python wouldn't build as a universal
binary anymore due a fix for issue 1628484. (According to the SVN log for
r80187).
I'll see what can be done to avoid adding -isysroot twice
Ronald Oussoren ronaldousso...@mac.com added the comment:
R. David Murray: the issue you refer to isn't the one you intend to link to, it
is related to proxy settings and doesn't contain a patch related to firefox.
--
___
Python tracker rep
Ronald Oussoren ronaldousso...@mac.com added the comment:
BTW. The firebox-bin binary in Firefox.app/Contents/MacOS does not support the
command-line arguments that Firefox on Linux supports. That is, the following
command does not work:
/Applications/Firefox.app/Contents/MacOS/firefox-bin
Changes by Ronald Oussoren ronaldousso...@mac.com:
--
assignee: - ronaldoussoren
components: +Macintosh -None
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3362
Ronald Oussoren ronaldousso...@mac.com added the comment:
Then why bother providing binaries?
I'm trying to keep the OSX port in good shape, but at times have to hunt down
issues that were introduced by other bugfixes.
A problem with adding OSX to the list of stable buildbots is IMHO
Ronald Oussoren ronaldousso...@mac.com added the comment:
I'm closing this issue:
1) webbrowser.get(firefox) currently works
2) firefox on OSX doesn't provide hooks to open tabs instead of windows
(neither through the command line nor though AppleScript) which means that the
'new
Ronald Oussoren ronaldousso...@mac.com added the comment:
Marc-Andre: what version of Xcode do you use? (the version in the About menu of
Xcode.app).
I'm getting clean builds with '--enable-universalsdk' on OSX 10.4.11 (PPC) with
Xcode 2.5 (the last Xcode for OSX 10.4). That is, all extension
Ronald Oussoren ronaldousso...@mac.com added the comment:
Reaction from scot w.r.t. my questions:
os x 10.5.8
python 2.5.1
/System/Library/Frameworks/Python.framework/Versions/2.5
came default with system
i'm going to try activestate python 2.6 and see if that solves the problem.
import
Ronald Oussoren ronaldousso...@mac.com added the comment:
Some notes: The system python on OSX 10.5 and 10.6 is linked to libedit, not
GNU readline, and doesn't seem to contain patches that convert stdlib usage of
readline APIs to the correct way to bind keystrokes to action with libedit
Ronald Oussoren ronaldousso...@mac.com added the comment:
This (untested) patch should fix the issue for the cmd module:
+++ Lib/cmd.py (working copy)
@@ -112,7 +112,18 @@
import readline
self.old_completer = readline.get_completer
Ronald Oussoren ronaldousso...@mac.com added the comment:
What I don't quite understand is why the build fails for you but passes for me.
What configure flags did you use?
This version should fare better:
def is_macosx_sdk_path(path):
Returns True if 'path' can be located in an OSX
Ronald Oussoren ronaldousso...@mac.com added the comment:
The search code must look in the SDK and not fall back on looking into the
system to avoid finding new headers and libraries when trying to build using an
older SDK on a newer system.
I don't think this is a problem at the moment
Ronald Oussoren ronaldousso...@mac.com added the comment:
I don't agree that there must be an option to fall back to system provided
libs. The point of using an SDK is to avoid doing that because you might end up
with a binary that won't work on an earlier version of the OS (the OpenSSL one
Ronald Oussoren ronaldousso...@mac.com added the comment:
I tested on OSX with a current version of FF and it didn't work.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7192
1 - 100 of 2417 matches
Mail list logo
