2016년 3월 30일 수요일

파이썬의 라이브러리 NumPy + SciPy _____ 8

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

어차피 우아하게 소스 레벨 디버깅도 물 건너간 상태다.

닥치고 수정 - 실행 , 재수정 - 실행의 무한 반복.

그나마 감 잡히는 부분이 있어서 다행이다.


로드하려는 라이브러리의 경로를 절대 경로로 지정하기 위해서 변환까지 하고, 변환하기 전의 경로를 사용한 부분.

dynload_win.c
pathname이라는 변수 대신에 pathbuf를 쓰는게 맞다고 생각해서 위 처럼 소스를 수정했다.

그리고 다시 빌드하고, 다시 실행해 본 결과,


역시나 같은 결과.

그것도 아니면 대체 뭐가 문제란 말인가?


dynload_win.c
의심이 가는 변수들의 값을 모두 확인하고자, 에러 메시지의 내용을 원하는 변수 값으로 출력하도록 수정했다.

그리고 다시 빌드하고 실행해 본 결과,


위의 함수가 호출될 때, 로드하라고 지정한 라이브러리는 _ufuncs
여기에 경로가 모두 포함된 pathname과 pthbuf는 결과적으로 _ufuncs.pyd를 똑같이 지정하고 있었다.


하지만 내가 알아낸 바에 의하면 _ufuncs.pyd라는 파일 자체를 로드하지 못한 것이 아니라, _ufuncs.pyd에서 필요로 하는 또 다른 DLL인 libifcoremd.dll을 찾지 못했기 때문에 발생한 것이었다.

그리고, 내 짐작엔 소스에서 로드하려고 LoadLibraryEx를 호출하는 이 부분이 바로 libifcoremd.dll를 대상으로 삼고 있을거라 생각했던 것이다.

하지만 그게 아니었다.

어쩌면 당연한거였는지도 모르겠다.

너무나 1차원적으로, 단순하게 생각했던 것이다.

저 메시지로 짐작하건데, _ufuncs.pyd도 라이브러리 이므로 LoadLibraryEx() 함수를 이용해 로딩하는 게 맞지만, OS의 입장에서 본다면, _ufuncs.pyd에서 또 다른 라이브러리의 함수를 사용할 수도 있는 것이고 그렇다면 그에 해당하는 DLL도 또한 로드해야만 제대로 된 작동을 할 수 있을 것이다.

그것이 libifcoremd.dll 이었던 것이다.

그렇다면 libifcoremd.dll은 어디에 명시되어 있을까?
아마도 _ufuncs.pyd에 명시되어 있을 것이다. 그래서 Ollydbg에서 해당 DLL을 찾을 수 없다고 메시지를 보여 줬던 것이리라.

그러면 통상의 DLL 탐색 순서에 따라 libifcoremd.dll을 탐색하고 찾아서 자동으로 로드해 주었으면 좋으련만, 윈도우즈에서는 그렇게까지 하지 않는 모양이다.

어쩌면 _ufuncs.pyd에는 libifcoremd.dll이 명시되어 있지 않을 수도 있고, 단지 libifcoremd.dll에 포함된 함수(프로시져)의 이름만을 명시하고 있을지도 모른다.

그렇다면 OS는 해당 함수를 가지고 있는 DLL이 무엇인지를 모두 뒤져봐야 할 것이고, 이건 너무나도 비효율적일테니, 특별히 자신이 가지 함수 이름을 미리 등록해 놓은 DLL에 대해서만 이런 서비스를 제공해 주는 것일지도 모른다.

(마침 _ufuncs.pyd에서 libifcoremd라는 문자열이 있는지 검색해 보았지만 찾지 못하고 있다. 오히려 Ollydbg가 메시지를 보여준게 신기할 따름.)

그렇다면 애초에 인텔의 이 라이브러리들을 아무 곳이나 PATH가 지정된 곳에 복사해 넣어서는 안되고, regsvr32라는 프로그램을 이용해서 등록해 주는 절차가 필요한 것이 아니었을까?

그렇다면 전에 받아 두었던 인텔의 배포용 라이브러리를 설치하는 것이 가장 좋은 해결책이 될지도 모르겠다.


그래서 당장 실행.
Intel C++ Redistributables for IA32

Intel Fortran Redistributables for IA32

설치 후에 추가된 PATH. 저기에 DLL들이 위치하고 있다.

