0. 들어가며


앞서 제공한 libtiff 컴파일법으로 컴파일하면, 압축된 파일들을 읽지 못한다. 완전 망ㅋ의 상황. libtiff를 가지고 여러 tiff파일을 읽던 중, 작동하지 않는 에러메시지도 아닌, libtiff 자체 내부에서 주는 warning들이 많이 뜬다. 대부분 헤더의 태그를 읽을 때 나타나는 warning인데, warning은 어쨌든 넘어갈 수 있다. 하지만, 일부 이미지를 읽는 과정에서 아래와 같은 에러를 뱉는다.

"AdobeDeflate compression support is not configured."
왓더헬 이건 대체 뭥미? 하는 것도 잠시. "configured"에서 힌트를 얻었다. '아, 빌드 할 때, 압축에 관한 내용이 포함되지 않았구나..


1. 문제점

앞서 말했듯, nmake를 통해 libtiff를 빌드하면, .lib, .dll 파일을 생성한다. 하지만, 빌드 과정에서 zlib, 즉, 압축 알고리즘을 가지고 있는 라이브러리를 포함시키지 않으면 tiff 파일을 읽을 때, 압축된 tiff 파일을 읽고 쓸 수 없다. zlib를 libtiff의 프로젝트에 include 하기 위해서, 해당 소스를 전부다 옮겨서 obj 파일로 만들어 링크하려 했으나 좋은 방법이 아니다. 검색하던 중에, nmake.opt 파일을 수정하면 될 것 같은데 잘 모르겠다는 예전 쓰레드를 발견하고 직접 열어보았다.
As I posted before, if you build libtiff with microsoft nmake, you get .lib and .dll files. But if you do not include the "zlib" - the library that has compression algorithm, your program cannot read any compressed tiff. I tried to include the "zlib" sources so that the obj files from the sources can be added to the "libtiff" project, but that was not a good idea. Googling, I found a thread that discussed about this issued and someone said that this situation MAY progress if we modify "nmake.opt" but he had no idea how to fix it exactly.


2. 해결법 - Solution

윈도우 환경에서 nmake를 이용하여 빌드할 때의 해결법만 간단히 적으면, tiffconf.vc.htiff_zip.c, 그리고 nmake.opt를 수정한다. 앞의 두 파일은 소스 디렉토리 루트 아래 libtiff 안에 있고, nmake.opt는 소스 디렉토리 루트에 존재한다.
Based on windows system with Visual Studio 2008, the solution is this: modify tiffconf.vc.h, tiff_zip.c, and nmake.opt. The previous two files exist in the "libtiff" directory under the root directory of source, and "nmake.opt" exists in the root directory of source.

tiffconf.vc.h는 tif_config.vc.h와 헷갈리기 쉬운데, 후자(tif_config.vc.h)의 경우, nmake가 전자(tiffconf.vc.h)를 이용해서 단순히 복사하는 파일이기 때문에, 빌드 과정에서 덮어씌워져 실제로 고쳐야 할 파일은 tiffconf.vc.h임을 유의해야한다. 또한, tiffconf.h도 있으니 Visual Studio(vc)라고 쓰여진 헤더를 찾아 고쳐야한다. tiffconf.vc.h를 보면 78, 79번째 줄에
/* Support Deflate compression */
/* #undef ZIP_SUPPORT */
와 같은 부분이 있다. 이 부분을 다음과 같이 고쳐준다.
/* Support Deflate compression */
#define ZIP_SUPPORT 1
tiffconf.vc.h can be easily confused with tif_config.vc.h. But the later is copied from tiffconf.vc.h by nmake while you build. So make sure you're modifying "tiffconf.vc.h". Moreover, there's "tiffconf.h". DON'T BE CONFUSED! we're under windows system with Visual Studio(vc). Double-check your file.
In 78, 79th lines in tiffconf.vc.h there's a part above. Change it as i've shown above so that it can ZIP_SUPPORT.

ZIP_SUPPORT를 사용하겠다고 환경설정을 했으니, libtiff가 진짜로 zip을 사용하는 tiff_zip.c를 고쳐야 한다. 물론, 지금 전제는 zlib이 설치되어 있거나, zlib.h를 가지고 있거나 하는 것을 전제로 한다. Visual Studio 2008의 기본 include 디렉토리에 zlib.h를 가지고 있는지 여부는 확인해보지 않았다. 이 부분은 선택적일 수 있으나, tiff_zip.c가 zlib.h를 include하기 때문에 이 부분은 어찌되었든 만나게 되는 단계일 것이다. tiff.zip.c의 50번째 줄을 보면,
#include "zlib.h"
가 있는데, 이것을 다음과 같이 수정한다
#include <zlib.h>
Now, we made it ZIP_SUPPORT, we need to the body source that utilizes zip - tiff_zip.c. Of course, I'm developing this story under the condition that you have "zlib" or "zlib.h" itself. I don't know if Visual Studio 2008 does have the zlib.h in default include directory. So, this part(modifying tiff_zip.c) can be an optional step, but i think you're going to encounter an error that tiff.zip.c needs zlib.h anyway. Change it as i've shown above so that it can include the correct zlib.h.

