앞으로    목차    1    2    제3장    4    5    6    7    8    다음으로

3. 파이썬 구축하기와 알려진 버그들

3.1. 테스트 모둠이 있나요?

물론입니다. 여러분은 그것을 "make test"로 구축한뒤에 실행할 수 있습니다, 또는 그것을 수동으로 파이썬 프롬프트에서 이 명령어로 실행할 수 있습니다:

 import test.autotest
파이썬 1.4 혹은 이전이라면, 다음을 사용하세요

 import autotest
그 테스트 모둠은 파이썬의 모든 사양을 테스트하지는 않습니다, 그렇지만 파이썬이 실제로 작동하는지 확증하기 위하여 오랜 시간이 필요합니다.

주의: 만약 "make test"가 실패한다고 해서, 단순히 그 출력을 뉴스그룹에 편지하지 마세요 -- 이것으로는 그 프로그램을 디버그하기 위한 충분한 정보가 되지 않습니다. 대신에, 어떤 테스트가 실패하는지 알아 내세요, 그리고 그 테스트를 수동으로 상호대화 모드에서 실행하세요. 예를 들어, "make test"가 test_spam이 실패했다고 보고하면, 이것을 상호대화적으로 점검하세요:

 import test.test_spam
이것은 일반적으로 더욱 상세한 출력을 산출하므로 그 프로그램을 디버그하기위해 진단될 수 있습니다. 만약 여러분이 파이썬에서 혹은 라이브러리에서, 또는 그 테스트에서 버그를 발견하게 되면, 이것을 소스포지(SourceForge)에 있는 파이썬 버그 추적기에 보고하세요:

http://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470


3.2. 그 테스트 모둠을 실행할 때, 나는 부동소수점 연산에 관한 불평을 듣습니다, 그렇지만 부동소수점 연산을 다룰 때는 잘 못된 어떤 것도 발견할 수 없습니다.

그 테스트 모둠은 C의 부동 소수점 연산의 의미론에 관하여 가끔 보장되지 않은 가정을 하곤 합니다. 어떤 사람이 더 좋은 부동 소수점 테스트 모둠을 기증할 때까지는, 그 성가신 부동소수점 연산 테스트를 주석처리하고 비슷한 테스트를 수동으로 할 필요가 있습니다.


3.3. 설정 스크립트를 재실행하고 난 후의 링크 에러.

환경설정이 변경된 후에는 일반적으로 "make clean"을 실행할 필요가 있습니다.


3.4. 스크립트로 (그 스크립트의 이름 뒤에) 건네진 선택사항들에 관하여 파이썬 인터프리터가 불평합니다.

아마도 GNU의 getopt와, 예를 들어 -liberty를 통하여서 연결하고 있는 것 같습니다. 그러지 마세요. 불평의 이유는 GNU의 getopt가, System V의 getopt 그리고 다른 시스템의 getopt 구현과는 다르게, 선택사항이 없는 것을 선택사항 리스트의 마지막이라고 간주하지 않기 때문입니다. 스크립트를 위한 신속한 (그리고 호환성 있는) 해결법은 "--"를 인터프리터에다, 다음과 같이 추가하는 것입니다:

        #! /usr/local/bin/python --
상호대화적으로 이렇게 사용할 수도 있습니다:

        python -- script.py [options]
주목하실 것은 작동하는 getopt 구현이 파이썬 배포본에 (Python/getopt.c)로 제공되지만 자동적으로 사용되지는 않습니다.


3.5. SGI에 대한 구축을 하는 중에, glmodule.c를 생성하기 위하여 파이썬을 실행하였지만, 파이썬은 구축되지 않았거나 혹은 설치되지 않았습니다.

설정에서 glmodule.c를 언급하고 있는 라인을 주석처리 하시고 먼저 파이썬을 gl 없이 구축하세요; 그것을 설치하시거나 $PATH에 그것이 있는지 확인하세요, 그리고 설정 파일을 다시 편집하셔서 gl 모듈을 켜세요, 그리고 다시 만드세요. "make clean"을 할 필요는 없습니다; 그 모듈들이 있는 하부디렉토리에서 "make Makefile"을 실행할 필요가 있습니다 (그렇지 않으면 단순히 최상위 수준에서 "make"을 실행하세요).