설치 후에 다시 실행

그러나 이 모든 것을 다시 설치하고도 문제는 여전.
내가 빌드한 파이썬의 바이너리와 DLL을 모두 지우고, 원래 배포버전으로 돌려놓고 시험해도 마찬가지였다.

그럼 정말 이것도 문제가 아니었단 말인가?

틀림없이 libifcoremd.dll이 설치된 것을 확인했는데도?

그래서 다시 Ollydbg에서 _ufuncs.pyd를 불러 보았다.



헉...이번엔 메시지가 달랐다.

이번엔 libifcoremd.dll이 아니라, libmmd.dll이 문제였고, 그것도 해당 DLL 없다는 것이 아니라 특정 함수의 진입점이 없다는 것.

진전은 있지만 굉장히 불길한 예감.

============================================================================
애초에 이문제는 파이썬의 문제가 아니었다.

생각해 보면 NumPy나 SciPy의 문제도 아니었다.

NumPy나 SciPy를 MS-Windows용으로 빌드를 하는 과정에 어떤 툴을 이용했느냐에 따라 필요로하는 라이브러리나 DLL이 달라질 수 있기 때문이다.

친절한 크리스토프 골케씨가 NumPy와 SciPy를 빌드해서 배포해 주셨지만, 거기에 필요한 Intel의 라이브러리에 대한 충고는 깜빡했다고 밖에 볼 수 없다.
=============================================================================

마지막으로 OllyDbg에서 보여준 메시지에 따라 libmmd.dll을 확인해 보았다.

인텔의 배포 라이브러리 중 C++용과 Fortran용 양쪽 모두에 있는 라이브러리이며, 양쪽 라이브러리 모두 libm_sse2_exp2라는 함수의 이름은 존재하고 있었다.

문제는 정말 함수의 이름만 존재하고 진입점이 없다면....이번엔 인텔의 문제?

2016년 3월 29일 화요일

파이썬의 라이브러리 NumPy + SciPy _____ 7

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

앞서의 포스팅에서 파이썬이 모두 빌드되었다.
(처음엔 뭐가 부족하거나 문제가 있는게 아닌가 싶었는데 확인해 보니 모두 빌드 되어 있었음. 단지 빌드시에 나온 여러개의 워닝 메시지와 스킵한 프로젝트가 뭔지는 아직 미확인.)

빌드의 결과물은 PC/VS9.0 폴더에 있으며, 릴리즈 버전인 python.exe와 python27.dll, 디버그 버전인 python_d.exe와 python27_d.dll이다. (각 써드 파티의 라이브러리는 각 해당 폴더에 있음)

빌드된 python.

배포되는 Python 실행. 빌드버전과 CRC로 보이는 숫자가 있고 다음에 빌드 시각 2015년 12월 5일 20시 32분.

새로 빌드된 Python 실행. 버전 대신 default, 빌드 시각은 2016년 3월 28일 23시 18분.

Python 소스의 트리 구조

Python의 트리 구조

파이썬 소스의 폴더는 바이너리 배포 버전의 폴더와 약간은 다른데, 여기에서 고민이 생긴다.
완벽한 파이썬의 실행 환경이 갖추어져 있지 않으므로 바로 여기에서 디버깅을 하기엔 제약이 따른다는 것이다.

그러면 어떻게 디버깅을 해야 하는가?

1) 빌드된 디버그 버전의 바이너리를 원래의 환경에 복사해 넣고 디버깅을 한다?
소스와 바이너리의 위치가 다를 경우엔 어떻게 해야 하지?
gdb라면 간단하게 소스 위치만 지정하면 될텐데, Visual Studio의 IDE 환경에서도 이게 가능할까?

2) 소스 디렉토리에 필요한 나머지 파일들을 복사해 놓고 디버깅?
파이썬이 비록 인스톨러로 설치가 되긴 하지만, PATH에 경로를 지정하는 것 외에는 별다른 작업이 필요하지 않은 것 같던데? 아닌가?
그리고 Windows/system32 폴더에 python27.dll이 복사되어 있는 것도 보았다.



