For any Mac users who may be interested, the Homebrew (http://mxcl.github.com/homebrew/) installation formula for DCMTK has been updated to 3.6.0. It also now supports installation of dev libs and/or building from git HEAD.
Also, third party libraries like libtiff, libxml, libpng and so on are not required by DCMTK. You can use it greatly without. The best is to leave the 3rd party library detection on automatic mode, i.e. ./configure will find out itself whether it has the libraries available on the system. Of course, if you found that this detection does not work well for libtiff and your dependency hint is just fixing this, then you can ignore this comment (but may document that in the homebrew "package" file, otherwise people will wonder).
Thanks for the tip re: --disable-threads on OS X. I missed that change in the final INSTALL document for 3.6.0. I'll submit a change to the Homebrew formula.
Whoever wrote the original formula decided that a Homebrew build of DCMTK should include everything (including libtiff), as do the the versions from MacPorts and Fink. That seems appropriate since someone installing from Homebrew (or other package manager) is not likely to be interested in refining the build configuration. OS X already supplies libssl, libz, libxml, and libpng, so those will always be detected and enabled during configuration. OS X also supplies libwrap, though it will not work without patching DCMTK, so it will always be detected but disabled during configuration. Since libtiff is not already available in OS X, it would have been added as an explicit dependency.
Unfortunately, Homebrew doesn't really support optional dependencies. If you'd prefer libtiff to be removed as a default dependency for Homebrew DCMTK, just let me know and I'll take it out and add some appropriate caveats to the formula. I don't have an opinion either way, so I'm happy to follow your lead on this.
Last edited by dinkypumpkin on Mon, 2011-03-28, 13:22, edited 1 time in total.
The problem with libwrap is that in OS X <tcpd.h> does not have ANSI C function prototypes needed for C++. I don't use it anymore, but all I did was copy the approach used by MySQL. See this thread.