3.6. 저는 VPATH를 사용합니다 그러나 어떤 목표들은 소스 디렉토리에 구축됩니다.

어떤 시스템에서는 (예로 Sun에서는), 만약 목표가 이미 소스 디렉토리에 존재하면, 구축디렉토리 대신에 거기에 생성됩니다. 이것은 보통 여러분이 이전에 VPATH 없이 구축한 적이 있기 때문입니다. 소스 디렉토리에서 "make clobber"를 실행해 보시기 바랍니다.


3.7. GNU의 readline 라이브러리와 링크 또는 구축곤란.

GNU의 readline 라이브러리를 사용하여 상호대화적인 사용자 인터페이스를 개선할 수 있습니다: 이것으로 여러분은 파이썬이 상호대화적으로 호출되면 명령어 기억기능과 라인 편집을 할 수 있습니다. 그 소스들은 (적어도 2.0에는) 파이썬과 함께 배포됩니다. Modules/Setup에 있는 다음 라인에서

#readline readline.c -lreadline -ltermcap

주석을 제거 하세요. 환경설정 선택사항인 --with-readline은, 적어도 파이썬 2.0에서는 더이상 지원되지 않습니다. readline 라이브러리를 사용하고 구축하는데 대한 약간의 힌트를 들자면: SGI IRIX 5에서는, 다음과 같이 rldefs.h에 추가 하셔도 좋습니다:

        #ifndef sigmask
        #define sigmask(sig) (1L << ((sig)-1))
        #endif
어떤 시스템에서는, 몇몇의 소스 파일의 최상단에 #include "rldefs.h"를 추가할 필요성이 있습니다, 그리고 VPATH 사양을 사용하신다면, foo의 여러 값들을 위해서 foo.o: foo.c 형태의 의존성을 Makefile 파일에 추가해야할 필요가 있을 것입니다. readline 라이브러리는 termcap 라이브러리의 사용을 요구합니다. 이와 관련된 알려진 문제 하나는 그것이 STDWIN과 SGI GL 라이브러리와의 충돌을 야기하는 항목을 포함한다는 것입니다. STDWIN의 충돌은 '#define werase w_erase'라는 라인을 stdwin.h 파일에 추가하면 해결될 수 있습니다 (STDWIN 배포본, 하부디렉토리 H에 있습니다). 파이썬 환경설정 스크립트에서 강제로 텀캡(termcap) 라이브러리의 정적 버전을 사용하도록 해킹함으로써 GL 충돌은 해결되었습니다. readline라이브러리와 관려된 특정한 문제들에 관심이 있으시면 뉴스그룹 gnu.bash.bug news:gnu.bash.bug 을 점검해 보세요 (저는 이 그룹을 읽지는 않았지만 제가 듣기로 그곳이 readline 버그가 보고되어 있는 곳이라고 알고 있습니다).


3.8. 오래된 리눅스 1.x 버전에서 소켓 I/O에 문제.

파이썬을 구축하셨으면, 그것을 사용해서 Lib/linux1 디렉토리에 있는 regen.py 스크립트를 실행하세요. 배포된 그대로의 파일들은 분명히 어떤 리눅스 버전에서는 시스템 헤더와 일치하지 않습니다.


3.9. Ultrix에서 프로토타입의 문제.

Ultrix의 cc가 망가진것이라고 판단됩니다 -- gcc를 사용하시거나, config.h를 #undef HAVE_PROTOTYPES 편집하세요.


3.10.플랫폼 X에서 파이썬을 구축하는데 따르는 다른 문제들.

자세한 사항을 소스포지의 버그 추적기에 제출하세요:

  http://sourceforge.net/tracker/?group_id=5470&atid=105470