먼저 2번의 방법을 좀 더 생각해 보다가, 이런 의문이 떠 올랐다.
- 맨 처음의 NumPy와 SciPy를 설치할 때도 특별히 파이썬의 위치를 지정하지 않았지만 알아서 설치가 되었다. 이건 어떻게 가능했을까? (PATH를 보고? 설치 프로그램인 pip의 위치를 기준으로?)
: 이걸 새로 빌드된 환경에서 시험해 보려고 했는데, 아무리 찾아봐도 pip가 보이질 않는다.
 그냥 복사를 해서라도 해 볼까 하다가 걍 포기.

- 파이썬 인터프리터에서 import를 하면 해당 라이브러리를 잘 찾아낸다. 어떻게 가능한걸까?
: 구글에서 "python import dir order"로 검색을 하자 파이썬의 문서에서 "module-search-path" 부분을 찾아서 보여준다.
https://docs.python.org/2/tutorial/modules.html#the-module-search-path

위 링크에서 언급하는 sys.path를 직접 확인해 보았다.

Python의 sys.path

새로 빌드된 Python의 sys.path
환경변수인 PATH에 지정된 경로와는 상관없이, 현재 실행된 위치를 기반으로 내부의 탐색 경로가 바뀌는 것을 알 수 있다.


다시 위의 디버깅에서 1번의 방법에 대해 알아보니, 빌드시에 생성된 pdb에 소스의 위치 정보가 있으므로 바이너와 소스의 위치가 달라도 소스 레벨의 디버깅이 가능하다고 한다......정말일까?

그래서 빌드된 exe, dll, pdb 파일들을 모두 원래의 파이썬이 설치되어 있던 폴더에 복사했다. (원래의 exe와 dll은 다른 폴더에 피신 시켜 둠.)

새로 빌드한 파일들을 파이썬 설치 폴더에 복사

그런데.... 안된다.
Visual Studio에서 읽어 들여 보았으나, 디스어셈블 코드만 보여 줄 뿐, 소스를 찾지 못한다.
심지어 소스 폴더를 지정하는 옵션도 없다.


그래서....Visual Studio에서 프로젝트의 속성을 수정했다.
Python 프로젝트의 속성에서 Debugging의 Command 항목 수정

저기에 직접 디버깅할 실행 파일 이름을 지정해주면 된다.
Debugging 위의 General에서 Output Dir을 바꿔주는 것도 방법이긴 한데, 수정 - 빌드 - 디버깅 작업이 그리 많지 않을거라 생각하기에 최소한만 건드리는 방법을 택한 것이다.

그리고 Visual Studio에서 Start Debugging(F5)을 하면 다음과 같이 나온다.
여기에서 sys.path로 작업중인 디렉토리를 확인할 수 있다.
Start Debugging후에 sys.path로 작업중인 위치 확인.

그리고 그토록 알고자 했던 그 문제점이 재현되는지 확인하기 위해 "from scipy import special, optimize"를 입력하자...

기존의 문제점이 재현되는지 확인....어?
출력되는 메시지가 다르다. 에러는 에러인데....뭔가 이상하다.

아까 디버그와 릴리즈 버전의 바이너리를 모두 복사해 놓은 상태이기에, Visual Studio를 거치지 않고 바로 실행해서 다시 확인해 보았다.


먼저 디버그 버전의 경우..

디버그 버전
역시나 맨 처음과는 다른, Visual Studio를 거쳤을 때와 같은 에러 메시지.

그럼 릴리즈 버전의 경우는...
릴리즈 버전
애초에 보았던 것과 동일한 에러 메시지.

이런 x같은 경우를 보았나.

디버그 버전과 릴리즈 버전의 동작이 서로 다르단 말인가? 왓더뻐~어~억 쒜트 쒜~에~트

메시지를 차근 차근 확인해 본 결과, 릴리즈 버전은 numpy를 먼저 다 import하고 난 후에 scipy의 special을 import하는 중에 에러가 발생했고, 디버그 버전은 numpy를 import하는 과정에서부터 에러가 발생한 것으로 보인다.


침착하고.....
이 문제점이 내가 빌드하는 과정에서 발생한 것인지, 파이썬 자체의 소스 혹은 빌드 구성에 문제가 있는 것인지 알려면 빌드 로그를 모두 꼼꼼하게 확인해 보아야 한다.

그리고 애초에 문제가 되었던 부분에 대한 확인은, 당장은 릴리즈 버전으로 밖에 할 수 없는 상황이고, 이것도 메시지 출력을 이용하거나, 의심되는 부분을 바로 수정해서 확인해 보는 방법 뿐인 듯 하다.

