This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: make install fails if no previous Python installation
Type: behavior Stage: test needed
Components: Installation Versions: Python 3.2, Python 3.3, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, Eric.Rannaud, Myroslav.Opyr, ajaksu2, amaury.forgeotdarc, eric.araujo, gael, lkraav, mbenkmann, sbassi, simon.percivall, skiolding, terry.reedy, whit537
Priority: high Keywords: patch

Created on 2007-02-26 18:22 by mbenkmann, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
Python-2.5.6c1-issue1669349-workaround.patch Eric.Rannaud, 2011-04-28 02:59 Post ./configure patch (workaround)
Makefile-2.4.6-unicodedata-zipfile-libinstall-altinstall-sequence.patch Myroslav.Opyr, 2013-03-12 12:38 The [Python 2.4.6] Makefile patch to change sequence of installation steps to avoid missing unicodedata on libinstall step and obscure (zipfile/libinstall) error.
Messages (17)
msg31366 - (view) Author: Matthias S. Benkmann (mbenkmann) Date: 2007-02-26 18:22
When installing Python 2.5 on a completely Python-less system 'make install' failed. The error that caused the failure was

Compiling /usr/lib/python2.5/test/ ...
Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",)
Compiling /usr/lib/python2.5/ ...
make: *** [libinstall] Error 1

'find -name' showed me that the library did not exist in the build tree. However, after a 'make -i install' to force make to continue despite the error, was there. So apparently the library is not built until a later stage of make install. And indeed, subsequent 'make install' calls without -i were successful. 

It is important to note that if you have a previous Python installation (at least of the same version), 'make install' will go through, because it'll load the library from there. So if you want to reproduce the issue you will have to install from a freshly unpacked tarball on a system with no Python installation.

msg31367 - (view) Author: Simon Percivall (simon.percivall) Date: 2007-03-21 11:26
It shouldn't be a problem changing the Makefile to do sharedinstall before libinstall in the altinstall target. I'm guessing that would solve the problem.
msg31368 - (view) Author: Sebastian Bassi (sbassi) Date: 2007-04-03 15:05
The same problem arises when installing Python using "make altinstall", even with another Python installed. 
msg31369 - (view) Author: Sebastian Bassi (sbassi) Date: 2007-04-03 15:50
Another workaround (by Jaroslaw Zabiello):

After executing
you have to edito
file and uncomment the following line:
#zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz
Then continue with normal make; make install.
msg31370 - (view) Author: Adrian Silva (skiolding) Date: 2007-04-19 09:02
The build failure is still present on svn trunk.

I'm using the first workaround posted (i.e. "changing the Makefile to do sharedinstall before
libinstall in the altinstall target") to build from trunk.
msg84659 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-03-30 21:41
Bumping priority so this has a better change of being confirmed/closed.
msg99812 - (view) Author: Gael (gael) Date: 2010-02-22 19:02
I have the same issue on Sun Solaris while compiling Python 2.4.5 on a Python-less system.

I was using GNU tools (tar, zlib, libgcc and bash).

I have noticed that the error appears while using --prefix=/something/ending/with/Python-2.4

But if I use --prefix=/something/ending/with/SomethingElse, like
--prefix=/something/ending/with/Python-24 or

Everything goes well and make install no more fails.

It looks like a fail regex or a hard coded path error.

Hope this can help.

Best regards,

msg99920 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-02-23 14:55
Interesting. What is the content of sys.path when you start ./python from the build tree?
msg99945 - (view) Author: Gael (gael) Date: 2010-02-23 19:24
Amaury Forgeot d'Arc a écrit :
> Amaury Forgeot d'Arc <> added the comment:
> Interesting. What is the content of sys.path when you start ./python from the build tree?

I will tell you tomorrow, I have no access to the computer at this hour.

> ----------
> nosy: +amaury.forgeotdarc
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
msg100099 - (view) Author: Gael (gael) Date: 2010-02-25 19:30
Here it is.

Python 2.4.5 (#1, Feb 24 2010, 08:26:11)
[GCC 3.4.6] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path

PS: Sorry for the message above, haven't seen I was responding to the bug system. Feel free to drop it.
msg116615 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-16 21:28
Can someone with install and/or build experience please confirm or deny that this is a problem with supported versions of Python.
msg121478 - (view) Author: (lkraav) Date: 2010-11-18 17:06
i think i am running into this trying to cross-compile for i686-gentoo-linux-uclibc and have been unable to figure out how to get altinstall to succeed:

build log available at

any thoughts?
msg121483 - (view) Author: (lkraav) Date: 2010-11-18 18:16
i have managed to get past unicodedata fails by manually enabling unicodedata ( got another error right after that, but that might be something further gentoo/xcompile specific, details in gentoo bug for those interested.
msg134637 - (view) Author: Eric Rannaud (Eric.Rannaud) Date: 2011-04-28 02:59
I get the same error when building Python-2.5.6c1 on Fedora 14 (with python2.7 installed).

./configure --prefix=$PREFIX && make install

Just to clarify the workaround used by lkraav on Gentoo, I attached a patch that manually enables unicodedata in Modules/Setup.dist
msg139196 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-06-26 18:57
I am closing this because none of the reports are for current versions (2.7,3.2)
msg143708 - (view) Author: Chad Whitacre (whit537) Date: 2011-09-07 21:01
I am seeing this behavior with 2.7.1.
msg184021 - (view) Author: Myroslav Opyr (Myroslav.Opyr) * Date: 2013-03-12 12:38
I've got the issue with Python 2.4.6 and solved the issue with changing sequence of altinstall steps (moved sharedinstall before libinstall). See attached Makefile-2.4.6-unicodedata-zipfile-libinstall-altinstall-sequence.patch.
Date User Action Args
2022-04-11 14:56:22adminsetgithub: 44622
2013-03-12 12:38:31Myroslav.Opyrsetfiles: + Makefile-2.4.6-unicodedata-zipfile-libinstall-altinstall-sequence.patch
nosy: + Myroslav.Opyr
messages: + msg184021

2011-09-07 21:01:33whit537setnosy: + whit537
messages: + msg143708
2011-06-26 18:57:00terry.reedysetstatus: open -> closed
versions: + Python 3.3, - Python 3.1
nosy: + terry.reedy

messages: + msg139196

resolution: out of date
2011-06-03 15:19:53eric.araujosetnosy: + eric.araujo
2011-06-01 06:15:47terry.reedysetversions: - Python 2.5
2011-04-28 02:59:24Eric.Rannaudsetfiles: + Python-2.5.6c1-issue1669349-workaround.patch
versions: + Python 2.5
nosy: + Eric.Rannaud

messages: + msg134637

keywords: + patch
2010-11-18 18:16:39lkraavsetmessages: + msg121483
2010-11-18 17:06:05lkraavsetnosy: + lkraav
messages: + msg121478
2010-09-16 21:28:39BreamoreBoysetnosy: + BreamoreBoy

messages: + msg116615
versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6, Python 3.0
2010-02-25 19:30:27gaelsetmessages: + msg100099
2010-02-23 19:24:51gaelsetmessages: + msg99945
2010-02-23 14:55:30amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg99920
2010-02-22 19:02:59gaelsetnosy: + gael
messages: + msg99812
2009-03-30 21:41:11ajaksu2setpriority: normal -> high

type: behavior
versions: + Python 2.6, Python 3.0, - Python 2.5
nosy: + ajaksu2

messages: + msg84659
stage: test needed
2007-02-26 18:22:01mbenkmanncreate