다음으로, nmake.opt를 열어 66번째 줄을 보면, ZIP_SUPPORT부터 4줄이 comment 되어 있는데, 이 부분을 uncomment하고, 다음 예제와 같이 zlib의 위치와 라이브러리 파일 이름에 따라 알맞게 수정한다.
ZIP_SUPPORT = 1
ZLIBDIR  = d:/projects/zlib-1.2.1
ZLIB_INCLUDE = -I$(ZLIBDIR)
ZLIB_LIB  = $(ZLIBDIR)/zlib1d.lib
And finally, open up nmake.opt and uncomment the following 4 line starting from line # 66. After uncommenting those lines, fill out zlib location, and zlib file name correctly.


3. 결과

컴파일도 잘되고 안읽히던 tiff 파일도 잘 읽힌다. 혹시 모르니 파일이나 첨부해둘까.
Now it's good to compile again with nmake. I attached zlib1d.lib, libtiff.lib, libtiff.dll

0. 들어가기


libjpg와 libpng는 Visual Studio 상에서 잘 컴파일 됐다. 다행히도 개발자들이 친절하게 프로젝트 파일이나 솔루션 파일을 제공하기 때문이다. 그런데 libtiff는 뭐임!? 약간 불친절하다고 느낄 수 있게 그런 배려가 없다.
libtiff를 배포하는 공식사이트에서는 building법을 제공할 때, nmake 쓸줄 알아야되 라고 전제하고 있다.


1. 새로운 접근 - nmake

*nix 환경에서 여러 소스를 컴파일 하는데 사용되는 make. 그 make를 윈도우에 맞게 마이크로스프트에서 개발한게 nmake인 모양. GNU maek와 BSD make의 부분적인 기능만 지원한다고 한다.
무슨말이고 하니, 그래픽 환경(GUI)를 사용할 수 없고, 명령어 프롬프트에서 작업해야 한다는 뜻이다. 검은색 화면
당연히 처음엔 cmd로 커맨드 프롬프트 띄워 nmake라고 치면 아무것도 안된다. 시스템 환경변수의 PATH 설정하고, 다시 nmake하면 실행은 된다.
원래 make는 Makefile 안에 저장된 build 순서나 그런 정보에 따라 컴파일하고 링크하는 툴이다. libtiff는 os 버젼별로(?) 혹은 make 버젼별로 makefile을 나누어놨는데, Visual Studio의 nmake가 써야 하는 makefile은 makefile.vc
그래서 대충 설정해서, nmake /f makefile.vc 라고 치면 각종 에러를 뱉는데..


2. 새로운 문제

문제가 뭔고 하니 각종 헤더 파일을 include 하지 못한다는 문제이다. 여기서부터 본격적인 헤딩이 시작되는데, 필요한 헤더 파일을 계속 복사한다고 해도 쉽게 해결되지 않는다. 짜증내며 미리 컴파일된 .dll, .lib 파일을 찾아 쓰다보면 필요한 dependency를 가진 또다른 헤더들.. 헤더들을 다 포함시켜도 링크 과정에서 에러를 뱉는다.
The problem when you compile "libtiff" using nmake is that you encounter so many errors saying "cannot fine ***.h" - header files "libtiff" depends on. Although, you copy and paste those header, you get more serious error message during linking process.


3. 새로운 해결법

시작 - 프로그램 - Microsoft Visual Studio 2008 - Visual Studio Tools - Visual Studio 2008 Command Prompt 라는 것이 있다. nmake를 위한 환경을 미리 만들어 준 상태에서 커맨드 프롬프트 창을 열어주는 아이콘이다. 물론, C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC 경로에 가면, vcvarsall.bat 파일이 있다. 이것을 실행하면 컴파일 환경이 만들어져야 하는 것이 정상(?)인 것 같지만 꼭 그렇지가 않다. libtiff 공식 사이트에는 vcvarsall.bat를 윈도우 시작 전 실행되는 배치파일인 AUTOEXEC.BAT에 추가하든가 해서 어찌됐든 컴파일 환경을 만들라고..
There's a brilliant link for making compiling environment "start - program - Microsoft Visual Studio 2008 - Visual Studio Tools - Visual Studio 2008 Command Prompt". This enables your command prompt suitable for compiling with nmake. Even the libtiff official webpage infer vcvarsall.bat in "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC" and add it into AUTOEXEC.BAT.

4. 결과

아무런 에러, 경고 없이 컴파일 잘 된다.
It's now good to go.

+ Recent posts