단, 하나의 문제점 때문에 너무나 많은 과정을 거치고 있고, 자꾸 곁가지를 치면서 목표의식마저 흐릿해져 가고 있는 듯 하다.

디버그 버전과 릴리즈 버전의 문제를 확인하기 앞서서, 본래의 문제점을 먼저 해결하길 나 자신에게 바래 본다.

2016년 3월 28일 월요일

파이썬의 라이브러리 NumPy + SciPy _____ 6

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

앞선 포스팅에서 언급한 방법 중, 첫번째인 파이썬 직접 빌드 시도.

파이썬의 창시자가 구글에서 일하고 있으며, 구글의 지원아래 업무시간의 일정 부분을 파이썬 개발에 할애하고 있다고.....누군가한테 들은 적이 있었다.

각설하고...파이썬 소스를 보면서 잠깐 보았던 빌드에 관한 문서를 보고, 빌드 해보고, 실패하고, 인터넷 검색하고, 다시 좌절하고, 귀찮아지고...아마 며칠간은 귀차니즘에 손도 안댔던 거 같다.

그래도 이제 고지가 코 앞이라...는 희망으로 다시 힘을 내 보자.


시작하기 전에 필요한 것들 미리 정리해 보았다.
===========================================

1) 파이썬 소스 : 나는 파이썬 2.7.11을 받아서 빌드하기로 했음. 파이썬 3.x는 Windows Vista 이상에서만 빌드되고 실행되니 이 점은 주의 할 것.

2) 컴파일러 : MS Visual Studio 2008 이상. Express Edition도 된다고 함.

3) SVN client : svn.exe 이름으로 실행되는 command line 버전으로 어디서나 호출 되도록 PATH에 경로 지정 필요.
나는 Tortoise SVN을 사용했는데, 아래 링크된 정성태님의 글에도 나와 있지만 설치시에 반드시 command line client tool을 설치하도록 변경 해 주어야 한다.
그리고 Tortoise SVN은 1.7.15가 Windows XP에 설치되는 마지막 버전이다.(1.9.x & 1.8.x는 설치 안되는 거 확인했음.)
TortoiseSVN 1.9.3

TortoiseSVN 1.9.3 설치 안 됨.ㅠㅠ

TortoiseSVN 1.7.15는 설치 됨. command line client tools는 기본적으로 선택되지 않음.

command line client tools를 설치하도록 바꿈.

Explorere와 연동되는 툴이라서 어지간한 프로그램들을 종료해야 설치 됨.

그러고도 시스템 재시작 필요.


4) Perl interpreter : perl.exe 이름으로 실행되는 command line 버전으로 PATH 경로 지정 필요. 가급적 최신 버전으로 할 것. Strawberry Perl 5.12.2를 이용했으나 에러 발생.
빌드 중 에러 발생. 대놓고 Active Perl 쓰라고 함.
다시 정정. 아마도 Pre-Build event에 뭔가 잘못이 있는 듯 함.
ActivePerl 5.22.1을 설치했으나 다음과 같이 에러 발생.
ActivePerl 설치 후에 build -r로 rebuild한 결과. 마찬가지 에러 발생.
그러나 메시지를 보면, 에러 없이 ssl 라이브러리가 완성되었다.
단지 메시지의 문제였을 뿐?

5) NASM (v2.10 이상) : nasm.exe 이름으로 실행되는 command line 버전으로 PATH 경로 지정 필요.



시작하기 전에 읽어보면 도움이 될 것 들.
=====================================

1) 직접 파이썬을 빌드해 본 경험자의 정리 된 자료
  정성태님의 Python 소스 코드를 Visual C++로 빌드하는 방법 (단, 이건 Python 3.x를 64 bit로 빌드하는 경우)
  저 버전의 파이썬은 조금 예전 버전 경우라 그런지 참 이상한 문제들로 문제를 겪고 있는 부분들이 보인다. 이 버전에서 같은 문제가 발생하지 않을 수 있으니 반드시 증상을 확인한 후에 참조할 것.

2) 파이선 소스에 포함 된 readme.txt 첫번째 : Python-2.7.11/PCBuild/readme.txt

3) 파이선 소스에 포함 된 readme.txt 두번째 : Python-2.7.11/PC/VS9.0/readme.txt



미리 알아두면 좋은 것들.
=======================