그러면 우리가 조사해 보겠습니다. 되도록이면 자세하게 보내 주시길 바랍니다. 특히, 여러분이 사용하시는 컴퓨터의 종류 운영체제(그리고 버전)의 종류를 말씀해 주시지 않으면 무엇이 문제인지 우리가 알아내기가 힘듭니다. 컴파일 출력 로그를 가지고 계시면, 파일 올리기를 사용해 주시길 바랍니다 -- 모든 것을 메시지 박스에 붙여 넣지 마세요.

많은 경우에, 우리는 같은 하드웨어 혹은 운영체제에 접근할 수는 없습니다, 그러므로 제발, 여러분이 소스포지 계정을 가지고 계시면, 여러분의 보고서를 다 채워 넣으시기 전에 로그인을 하세요, 혹은 계정이 없으시다면, 전자 우편 주소를 포함하셔서 여러분에게 추가 질문을 할수 있도록 해 주세요. 소스포지에 처음 로그인 하시게 되면 여러분의 보고서에 대하여 연구한 갱신사항이 여러분에게 보내질 것입니다.


3.11. 리눅스에서 동적 적재를 설정하는 법.

이것은 이제 자동적이 되었습니다. 여러분의 리눅스 버전이 ELF 형식을 사용한다면 말이지요 (최근의 모든 리눅스는 그것을 사용합니다).


3.12. 리눅스 2.0에서 공유 모듈을 얻을 수 없습니다 (Slackware96)?

이것은 Slackware96 배포본에 있는 버그입니다. 해결책은 쉽습니다: /lib/libdl.so에서 /lib/libdl.so.1으로 연결되어 있는 것을 확인하셔서 다음의 연결들이 설정되어 있는지 살펴보세요: /lib/libdl.so -> /lib/libdl.so.1 /lib/libdl.so.1 -> /lib/libdl.so.1.7.14

이렇게 수정한 후에 파이썬을 재구축하려고 시도하기 전에, config.cache 파일을 rm으로 삭제하고 나서, 아마도 환경설정 스크립트를 재실행할 필요가 있을 것입니다.


3.13. 리눅스에서 공유 모듈을 만들 때의 문제.

이것은 파이썬을 정적 연결로 구축하고 그리고는 설정 파일에서
  *shared*  
를 가능하도록 할 때 일어납니다. 공유 라이브러리 코드는 반드시 "-fpic"으로 컴파일하여야 합니다. 만약 그 모듈을 위한 a.o 파일이 이미 정적 연결로 컴파일되어 존재한다면, 그것을 제거하거나 혹은 그 모듈의 디렉토리에서 "make clean"을 하세요.


3.14. 리눅스에서 쓰레드를 사용하는 법.

[그레그 스타인(Greg Stein)] 아주 최근의, 혹은 그 이상의 libc를 가지고 계시거나, LinuxThreads-0.5 배포본을 구하실 필요가 있습니다. 주목할 것은 LinuxThreads를 정상적으로 설치하셨다면, 그 디렉토리를 -with-thread 설정 스위치에 전혀 지정하실 필요가 없습니다. 설정 스크립트는 아무 문제없이 찾을 수 있을 것입니다. 모든 것이 적절하게 구축된것을 확인하셨으면, "make clean"을 하시고, config.cache를 제거하시고, 그 스위치로 다시 재설정하시고, 그리고 구축하십시오.

[앤디 더스트만(Andy Dustman)] glibc 시스템 (즉. RedHat 5.0+)에 대해서 말하자면, LinuxThreads 는 폐기되고 POSIX 쓰레드 (-lpthread)가 대신하게 되었습니다. 이전의 RedHat으로부터 업그레이드 하셨다면, LinuxThreads를 "rpm -e linuxthreads linuxthreads-devel"으로 제거하세요. 그리고 --with-thread를 위와 같이 재설정하십시오.


3.15. C++ 코드를 담고 있는 공유 라이브러리와 링크할 때 에러 발생.

