Installation of Py3.0rc1 fails on Mac OS X with bad locale

[Mario Ruggier]

Hi,

i had the following problem when installing py3.0rc1 on a Mac OS X
10.5.5. On this system, the default locale values are:

$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

but "UTF-8" is is not a value for LC_CTYPE that is valid for python.
Proceeding with the above settings, doing configurie/make of py3.0rc1
fails:

$ cd Python-3.0rc1
$ ./configure
.... # seems to goes ok
$ make
.... # lots of omitted info output
ranlib: file: libpython3.0.a( pymath.o) has no symbols
gcc -o python.exe \
Modules/python.o \
libpython3.0.a -ldl
make: *** [sharedmods] Error 1

So, after some poking, I change the value of LC_CTYPE as follows:

$ LC_CTYPE=
$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

And then redoing the configure/make/install steps seems to all go OK:

$ make clean
$ ./configure
$ make
$ make test
$ sudo make altinstall

$ python3.0 -c "import locale; print(locale.ge tdefaultlocale( ));"
(None, 'mac-roman')

Plus, running the newly installed python3.0 in the same terminal
window seems to be just fine. However, when I start a new terminal
(thus LC_CTYPE is back to its default value of "UTF-8") and run
python3.0 again, there are no errors but there is never any output!
For example:

$ python3.0 -c "import locale; print(locale.ge tdefaultlocale( ));"
$ python3.0
Python 3.0rc1 (r30rc1:66499, Oct 19 2008, 10:54:25)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright" , "credits" or "license" for more information.

>>dir()
>>>

If I however re-unset LC_CTYPE, as above, then stdout to console seems
to work fine again. For completeness and curiosity, on the same system
py2.6 and py2.5 give the following locale info:

$ python2.6 -c "import locale; print locale.getdefau ltlocale();"
(None, 'mac-roman')
$ python -c "import locale; print locale.getdefau ltlocale();"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/System/Library/Frameworks/Python.framewor k/Versions/2.5/lib/
python2.5/locale.py", line 441, in getdefaultlocal e
return _parse_localena me(localename)
File "/System/Library/Frameworks/Python.framewor k/Versions/2.5/lib/
python2.5/locale.py", line 373, in _parse_localena me
raise ValueError, 'unknown locale: %s' % localename
ValueError: unknown locale: UTF-8

I think this issue is related to the (currently open) "Python fails
silently on bad locale" bug:

http://bugs.python.org/issue2173

How should this issue be worked around or dealt with? Should users on
Mac OS X 10.5 change the default value of LC_CTYPE? To what?

mario

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: Installation of Py3.0rc1 fails on Mac OS X with bad locale

How should this issue be worked around or dealt with? Should users on

Mac OS X 10.5 change the default value of LC_CTYPE? To what?

It would be best if a Mac user could propose a patch for that problem
before the release of Python 3.0.

Regards,
Martin

[mr]

Re: Installation of Py3.0rc1 fails on Mac OS X with bad locale

On Nov 1, 4:40 pm, "Martin v. Löwis" <mar...@v.loewi s.dewrote:

>
It would be best if a Mac user could propose a patch for that problem
before the release of Python 3.0.

Not sure if this would qualify as a patch, but a workaround that seems
to be working for me is to change the bash environment's default
locale setting -- to a value acceptable to py3.

I did this by adding the following line to /etc/profile:

export LC_ALL="en_US.U TF-8"

Presumably, other valid values should also work correctly.

mario

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: Installation of Py3.0rc1 fails on Mac OS X with bad locale

Not sure if this would qualify as a patch, but a workaround that seems

to be working for me is to change the bash environment's default
locale setting -- to a value acceptable to py3.
>
I did this by adding the following line to /etc/profile:
>
export LC_ALL="en_US.U TF-8"

It's not a patch - as you say, it's a workaround. It's not clear to me
whether this has potentially negative side effects, such as other
programs now breaking.

Regards,
Martin