1) 파이썬은 시간을 거치면서 많은 기능의 확장이 있었고, 이들 기능 중 일부는 이미 독립적인 라이센스를 가진 소스들을 이용하고 있다. 이런 소스들이 파이썬을 빌드하는데 필요하긴 하지만, 무작정 파이썬 소스에 묶어버리기엔 많은 문제점들이 존재한다. (카피라이트, 라이센스, 버전 관리 등)
따라서 이들 써드 파티의 소스는 별도로 가져와서 빌드를 해야 한다.

2) 위에서 읽어보라고 한 문서를 보면 알겠지만, 문서가 알아보기 쉽거나 간결하지 못하다. 중언 부언에, 내가 원하는 경우를 딱 꼬집어 찾기도 어렵고, 끝까지 읽어 보고 필요한지 아닌지 직접 판단해야 한다.

3) 예전에는 지원했지만, 이제는 지원을 하지 않는다고 없애지 않고 남겨진 폴더들이 있다.
VC6 (Visaul C++ 6.0), VS7.1 (Visual Studio 2003), VS8.0 (Visual Studio 2005)는 더 이상 지원하지 않는다고 하니 쓸데없는 희망을 가지지 말자.



시작
====
명령 프롬프트에서 PC/VS9.0으로 이동해서 build -e를 실행.

이 과정을 통해서 써드파티의 소스를 다운로드 받고 각각을 빌드한다.

문서에서는 pcbuild.sln을 열어서 빌드를 하라고 되어 있지만, 문서를 조금 더 읽어보면 그럴 수 없는 이유들이 나온다.

즉, 초기에 써드파티 소스를 가져오는 과정과 특별히 먼저 빌드되어야 하는 하위 프로젝트들이 존재하기 때문이다.
(하위 프로젝트들 가운데 좀 까다로운 부분이 Open SSL이고, 또 Tcl/Tk 그리고 이를 이용하는 tkinter 부분이라고 되어 있다. 특히 Tcl/Tk 부분은 pcbuild.sln으로는 빌드나 클린이 안되니 반드시 build.bat를 한번은 거쳐야 한다고 한다.)

아마도 처음에 이 부분들이 빌드가 되고 나면, 나머지 파이썬 자체의 소스를 변경하고 빌드하는 과정은 Visual Studio 내에서 가능하리라 생각한다.

build -e, 먼저 받은 소스가 있는 경우에는 skip하고 빌드.

25개 프로젝트 성공, 실패 없음, skip 1개?

이제 각 폴더에 남겨진 BuildLog.htm을 확인해 보고 문제가 없는지 확인해봐야 함.

그리고 Skip된 프로젝트가 무엇인지도...

2016년 3월 21일 월요일

파이썬의 라이브러리 NumPy + SciPy _____ 5

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

정말 정말 궁금했습니다.
왜 나만 안된다고 혼자서 이리도 고생을 하는건지....
정말 미치도록 알고 싶었습니다.

그래서 결국....파이썬의 소스를 보기로 했습니다.

마이크로 소프트가 언급한 DLL의 탐색 경로에 들어가 있음에도 자꾸 DLL을 찾지 못한다고 나오는게 너무 답답해서 누가 잘못하고 있는건지 알아봐야겠습니다.

이젠 귀찮아서 사진도 어지간하면 안올릴 생각이다.

다운로드 받은 소스는 2.7.11
https://www.python.org/downloads/release/python-2711/


소스 분석엔 소스인사이트가 최고.

핵심만 빠르게 찾아가기 위해서 메시지를 바로 찾아 보는게 장땡.

"DLL load failed"라는 문자열로 검색한 결과

dynload_os2.c
dynload_win.c

위의 두개 파일만 검색 된다...그나마 다행.
이름을 보니 볼 거 없이 dynload_win.c가 내가 찾는 파일임이 확실하다.

dynload_win.c

DLL load failed는 저기 보이는 소스에서 조금 더 내려가면 나온다.

저기서 봐야 할 것은 GetFullPathName()과 LoadLibraryEx().

먼저 해당 함수에 대한 MSDN의 설명을 참조.

GetFullPathName()

첫번째 두번째 인자가 입력이고 세번째 네번째가 출력.
그러니까 pathname을 넣고 pathbuf를 받아온 것이다.

그러면 다음엔 pathname이 아닌 pathbuf를 사용해야 할텐데, 다음의 LoadLibraryEx()에서는 pathname을 사용하고 있다.???

