2012-08-31 4 views
2

나는 자체 개발 한 소프트웨어를 가지고있다. Fortran으로 작성되었으며 1) 솔버 파일, 2) 모델 파일, 3) 사용 모델이 정의 된 파일 등 3 가지 파일로 구성됩니다. 솔버는 또한 lapack과 HSL ma41과 같은 라이브러리를 사용합니다. 대개 사용자를 위해 필요한 모델을 선택하고 함께 컴파일하고 실행 파일을 제공합니다.소스 코드 공개하지 않고 포트란 라이브러리 공유

사용자가 솔버 소스 코드를 변경/수정/볼 수 없어도 자신의 모델을 추가하거나 기존 모델을 수정할 수있게하고 싶습니다.

솔버를 오브젝트 파일로 컴파일하는 것이 하나의 생각이었습니다. 그런 다음 사용자는 정의 파일과 모델을 컴파일하고 라이브러리와 함께 연결합니다. 그게 가능하니? 그때 사용자는 솔버가 컴파일 된 플랫폼과 동일한 플랫폼을 가지고 있어야만합니까? (예 : Windows 64 비트 용 인텔 컴파일러) 그렇다면 가능한 모든 조합의 OS/하드웨어/컴파일러 용 라이브러리를 만들어야합니까?

또 다른 아이디어는 해석기 소스도 보내지만 난독 화를 사용하는 것입니다. 온라인에서 테스트를 거쳐/신뢰할 수있는 솔루션을 찾을 수 없습니까? 좋은 선택입니까?

미리 감사드립니다.

답변

2

사용자가 제안한대로 오브젝트 코드를 라이브러리에 배포 할 수 있습니다. 코드의 진입 점이 Fortran 모듈에 있으면 모듈 컴파일 결과 인 mod 파일 (또는 컴파일러에 해당하는 파일)도 배포해야합니다.

(라이브러리 코드의 엔트리 포인트 중 하나가 외부 프로 시저 인 경우 이러한 외부 프로 시저에 대한 인터페이스 블록을 제공하면 사용자가 편리하게 사용할 수 있습니다. 이러한 인터페이스 블록은 소스 형식이 될 수 있습니다 라이브러리 설명서가 제공해야하는 것 이상의 정보) 또는 모듈로 미리 컴파일 될 수 있습니다.

오브젝트 코드는 플랫폼 (아키텍처) 특정, 컴파일러 특정, 컴파일러 특정 및 경우에 따라 컴파일 옵션 특유한. 솔버와 클라이언트 모델 간의 인터페이스를 신중하게 설계하고 지정하면 잠재적 변형을 완화 할 수 있습니다. 예를 들면 - 많은 플랫폼은 잘 정의 된 (아마도 명백한 명세 또는 거의 유비쿼터스 컨벤션을 통해) C 애플리케이션 바이너리 인터페이스를 가지고 있기 때문에, C 등가물을 사용하여 기술 된 인터페이스는 일반적으로 견고하며, 공통 프로세서 인 Fortran 포트란 인터페이스.

관련 문제