리눅스에 OpenCascade 6.5 자체를 까는 것은 문제가 없었다.
직접 컴파일 하는 것은 불필요하다고 생각되고
우분투에서 패키지로 제공되는 것들을 그대로 이용하기로 하였다.
다만 정확히 무엇을 깔아야 되는지는
https://launchpad.net/ubuntu/+source/opencascade
를 참고할 수 있었다.
체크 완료.
여기에 추가하여 Python-occ를 설치하기 위해
http://lists.en.qi-hardware.com/pipermail/discussion/2011-July/008480.html
이곳을 참고한다.
여기 설명된 선행작업으로 Python-occ 소스 배포본 안에 들어있는
SMESH를 컴파일하는 것은 큰 문제없이 끝났다.
GEOM를 컴파일할 때는 Fatal Error가 하나 뜨는데
------------------------------------------------------------------
디렉토리../Partition_Loop2d.cpp:35:45: fatal error: BRepOffset_DataMapOfShapeReal.hxx: 그런 파일이나 디렉터리가 없습니다
compilation terminated.
------------------------------------------------------------------
대충 이런 내용이 나온다.
즉 Partition_Loop2d.cpp 소스를 컴파일하다 보니깐
BRepOffset_DataMapOfShapeReal.hxx 파일이 없어서 중단한다는 거다.
B-Rep은 Boundary Representation 이니깐 앞서 이미 설치된 OpenCascade 패키지안의 파일일 터.
따라서 /usr/include/opencascade 디렉토리에 들어가서 뒤져보니,
과연 해당 파일이 누락되어 있다.
결론적으로 Ubuntu에서 제공되는 OpenCascade 6.5 의 배포판 자체에 이 파일이 빠져있어서 배포되고 있다는 이야기.
구글링을 해 보니, 데비안 버그리포트가 하나 나온다.
여기서 확인되듯이 Debian 에서 원래 제공하는 OpenCascade 6.5 배포판 자체가 문제가 있다는 것이다. 위 버그리포트에서는 Netgen을 컴파일하다가 누가 발견해서 보고한 모양이다.
데비안 측에서도 심각한 버그라고 인정하고 다음판에 반영하겠다고 하는 모양이다.
아무튼 나로서는 이 문제를 어떻게 떼워넣어야 할 것이므로
일단 누락된 BRepOffset_DataMapOfShapeReal.hxx 파일을 구해야 한다.
OpenCascade.org 에서 제공하는 원본 소스코드 (버전 6.5.4) 의 소스코드 전체를 다운로드 받아둔 것이 있기 때문에 여기서 찾아봤다.
그런데 없는거다...
황당
결국 문제는 데비안이나 우분투 배포판 제작자가 실수한게 아니고
OpenCascade 쪽에서 해당 파일을 빼먹은 것으로 생각된다.
이 헤더파일이 6.5 버전으로 오면서 불필요해졌다고 하더라도, 하위호환성을 위해서 그대로 유지해 주거나 해서 에러가 안 나게 해 줬으면 좋았을 것을.
결국 다시 구글링 해서 버전 6.3에 들어있는 해당 파일을 복사해서 /usr/include/opencascade 디렉토리 안에 복사해 넣어줬다.
이게 다가 아니고, 또 이 인클루드 파일이 또 인클루드 하는 다른 파일이 더 있는데 그놈들도 빠져있다.
Handle_BRepOffset_DataMapNodeOfDataMapOfShapeReal.hxx
Interface_DataMapOfIntegerTransient.hxx
Handle_BRepOffset_DataMapNodeOfDataMapOfShapeReal.hxx
Interface_DataMapIteratorOfDataMapOfIntegerTransient.hxx
대충 이런 것들이 줄줄 빠져 있는데
아무튼 전부 버전 6.3에서 갖다 넣어준다.
원래 python-occ 0.5 가 OpenCascade 6.3 에 맞춰져 있기 때문에 할 수 없는 듯 하다.
OpenCascade 6.3을 스스로 컴파일해서
우분투에 설치할 능력(?)이 있다면 처음부터 그렇게 했으면 좋았을지도 모른다.
아무튼 이렇게 패치해 주고 나니깐 make가 별 문제없이 끝난다.
이렇게 make 된 SMESH 및 GEOM을 make install을 각각 해 주면
각각 또 에러가 하나씩 뜨는데, 어떤 .so 파일을 /usr/local/lib 안에 복사해 넣어줄 수 없다는 이야기이므로, 슈퍼유저 상태로 그냥 강제로 해당 파일들을 복사해 넣어줬다.
그 다음...
이제 python-occ의 소스코드 디렉토리로 와서
python setup.py build -j4
때려주고 빌드 시도하니깐
Building pythonOCC-0.5 for linux2
Checking OCC Standard_Transient.hxx header ... found
Checking OpenCASCADE libraries BinLPlugin not found Missing library BinLPlugin. Compilation aborted.
이렇게 나온다.
매 단계마다 뭐가 하나씩 빠졌다고 나오는 판에 그냥 돌아버릴 지경이다... ㅠㅠ
BinLPlugin은 또 뭐하는 물건이길래 빠졌다는 건지...
또 구글링 해 보니
https://github.com/tpaviot/oce/issues/245
이 모듈은 OpenCascade 6.5 버전에서 '드랍' 되었다는 답변이 달려있다.
http://pl.digipedia.org/usenet/thread/11246/620/
또 여기서의 답변을 보면..
Hi Oliver, The pythonOCC SWIG files have to be re-generated from the new release header files, since there might have been changes from 6.3.0 to 6.5.0 in the OCC API. Some other changes are perhaps necessary (for instance remove the BinLPlugin dependency, as you reported). The plan is then as follows: - first manage to get OCC 6.5.0 compiled on MacOSX (I've been playing with it for two hour, and it fails) - just wait for a couple of months to know whether OCC 6.5.0 can actually be trusted. I'm quite sure that, in the following weeks, many messages on the OCC forum will come with patches to the build system (the OCC team did not make any progress with automake) - hack the current pythonOCC so that it becomes compliant with this new OCC release. This part of the work will be a very good opportunity to check the robustness of the wrapper, since it is automatically generated. It took 3 years to generate a wrapper for 6.3.0, I hope it take 3 days to do the same for 6.5.0! Of course any help/feedback is welcome regarding this topic. The next release will also come with the refactored wrapper from Henrik Rustrom, as well as a Sphinx based documentation. Regards, Thomas
발번역
python-occ SWIG 파일들이 새로운 릴리즈의 헤더파일들로 재생성되어야 한다고 한다.이유는 OpenCascade가 6.3 에서 6.5로 바뀌면서 API들도 바뀌었기 때문에....이것 말고 다른 변경들도 있을 것이므로, 해결책으로는(1) OCC 6.5의 소스코드를 잘 관리해서 새로 컴파일할 것 (2시간동안 해 봤는데 결국 실패)(2) OCC 6.5가 믿을만 할 때 까지 몇달 더 기다릴 것. (최근 수주간에 걸쳐 포럼에 많은 메시지가 오고 있으므로 빌드 시스템에 패치가 이루어질 것 같음. OCC 팀은 automake 프로세스 개발에 별 진전을 보이지 못하고 있음.)(3) python-occ 코드를 해킹할 것 (OCC 6.5에 호환되도록)이런 일은 wrapper의 신뢰성을 체크하는 좋은 기회가 될 것이다. 이렇게 함으로써 자동 생성이 가능해질 수 있을 것이다. OCC 6.3.0의 wrapper가 만들어지는데 3년이나 걸렸다!OCC 6.5.0의 wrapper 작업은 딱 3일 걸렸으면 좋겠다!이하생략... 궁시렁 궁시렁
(1), (3)번 즉 '해킹'을 해야 해결이 된다는 이야기군화... 멘붕 ㅠㅠ
결국 (2)번 - "무작정 기다리기"가 사용자 입장에서 할 일인 듯 하다.
포기... ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ
-----> 결론
최신버전 우분투 계열에서는 OCC 6.5가 제공되기 때문에
OCC 6.3에 맞춰서 개발된 python-occ 0.5는 이용 불가능하다는 소리.
python-occ가 버전업 되거나
OCC 6.5가 안정화 및 하위호환성 확보 되거나
둘 중의 하나가 이루어져야 한다는 것...
댓글 없음:
댓글 쓰기