LoadLibraryEx()에 대한 설명도 찾아 보자.


LoadLibraryEx()

이 함수는 좀 복잡한데 마지막 인자인 dwFlags에 따라서 DLL 탐색의 순서나 방법이 달라진다고 한다.

LoadLibraryEx()의 dwFlags 설명 중.

이 플래그에 대한 설명도 참 복잡한데, LOAD_WITH_ALTERED_SEARCH_PATH를 사용할 때에는 반드시 파일을 절대 경로로 적어야 한다는 것.
그리고 탐색방법은 아래에 설명....한다고 되어 있는데, 설명이 없다.휴....

다른 페이지에서 설명을 찾았는데,

Dynamic-Link Library Search Order이라는 페이지이고,

여기에서
Alternate Search Order for Desktop Applications
이라는 항목을 찾아보면 설명이 나와 있다.
하지만 해당 항목을 읽어보면 알겠지만 통상적으로 탐색을하는 디렉토리의 순서가 다를 뿐 크게 문제가 되지는 않아보인다.

그렇다면 문제가 될 것으로 예상되는 건, 앞서 LoadLibraryEx()에서 LOAD_WITH_ALTERED_SEARCH_PATH 플래그 사용시 반드시 절대경로를 사용해야 한다는 문구였다. 절대 경로가 아닐 경우에는 결과가 어찌될지 모른다는게 설명...


과연 파이썬 소스에 결정적인 문제가 있어서 이것이 원인이었는지를 확인하려면,

1. 직접 파이썬을 빌드하고 해당 부분을 적절하게 수정한 뒤 문제가 해결되는지 확인한다.

2. 파이썬 3.x의 경우에는 이 부분이 같은지 다른지 확인하고, 또 문제가 발생하는지 여부를 확인해 본다.
  2-1. 파이썬 3.x도 소스가 같고 문제도 동일하게 발생한다면 위의 1번 방법으로 확인해야 한다.
  2-2. 파이썬 3.x도 소스가 같은데 문제가 발생하지 않는다면, 문제의 원인은 다른 곳에 있다는 의미이다. 골치 아픈 케이스.
  2-3. 파이썬 3.x는 소스가 다르고 문제가 발생하지 않는다면 3.x의 소스를 최대한 활용해서 무엇이 문제였는지 최대한 유추해 볼 수 있다. 하지만 결국엔 1번의 과정을 밟아야 한다.
  2-4. 파이썬 3.x는 소스가 다른데 문제가 동일하게 발생한다면 완전히 별개의 문제로서 따로 따로 소스를 분석해야 하지만, 파이썬 소스의 문제가 아니라 내가 사용하는 환경의 문제일 가능성이 높아진다.

3. 최소한의 비용으로 최대한의 결과를 얻기위해 리버싱으로 살짝만 확인해본다.(?)


이상의 계획을 가지고 생각해보니, 먼저 2번의 과정을 거치는게 빠르겠다 싶었다.

그래서 파이썬 3.x의 소스를 받아서 확인해 본 결과....소스가 달랐다.

아예 LoadLibraryEx()를 부르는 함수에 들어오기 전에 먼저 처리를 한게 아닐까 싶게...그래서 소스만으로 비교를 하기엔 무리가 있어서 직접 실행해 보기로 했다.

그.런.데......파이썬 3.x는 Windows Vista이상에서만 돌아간단다.....설치도 안된다...ㅠ.ㅠ

결국 2번의 방법은 몽땅 수포로 돌아가고....

1번의 정공법이냐, 3번의 편법이냐....만 남은 상황이다.

파이썬의 라이브러리 NumPy + SciPy _____ 4

==========================================================
이 포스팅은 쓸모 없어진 포스팅입니다.
(NumPy + SciPy ____ 4 ~ NumPy + SciPy ____ 8)
해당 문제점은 Scipy 패키지를 빌드했던 툴(아마도 MS Visual Studio 201x)이 Windows XP를 지원하지 않아서 발생한 것으로 추측하고 있습니다.
이후의 포스팅에서 이 시행착오를 정리할 계획입니다. (아마도 NumPy + SciPy ____ 9)
==========================================================

배포판마저 실패하게 되자 뭔가 근본적인 문제가 있지 않나 생각하게 되었다.

