On 27-aug-04, at 2:49, Nick Bastin wrote: > > On Aug 26, 2004, at 7:41 PM, Brett C. wrote: > >> Martin v. Löwis wrote: >> >>> Brett C. wrote: >>>> Personally I would like to turn off the test on OS X for now and >>>> then try to see if there is a proper way to solve this. >>> In what way does that help? The test shows that the locale module is >>> broken on OS X. So the only sensible options are to remove the module >>> (or atleast the relevant functions), or to fix them. >> >> I have an idea for detecting a broken setlocale. When configure.in >> does its compiling does it compile with the same flags that the >> Makefile uses for compiling? If it does we can test for something we >> know will be different (fr_FR has a different decimal point, for >> instance) and compare them and then have a value in pyconfig.h to >> signal that a busted setlocale exists. setlocale can then raise >> locale.Error automatically for platforms that have that macro >> defined. But the test has to be compiled with the ``-framework >> CoreFoundation`` option or else this won't work. > > I think we should actually just fix this, rather than removing locale > support for MacOS X builds. The trick is that we need to call > __setonlyClocaleconv() again, to remove the protection against calling > setlocale() in framework builds (why they did this in the first place > is beyond me). Seems like it should be an easy gate against darwin, > and then call that on startup. Why do you think it is save to re-enable setlocale? There must be some reason for disabling setlocale. If you re-enable setlocale some random CoreFoundation function might suddenly fail. Ronald
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4