이 포스팅은 쓸모 없어진 포스팅입니다.
(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번의 편법이냐....만 남은 상황이다.
댓글 없음:
댓글 쓰기