이미 굉장히 많은 사람들이 사용하고 있는 패키지인데, 여러 소스를 통해 받아 보아도 동일하게 문제가 발생하고 있다면, 내가 아주 기본적인 무언가를 빼먹었거나 아니면 누구나 안되는 걸 가지고 골머리를 썪이고 있는게 아닐까?

보통은 혼자서 끄적여 보고, 시행착오도 거치고 난 후에 결론이 나오면 포스팅을 하곤 하는데, 이젠 귀차니즘 때문인지 두번 반복하는게 싫어졌고, 그래서 거의 직접 하면서 중간 중간 포스팅을 하고 있다.
그 때문인지 자꾸 옆으로 새거나 아무 쓸모 없는 내용들도 포함이 되고 있다.


배포판의 실패로 이번에는 scipy.org를 다시 살펴 보다가 등록된 문제점이 있는지 확인 해 보았다.



저기에서 ScyPy 항목으로 들어가서


너무 많길래 scipy.special로 검색해 보니, 비슷한 문제점이 등록되어 있다.

https://github.com/scipy/scipy/issues/5570

읽어보니 문제는 나와 동일한 상황.
이 사람도 크리스토프 골케의 버전을 받아서 사용했다고 한다.

여기에 누군가 댓글을 달았는데, MS의 런타임 라이브러리 문제같다면서 받아서 설치해보라고 한다.(아마도 MSVCRTxx.DLL 이런걸 말하는 듯)
그런데 문제점을 올린 사람이 이미 다 설치되어 있는 상황이라고 했으니 이 문제는 아닌 듯.

여기에 관리자가 이건 NumPy나 SciPy의 문제가 아니라 Third Party에서 배포한 버전에서 발생한 문제라면서 문제점을 Close 시켜 버렸다.


이게 직접적인 도움은 되지 않았지만, 암튼 같은 문제를 겪고 있는 사람이 있으며, 사용 환경에 따라 발생할 수 있는 문제라는 걸 알게 되었다.

먼저 _ufuncs.pyd에 대해 좀 더 살펴 보기로 했다.

이 파일을 에디터로 읽으면 바이너리 파일이라 알아 볼 수 없게 나온다.


하지만 맨 앞의 MZ는 MS의 실행파일에 붙는 일종의 표식이다.

이건 _ufuncs.pyd가 DLL일 수 있다는 의미.

그래서 몇가지 툴로 이 파일의 정체를 분석을 시도해 보다가 올리 디버거(OllyDbg)에서 불러들이는 과정에 이상한 메시지를 보게 되었다.


libifcoremd.dll을 찾을 수 없다?

저게 대체 뭔데?

다시 구글 검색.
https://www.google.co.kr/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=libifcoremd.dll



검색 결과 중 몇개를 찾아보니 Intel의 Fortran Comiler에서 사용하는 DLL이라는 정보.

처음엔 웬 Fortran? 이랬는데 생각해보니 과학 기술용 패키지를 빌드하는데 포트란을 사용했을지도 모르겠다는 생각이 들었다.


에라 모르겠다 하는 심정으로 Intel 사이트에서 Fortran용 실행 라이브러리를 받았다.
https://software.intel.com/en-us/articles/redistributable-libraries-of-the-intel-c-and-fortran-compiler-for-windows


이걸 설치하려다가.....정말 무슨 귀신이 씌운건지... 우연히 살펴보게 된 NumPy의 디렉토리.
NumPy/core 폴더에 이런 파일들이 있다.


중간즈음에 libxxxxx.dll들이 눈에 뜨인다.

이 폴더에 들어있는 모든 DLL 들을 확인해 보니 모두 Intel에서 만든 것이고, 이 DLL들을 모두 SciPy/special 폴더에 복사해 넣으면 O.K.

혹은 PATH에 있는 경로에 추가해도 될 거 같은데....개인적으로는 좀 찝찝하다.

=========================================================
이젠 지긋지긋해져서 그냥 마무리 하고 싶은데,

그래도 궁금한건 궁금한거니까...추가.

몇가지 더 확인을 해 보니, SciPy의 모듈 여러가지에서 에러가 발생하고 있다.

대부분은 동일한 문제로 _ufuncs를 로드하지 못해서 발생하는 것이다.