핵심 파이썬 이진파일을 C++과 링크하세요. Modules/Makefile에 있는 LINKCC의 정의를 여러분의 C++ 컴파일러가 되도록 변경하세요. config.c를 약간 변경하셔서 C++과 호환되도록 편집할 필요가 있을 것입니다.


3.16. 삭제됨 **


3.17. 삭제됨. *


3.18. _tkinter 모듈에 대한 컴파일 혹은 링크 에러

거의 확실히, Tcl/Tk 머리파일 (tcl.h and tk.h)과 사용하고 계시는 Tcl/Tk 라이브러리 사이에 버전 불일치가 있습니다. (예. 설정파일에서 _tkinter에 대한 "-ltk8.0"과"-ltcl8.0" 인수들). 여러 버전의 Tcl/Tk 라이브러리를 설치하는 것도 가능합니다, 그러나 오직 하나의 버전으로 된 tcl.h와 tk.h 머리 파일만이 있어야 합니다. 만약 라이브러리가 머리부에 일치하지 않으면, 그 모듈을 연결할 때나, 그것을 수입할 때, 문제에 봉착하게 될 것입니다. 다행스럽게도, 버전 번호는 각 파일에 명확하게 명시되어 있어서, 쉽게 발견할 수 있습니다. 보통은 최신의 버전을 재 설치하시거나 사용하시면 이 문제는 해결됩니다.