그렇다면 위에서 찾은 dll들을 따로 따로 복사할 수 없으니 한군데에 모아두고 사용하고 싶어진다.
그래서 MS-Windows에서 DLL을 탐색하는 범위를 찾아 보니 다음과 같았다.
  1. 현재 프로세스의 실행 모듈이 있는 디렉터리
  2. 현재 디렉터리
  3. Windows 시스템 디렉터리. GetSystemDirectory 함수가 이 디렉터리의 경로를 검색합니다.
  4. Windows 디렉터리. GetWindowsDirectory 함수가 이 디렉터리의 경로를 검색합니다.
  5. PATH 환경 변수에 나열된 디렉터리

그런데, python 디렉토리에 넣어두어도, 그 python 디렉토리를 PATH에 넣어두어도 문제가 발생한다.

심지어는 Windows\System32 디렉토리에 넣어도 안된다....ㅠ.ㅠ

대체 이건 무슨 조화인가?
=========================================================

2016년 3월 19일 토요일

파이썬의 라이브러리 NumPy + SciPy _____ 3

이도 저도 안되니 결국은 과학기술용 파이썬 배포판을 사용해 보기로 했다.

과학기술용 파이썬 배포판들


위의 링크들을 대충 살펴보고 가장 기대치가 낮은 것부터 시도해 보기로 한다.

왜 나는 항상 이런식일까?

처음에 가장 좋은 것을 선택하면, 한번에 성공하고, 시간도 절약되고, 얼마나 좋은가?

그런데 왜? 가장 허접해 보이는 걸 먼저 선택하고, 실망하고, 다음걸 선택하고.... 결국은 많은 시간과 노력을 소모하는 방법을 택하는 걸까?

가보지 않은 길을 만들지 않기 위해서?
최종 선택에 아무련 후회가 남지 않도록 하기 위해서?


아무튼....

첫번째 선택은 Pyzo.
http://www.pyzo.org/index.html


Pyzo는 Python3에 Conda라는 패키지 관리자와 iPython, 그리고 IEP라는 IDE를 포함하고 있다고 되어 있다.


Pyzo가 허접하다고 생각한 이유는 홈페이지의 모습도 그러하지만, 바로 저 배포 버전의 이름 때문이었다.

OS별, CPU별 구분이야 당연한 것이고, 그 외에는 달랑 2015a라는 것 하나 뿐이다.

하지만 그만큼 이 배포판은 제약이 적을거라는 생각도 할 수 있다.
왜냐하면 특정 패키지의 업그레이드를 각 사용자들이 자유로이 해야 할 테니까...

설치 방법을 보아도 그러함을 예상할 수 있는데, exe 파일의 installer도 있지만, zip 파일을 받아서 원하는 폴더에 풀어서 사용하는 방법도 있다고 하니 말이다.

다운로드 받은 Win32용 인스톨러는 148MB, Win32용 Zip파일은 213MB이다.


먼저 Zip 파일을 압축 풀면 대략 다음과 같이 나온다.


특별한 지시사항도 없다.
README를 읽어봐도 이상한 imageio에 관한 설명 뿐이다.

그래서 먼저 pyzo를 cmd에서 실행해 보았다.



그러자 위와 같은 화면이 나오는데, 이건 IDE라던 IEP로 보인다.

실행 중인 프로세스를 확인해 보니 다음과 같이 나온다.


이게 IEP가 아닌 Pyzo와 python 인터프리터가 실행 중.

어째서 IEP라는 IDE의 이름을 Pyzo라고 만든건지....


그래서 다음은 Pyzo_activate.exe를 실행.


몇개 묻고 끝.

환경 변수에 추가된것도 없음.

레지스트리 검색해보니 다음과 같은 것이 추가 되었음.(pyzo2015a로 검색)


Trolltech라는 회사/제품인데 이건 pyzo만 쓰는게 아니라, calibre라는 eBook 프로그램도 함께 사용중인 제품으로 보임.


그리고 iPython-qtconsole 실행.
실행 하고 시험삼아 문제가 되었던 SciPy를 import해 보았다.


이건 뭐지....역시나 같은 에러 메시지.

배포판에서도 문제가 있다는 말인가?


==========================================================
첫번째 포스팅의 마지막에 추가한 것과 마찬가지로, Pyzo에 포함된 Scipy 역시 Windows XP를 지원한지 않는 것으로 보인다.
Pyzo 사이트에서는 이에 대해 공식적으로 언급한 부분이 없는 듯이 보인다.
==========================================================