(또한 주의하실 것은 패치되지 않은 파이썬 1.5.1을 Tcl/Tk 7.6/4.2 이전에 대하여 컴파일 하시면, Tcl_Finalize에 관한 에러를 맞이합니다. 다음의 1.5.1 패치 페이지 http://www.python.org/1.5/patches-1.5.1/를 참조하세요.)


3.19. Tcl/Tk를 위해 파이썬을 설정하고 구축하였지만 "import Tkinter"가 실패합니다.

분명히, 당신은 다음의 라인을 설정하는 것을 잊어먹고 계실겁니다: "TKPATH=:$(DESTLIB)/tkinter".


3.20. Tk가 DEC Alpha에서 정확하게 동작하지 않습니다.

아마도 Tcl, Tk 또는 파이썬을 gcc로 컴파일 하셨을 것입니다. 그러지 마세요. 이 플랫폼에 대해서는, 64-비트 정수를 가지고 있으므로, gcc가 망가진 코드를 생성한다고 알려져 있습니다. 표준 cc (그 운영체제에 함께 딸려옵니다)가 작동합니다. 그래도 gcc를 사용하시고 싶으시면, 적어도 뉴스그룹이나 저자에게 문제를 보고하시기 전에 cc로 재컴파일해 보시기 바랍니다; 만약 이것으로 그 문제가 해결되면, 버그를 대신에 gcc 개발자들에게 보고하세요. (우리가 알고 있는한, 다른 플랫폼에서는 gcc에 문제가 없다고 알고 있습니다 -- 그 불안정성은 DEC Alpha에만 한정된다고 판단됩니다.) 질문 3.6. 역시 참조바랍니다.

Tcl/Tk를 위한 64-bit 버그수정 버전이 있습니다; 다음을 참조하세요

	http://grail.cnri.reston.va.us/grail/info/patches/tk64bit.txt


3.21. 약간의 일반적인 시스템 호출을 포식스 모듈에서 발견할 수 없습니다.

거의 확실히, 설정스크립트에 의해서 실행되는 모든 테스트용 컴파일물들은 어떤 이유에서 인가 실패하고 있습니다. config.log를 보셔서 그 이유가 됨직한 것을 찾아 보세요. 일반적인 이유는 디렉토리를 --with-readline 선택사항에 지정하는 것인데 그 디렉토리는 libreadline.a 파일을 포함하고 있지 않습니다.


3.22. 윈도우에서, ImportError: No module named string.

분명히, PYTHONPATH 환경 변수가 다음과 같은 어떤 것으로 설정되어 있을 것입니다:

set PYTHONPATH=c:\python;c:\python\lib;c:\python\scripts

(파이썬이 c:\python에 설치되어 있다고 가정합니다)


3.23. gl 모듈을 사용할 때 SGI에 관하여 핵심코드 덤프.

termcap과 curses라이브러리에서의 입구점과 GL 라이브러리의 입구점 사이에 충돌이 있습니다. GNU readline 라이브러리에 필요하다면, termcap 라이브러리에 대하여는 해킹 수준의 해결책이 나와 있습니다, 그러나 curses를 사용할 때는 작동하지 않습니다. 결론을 말하자면, curses와 gl 모듈 둘 다를 포함하는 파이썬 이진 파일을 구축할 수는 없습니다.


3.24. 윈도우에서 DLL을 구축하는 동안에 "Initializer not a constant" 에러 발생

확장 모듈에 있는 정적 형태의 객체 초기화자는 "initializer not a constant"과 같은 에러 메시지를 가지고 컴파일 실패를 야기할 수 있습니다. 프레드릭 룬트(Fredrik Lundh)씨가 <Fredrik.Lundh@image.combitech.se> 설명합니다:

이것은 MSVC아래에서 DLL을 구축할 때 일어납니다. 이것에 접근하는 방법은 두가지가 있습니다: 그 모듈을 C++로 컴파일 하거나, 혹은 코드를 다음과 같이 변경하는 것입니다:

  statichere PyTypeObject bstreamtype = {
      PyObject_HEAD_INIT(NULL) /* must be set by init function */
      0,
      "bstream",
      sizeof(bstreamobject),
  ...
  void
  initbstream()
  {
      /* Patch object type */
      bstreamtype.ob_type = &PyType_Type;
      Py_InitModule("bstream", functions);
      ...
  }


3.25. 파이프 혹은 파일로 방향전환된 출력이 리눅스에서 사라집니다.

어떤 사람들은 스크립트를 상호대화적으로 사용할 때, 실행은 잘 되지만, 파이프나 혹은 파일로 방향 전환하게 되면, 아무런 출력도 나오지 않는다고 보고합니다.

    % python script.py
    ...some output...
    % python script.py >file
    % cat file
    % # no output
    % python script.py | cat
    % # no output
    %
이무도 이것의 원인이 무엇인지는 모릅니다, 그러나 리눅스의 버그임은 확실합니다. 대부분의 리눅스 사용자들은 이것 때문에 영향을 받지는 않습니다.

적어도 한개의 보고가 있다면 (더 새로운 버전으로) 리눅스와 파이썬을 재 설치하고 이 문제를 제거했다고 합니다; 그래서 이것이 아마도 해결책이 아닐까 합니다.


3.26. libc 5.4를 가진 리눅스에서 모든 곳에서 구문 에러

``파이썬 1.4를 리눅스 시스템에 설치하였습니다. 수입 서술문을 실행하려고 할 때 다음과 같은 에러 메시지를 맞이하였습니다:''

   File "<stdin>", line 1
       import sys
          ^
   Syntax Error: "invalid syntax"
그것을 스스로 컴파일 하였습니까? 이것은 보통 libc 5.4.x와 이전의 libc 사이의 비호환성 때문에 야기됩니다. 특히나, libc 5.4와 컴파일된 프로그램들은 libc 5.2가 설치된 시스템에서는 ctype.h 파일이 깨져 있기 때문에 부정확한 결과를 산출합니다. 이 경우에는, 파이썬이 어떤 문자가 기호인지 등등을 인식할 수 없습니다. 해결책은, 설치된 이진파일을 구축할 때에 사용한 C 라이브러리를 설치하던가, 또는 파이썬을 스스로 컴파일 하는 것입니다. 이렇게 할 때에, 컴파일러가 사용한 C 라이브러리 머리부 파일과 설치된 C 라이브러리가 일치하는지 확인하세요.

[Martin v. Loewis의 답변으로부터 인용]

추가 [Andreas Jung으로부터 인용]: libc 5.4.x으로 업그레이드하였고, 그래도 문제가 지속되면, 구형 버전의 libc를 위한 라이브러리 경로를 점검하세요. 거기에 있는 libs와 header 파일로 libc를 깨끗하게 갱신하세요. 그리고 나서 모두 다 재컴파일하세요.


3.27. 리눅스에서 Tkinter를 사용할 때 XIO에서 충돌

파이썬이 리눅스 아래에서 쓰레드로 구축될 때, Tkinter를 사용하는 것은 다음과 같은 충돌을 야기할 수 있습니다:

  >>> from Tkinter import *
  >>> root = Tk()
  XIO:  fatal IO error 0 (Unknown error) on X server ":0.0"
        after 45 requests (40 known processed) with 1 events remaining.
이유는 기본 Xlib가 쓰레드를 지원하도록 구축되지 않았기 때문입니다. Xlib를 쓰레드가 가능하도록 재구축하면 문제가 사라집니다. 대안적으로, 파이썬을 쓰레드 없이 재구축할 수 있습니다 (먼저 "make clean" 하세요!).

(Disclaimer: this is from memory.)


3.28. Tkinter가 작동하는지 어떻게 테스트 할 수 있나요?

다음과 같이 해보세요:

  python
  >>> import _tkinter
  >>> import Tkinter
  >>> Tkinter._test()
이것은 하나는 "Click me" 그리고 "Quit"라는, 두 개의 버튼을 가진 윈도우 하나를 팝업시킵니다.

첫 번째 서술문(import _tkinter)이 실패하면, 여러분의 파이썬 설치가 아마도 Tcl/Tk를 지원하도록 설정되지 않은 것입니다. 유닉스에서, Tcl/Tk를 설치하였다면, _tkinter 모듈과 TKPATH 환경 변수를 사용가능하도록 Modules/Setup을 편집한 후에 파이썬을 재구축하여야 합니다.

Tcl/Tk 버전 번호 불일치 혹은 TCL_LIBRARY없음 또는 TK_LIBRARY 환경 변수들에 관한 불평들을 만나게 될 수도 있습니다. 이러한 것들은 Tcl/Tk 설치 문제와 관련이 있습니다.

흔한 문제는 설치된 Tcl/Tk 라이브러리의 버전과 일치하지 않는 tcl.h와 tk.h 버전을 설치하는 것입니다; 이것은 보통 연결자 에러를 야기하거나 혹은 (동적 적재를 사용할 때) 공유 라이브러리를 적재하는 동안에 '심볼 없음' 불평으로 결론지어집니다.


3.29. 파이썬 인터프리터의 상호대화 모드에서 함수/변수 이름 완성을 수행하도록 할 방법이 있나요?

(귀도 반 로섬의 글에서 인용)

유닉스에서, readline 모듈을 가능하도록 하셨다면 (즉. 이맥스-스타일의 명령어 라인 편집과 bash-스타일의 명령기억이 작동한다면), 문서화되지 않은 표준 라이브러리 모듈 "rlcompleter"를 수입함으로써 이것을 추가할 수 있습니다. 간단한 식별자를 채워 넣으면, __main__에 있는 키워드, 내장 그리고 전역변수들을 채워줍니다; NAME.NAME...을 완성할 때, 그 표현식을 마지막 점까지 평가하여(!) 그 속성들을 채워넣습니다.

이런식으로, "import string"을, "string."이라고 타자하고, 완성 키를 두번 누르면, 그 문자열 모듈이 정의한 이름들의 목록을 볼 수 있습니다.

팁: 탭 키를 완성 키로 사용하려면, 다음과 같이 호출하세요

    readline.parse_and_bind("tab: complete")
이것을 ~/.pythonrc 파일에 배정할 수 있으며, PYTHONSTARTUP 환경 변수를 ~/.pythonrc에 설정할 수 있습니다. 이렇게 하면 파이썬을 상호대화적으로 실행할 때마다 완성기능을 사용할 수 있게 될 것입니다.

주의 (더 자세히 알려면 rlcompleter.py를 위한 문서화 문자열(docstring)을 참조하세요):

* 만약 __getattr__ 낚아채기를 가지고 있는 객체가 발견된다면 NAME.NAME... 형태를 평가하는 것은 임의적인 어플리케이션을 실행되어야 할 코드로 정의하여 버릴 수도 있습니다. 왜냐하면 이 사양을 가능하게 하는 것은 어플리케이션 (혹은 사용자)의 책임이기 때문인데, 이것은 허용할 만한 위험이라고 생각합니다. 더욱 복잡한 표현식 (예를들어, 함수 호출이나 연산을 지표화하는 것들)은 평가되지 않습니다.

* GNU readline는 또한 내장 함수 input()과 raw_input()에 의해서 사용됩니다, 그리하여 이것들은 또한 그 완성사용 때문에 혜택을 받기도/고통을 받기도 합니다. 분명히 상호대화적인 어플리케이션은 자신만의 완성 기능을 지정하고 모든 입력에 대하여 raw_input()을 사용함으로써 혜택을 받을 수 있습니다.

* 표준입력이 tty 장치가 아니라면, GNU readline은 절대로 사용되지 않습니다, 그리고 이 모듈은 (그리고 readline 모듈)은 조용하게 작동하지 않습니다.


3.30. 왜 파이썬 인터프리터는 공유 라이브러리처럼 구축되지 않았나요? *

(이것은 유닉스의 문제입니다; 맥과 윈도우에서, 그것은 공유 라이브러리입니다.)

이것을 다른 모든 플랫폼에서 작동하도록 하는 것은 정말 악몽입니다. 공유 라이브러리의 이식성은 고통입니다. 네 물론, GNU의 libtool에 관하여 알고 있습니다 -- 그러나 그것은 파일 이름의 관례 등등을 사용하기를 요구하고, 지금 사용하고 있는 모든 makefile과 설정도구들을 완전하게 그리고 철저하게 재작성 하도록 요구할 것입니다.

실제적으로, 파이썬을 내장한 어플리케이션은 없습니다 -- 더욱 더 일반적인 것은 파이썬 확장을 보유하는 것이고, 이미 공유 라이브러리입니다. 또한, 엄격한 내장자들은 때때로 그들이 사용하고 있는 파이썬 버전과 설정에 관하여 전적인 통제를 원합니다. 그래서 어쨋든 표준 공유 라이브러리를 사용하기를 원하지 않을 것입니다. 그래서 많은 어플이 파이썬을 내장할 때 공간을 절약한다는 동기가 이론적으로는 좋지만, 실제적으로 그 만큼 많이 절약해 줄지는 의문입니다. (그러므로 저는 공유 라이브러리를 만드는 것에 중요성을 두지 않습니다.)

리눅스 시스템을 위해서는, libpython1.5.so를 만드는 가장 간단한 방법은 다음과 같습니다 (출처는 Minotaur 프로젝트 웹페이지 http://www.equi4.com/minotaur/minotaur.html 입니다.):

  make distclean
  ./configure
  make OPT="-fpic -O2"
  mkdir .extract
  (cd .extract; ar xv ../libpython1.5.a)
  gcc -shared -o libpython1.5.so .extract/*.o
  rm -rf .extract


3.31. GCC로 Solaris 2.6 (SunOS 5.6)에서 구축할 수 없습니다

Solaris 2.5또는 2.5.1에서 Solaris 2.6으로 업그레이드 하셨는데, GCC 설치를 업그레이드 하지 않으셨다면, 컴파일은 예를들어, 다음과 같이 실패할 것입니다:

 In file included from /usr/include/sys/stream.h:26,
                  from /usr/include/netinet/in.h:38,
                  from /usr/include/netdb.h:96,
                  from ./socketmodule.c:121:
 /usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified"
해결책: GCC를 Solaris 2.6용으로 구축하세요. 단순히 fixincludes를 재실행 할 수도 있겠지만, 사람들은 그렇게 하는 것을 성공한 것으로 착각합니다.


3.32. "make clean"을 실행하면 잇달으는 구축을 실패하게 하는 문제있는 파일들이 남는 것 같습니다.

대신에 "make clobber"를 사용하세요.

기쁜마음으로 구축하고 설정한 후에 "make clean"을 사용하여 source/build 디렉토리의 크기를 줄이세요. 이미 파이썬을 구축하기를 시도해 보았고 다시 시작하고자 한다면, "make clobber"를 사용하여야만 합니다. 그것은 "make clean"을 하여주고 또한 이전의 구축으로부터 부분적으로 구축된 파이썬 라이브러리와 같은 파일들을 제거합니다.


3.33. 버그 보고와 패치를 제출하기

버그 보고 혹은 패치를 제출하기 위해서는, 소스 포지의 파이썬 프로젝트에서 제공하는 적절한 서비스를 이용하시길 바랍니다.

버그: http://sourceforge.net/tracker/?group_id=5470&atid=105470

패치: http://sourceforge.net/tracker/?group_id=5470&atid=305470

소스포지에 계정을 가지고 계시다면, 버그 보고를 제출하시기 전에 먼저 로그인 하시길 바랍니다; 이렇게 하시면 뒤-따르는 문제들이 발생하였을 때 우리가 여러분의 보고에 관하여 더 쉽게 여러분에게 접근할 수 있을 것입니다. 또한 여러분의 버그에 관한 작업과 동시에 소스포지가 갱신사항을 여러분에게 보내줄 수 있을 것입니다. 소스포지에 계정이 없으시다면, 여러분의 이름과 전자우편 주소를 보고서의 한 부분에 남겨주시길 부탁드립니다.


3.34. 파이썬 1.5.2, 솔라리스 7, 그리고 gcc 2.95.2아래에서 공유 라이브러리를 적재할 수 없습니다

공유 라이브러리를 적재하려 할 때, 다음과 같은 에러를 볼 겁니다: ImportError: ld.so.1: python: fatal: relocation error: file/usr/local/lib/python1.5/site-packages/Perp/util/du_SweepUtilc.so:
 symbol PyExc_RuntimeError: referenced symbol not found

파이썬 1.5.2, 솔라리스 7, 그리고 gcc 2.95.2아래에서 환경설정 스크립트에 문제가 있습니다. 환경설정은 make 변수에 LINKFORSHARED=-Xlinker-export-dynamic으로 설정되어야 하는데.

Modules/Makefile에서,

수동으로 이 라인을 Modules/Makefile에 삽입하세요. 이것으로 파이썬이 공유 라이브러리 확장을 적재하도록 구축할 수 있습니다 (xxx.so).


3.35. 회귀 테스트에서, test___all__이 성능최적화 모듈에서 실패합니다. 무엇이 문제인가요?

그 성능최적화 모듈을 사용하고, 아래의 성능최적화기 문서에 설명된대로 그 모듈의 복사본을 적절하게 측정하셨다면:

current/lib/profile-calibration.html

그러면 그 회귀 테스트 "test___all__"은 파이썬의 소스 디렉토리에서 "make test"를 사용하지 않고 수동으로 그 회귀 테스트를 실행하였음에도 불구하고 실패할 가능성이 있습니다. 이러한 일은 측정될 성능최적화 모듈을 담고 있는 디렉토리를 포함하도록 PYTHONPATH 환경변수를 설정하게 되면 일어납니다. 아마도 그 성능최적화기를 구형 버전의 프로파일 모듈을 사용하여 측정하셨을 텐데, 그 모듈에는 __all__ 값이 정의되어 있지 않으며, 파이썬 2.1. 버전부로 추가되었습니다.

그 문제는 해결될 수 있는데 그 구형 성능최적화 측정 모듈을 제거하고 최근의 버전을 사용하셔서 새로이 측정하는 것입니다. 일반적으로, 파이썬의 각 버전에 대하여 재-측정할 필요가 있읍니다, 왜냐하면 성능의 특징은 성능최적화에 영향을 주게되면 미묘하게 변경될 수 있기 때문입니다.


앞으로    목차    1    2    제3장    4    5    6    7    8    다음으로