DCMTK Version 3.6.9 OFFIS DICOM Toolkit

Loading...
Searching...
No Matches
INSTALL file

    ==================================
    DICOM TOOLKIT (DCMTK) INSTALLATION
    ==================================

    PRE-REQUISITES
    ==============

    The DICOM toolkit (DCMTK) needs to be compiled with a C++ compiler.  We
    recommend using the GNU C++ compiler in versions higher than 9.5.0 (most of the
    development for this release was done using GNU gcc 12.2.0 on Debian Linux and
    GNU gcc 13.2.0 on Ubuntu Linux).  The software is also known to compile using
    Clang and Microsoft Visual Studio.

    Compatibility with other C++ compilers is unknown, however, we have tried to
    keep language demands to a minimum.

    You will need several hundred Mbytes (or even more than a Gbyte) of disk space
    to compile all the software.

    SUPPORTED SYSTEMS
    =================

    Microsoft Windows
    -----------------

    The DCMTK software can be compiled under a native Microsoft Windows environment
    (see section "Microsoft Windows with CMake" below for more information).

    The current DCMTK software release 3.6.9 successfully compiles on the following
    operating system / hardware / compiler combinations:

       Windows 10      / Intel x86    / Microsoft Visual C++ 2017 Community (VS 15)
       Windows 10      / Intel x86    / Microsoft Visual C++ 2019 Community (VS 16)
       Windows 10      / Intel x86    / Microsoft Visual C++ 2022 Community (VS 17)
       Windows 10      / Intel x86    / MinGW Clang 17.0.6 (i686-w64-windows-gnu)
       Windows 10      / Intel x86    / MinGW gcc 13.2.0 (i686-w64-windows-gnu)
       Windows 10      / amd64|x86_64 / Microsoft Visual C++ 2017 Community (VS 15)
       Windows 10      / amd64|x86_64 / Microsoft Visual C++ 2019 Community (VS 16)
       Windows 10      / amd64|x86_64 / Microsoft Visual C++ 2022 Community (VS 17)
       Windows 10      / amd64|x86_64 / MinGW Clang 17.0.6 (x86_64-w64-windows-gnu)
       Windows 10      / amd64|x86_64 / MinGW gcc 13.2.0 (x86_64-w64-windows-gnu)
       Windows 11      / Intel x86    / Microsoft Visual C++ 2019 Community (VS 16)
       Windows 11      / Intel x86    / Microsoft Visual C++ 2022 Community (VS 17)
       Windows 11      / Intel x86    / MinGW Clang 18.1.8 (i686-w64-windows-gnu)
       Windows 11      / Intel x86    / MinGW gcc 14.2.0 (i686-w64-mingw32)
       Windows 11      / amd64|x86_64 / Microsoft Visual C++ 2019 Community (VS 16)
       Windows 11      / amd64|x86_64 / Microsoft Visual C++ 2022 Community (VS 17)
       Windows 11      / amd64|x86_64 / MinGW Clang 18.1.8 (x86_64-w64-windows-gnu)
       Windows 11      / amd64|x86_64 / MinGW gcc 14.2.0 (x86_64-w64-mingw32)

    Unix (or lookalikes)
    --------------------

    The current DCMTK software release 3.6.9 successfully compiles on the following
    operating system / hardware / compiler combinations using the instructions
    given below:

       FreeBSD 14.1    / amd64|x86_64 / Clang 18.1.5
       Linux 4.19.0    / ppc64le      / IBM XL C/C++ 16.1.1 Community
       Linux 5.14.0    / amd64|x86_64 / GNU gcc 11.4.1    (AlmaLinux 9.4)
       Linux 6.1.0     / Intel x86    / Clang 14.0.6      (Debian 12)
       Linux 6.1.0     / Intel x86    / GNU gcc 12.2.0    (Debian 12)
       Linux 6.1.0     / amd64|x86_64 / Clang 14.0.6      (Debian 12)
       Linux 6.1.0     / amd64|x86_64 / GNU gcc 12.2.0    (Debian 12)
       Linux 6.1.0     / amd64|x86_64 / GNU gcc 13.2.1    (Alpine 3.20 musl libc)
       Linux 6.8.0     / amd64|x86_64 / Clang 18.1.3      (Ubuntu 24.04.1 LTS)
       Linux 6.8.0     / amd64|x86_64 / GNU gcc 10.5.0    (Ubuntu 24.04.1 LTS)
       Linux 6.8.0     / amd64|x86_64 / GNU gcc 11.4.0    (Ubuntu 24.04.1 LTS)
       Linux 6.8.0     / amd64|x86_64 / GNU gcc 12.3.0    (Ubuntu 24.04.1 LTS)
       Linux 6.8.0     / amd64|x86_64 / GNU gcc 13.2.0    (Ubuntu 24.04.1 LTS)
       Linux 6.8.0     / amd64|x86_64 / GNU gcc 14.2.0    (Ubuntu 24.04.1 LTS)
       Linux 6.11.0    / amd64|x86_64 / GNU gcc 14.2.0    (Ubuntu 24.10)
       MacOS X 13.4.1  / amd64|x86_64 / Apple Clang 14.0.3
       MacOS X 13.4.1  / amd64|x86_64 / GNU gcc 13.1.0
       MacOS X 13.4.1  / arm64        / Apple Clang 15.0.0
       NetBSD 10.0     / amd64|x86_64 / Clang 16.0.6
       NetBSD 10.0     / amd64|x86_64 / GNU gcc 10.5.0
       OpenBSD 7.5     / amd64|x86_64 / Clang 16.0.6
       OpenIndiana     / amd64|x86_64 / GNU gcc 13.2.0    (OpenIndiana 2023.10)

    Cross Compiling
    ---------------

    For target platforms other than Android, see section "CROSS COMPILING WITH
    CMAKE" below.  For Android, the current DCMTK release can be cross-compiled
    targeting the following platform:

       Android         / arm64        / GNU gcc 12.2.0    (API 24, ABI arm64-v8a)

    Cross compiling support with running configuration and unit tests is provided
    using CMake and requires the use of the Android emulator or Wine when targeting
    Android or Windows respectively.  Other versions of Android will most likely
    also work, but the above mentioned one is currently the only one that is being
    regularly tested.

    Other Platforms
    ---------------

    The previous release DCMTK 3.6.8 was also tested on the following platforms
    that may still work, but were not tested again for this release:

       FreeBSD 13.2    / amd64|x86_64 / Clang 14.0.5
       Linux 3.10.0    / amd64|x86_64 / Clang 3.4.2       (CentOS 7.9)
       Linux 3.10.0    / amd64|x86_64 / GNU gcc 4.8.5     (CentOS 7.9)
       Linux 4.19.0    / amd64|x86_64 / GNU 12.2.1        (Alpine 3.15.0 musl libc)
       Linux 5.10.0    / Intel x86    / Clang 11.0.1      (Debian 11)
       Linux 5.10.0    / amd64|x86_64 / GNU gcc 10.2.1    (Debian 11)
       Linux 5.15.0    / amd64|x86_64 / Clang 13.0.1      (Ubuntu 22.04.3 LTS)
       Linux 5.15.0    / amd64|x86_64 / Clang 14.0.0      (Ubuntu 22.04.3 LTS)
       Linux 5.15.0    / amd64|x86_64 / GNU gcc 9.5.0     (Ubuntu 22.04.3 LTS)
       Linux 5.15.0    / amd64|x86_64 / GNU gcc 10.5.0    (Ubuntu 22.04.3 LTS)
       Linux 5.15.0    / amd64|x86_64 / GNU gcc 11.4.0    (Ubuntu 22.04.3 LTS)
       Linux 5.15.0    / amd64|x86_64 / GNU gcc 12.3.0    (Ubuntu 22.04.3 LTS)
       Linux 6.2.0     / amd64|x86_64 / clang 15.07       (Ubuntu 23.04)
       Linux 6.2.0     / amd64|x86_64 / gcc 12.3.0        (Ubuntu 23.04)
       NetBSD 9.3      / amd64|x86_64 / Clang 13.0.1
       NetBSD 9.3      / amd64|x86_64 / GNU gcc 7.5.0
       OpenBSD 7.3     / amd64|x86_64 / Clang 13.0.0
       OpenIndiana     / amd64|x86_64 / GNU gcc 10.3.0    (OpenIndiana 2021.10)
       Windows 10      / Intel x86    / MinGW Clang 15.0.7 (i686-w64-windows-gnu)
       Windows 10      / Intel x86    / MinGW gcc 12.2.0 (i686-w64-mingw32)
       Windows 10      / amd64|x86_64 / MinGW Clang 15.0.7 (x86_64-w64-windows-gnu)
       Windows 10      / amd64|x86_64 / MinGW gcc 12.2.0 (x86_64-w64-mingw32)
       Windows 7       / Intel x86    / Microsoft Visual C++ 2015 Community (VS 14)
       Windows 7       / Intel x86    / Microsoft Visual C++ 2017 Community (VS 15)
       Windows 7       / Intel x86    / Microsoft Visual C++ 2019 Community (VS 16)
       Windows 7       / Intel x86    / MinGW gcc 9.2.0 (i686-w64-mingw32)
       Windows 7       / amd64|x86_64 / Microsoft Visual C++ 2015 Community (VS 14)
       Windows 7       / amd64|x86_64 / Microsoft Visual C++ 2017 Community (VS 15)
       Windows 7       / amd64|x86_64 / Microsoft Visual C++ 2019 Community (VS 16)
       Windows 7       / amd64|x86_64 / MinGW gcc 9.2.0 (x86_64-w64-mingw32)

    The previous release DCMTK 3.6.7 was also tested on the following platforms
    that may still work, but were not tested again for this release:

       Windows 7       / Intel x86    / Microsoft Visual C++ 2010 Express (VS 10)
       Windows 7       / amd64|x86_64 / Microsoft Visual C++ 2010 Express (VS 10)
       Windows 7       / amd64|x86_64 / Cygwin GCC 7.4.0   (x86_64-pc-cygwin)
       Windows 10      / Intel x86    / MinGW gcc 11.2.0   (i686-w64-mingw32)
       Windows 10      / Intel x86    / MinGW Clang 13.0.0 (i686-w64-windows-gnu)
       Windows 10      / amd64|x86_64 / MinGW gcc 11.2.0   (x86_64-w64-mingw32)
       Windows 10      / amd64|x86_64 / MinGW Clang 13.0.0 (x86_64-w64-windows-gnu)
       FreeBSD 13.0    / amd64|x86_64 / Clang 11.0.1
       Linux 4.19.0    / amd64|x86_64 / Clang 7.0.1       (Debian 10)
       Linux 4.19.0    / amd64|x86_64 / GNU 10.3.1    (Alpine 3.15.0 with musl libc)
       Linux 4.19.0    / amd64|x86_64 / GNU gcc 8.3.0     (Debian 10)
       Linux 4.19.0    / amd64|x86_64 / GNU gcc 8.3.0     (Debian 10)
       Linux 5.10.0    / Intel x86    / GNU gcc 10.2.1    (Debian 11)
       Linux 5.4.0     / amd64|x86_64 / Clang 10.0.0      (Ubuntu 20.04)
       Linux 5.4.0     / amd64|x86_64 / Clang 9.0.1       (Ubuntu 20.04)
       Linux 5.4.0     / amd64|x86_64 / GNU gcc 10.3.0    (Ubuntu 20.04)
       Linux 5.4.0     / amd64|x86_64 / GNU gcc 9.3.0     (Ubuntu 20.04)
       Linux 5.13.0    / amd64|x86_64 / Clang 13.0.0-2    (Ubuntu 21.10)
       Linux 5.13.0    / amd64|x86_64 / GNU gcc 11.2.0    (Ubuntu 21.10)
       MacOS X 10.15   / amd64|x86_64 / Apple Clang 11.0.0
       MacOS X 10.15   / amd64|x86_64 / GNU gcc 9.2.0
       NetBSD 9.0      / amd64|x86_64 / Clang 10.0.1
       NetBSD 9.0      / amd64|x86_64 / GNU gcc 7.5.0
       OpenBSD 7.0     / amd64|x86_64 / Clang 11.1.1

    Earlier releases of the DCMTK are known to also compile on further platforms,
    which are not available to us for testing purposes any more, e.g. AIX, HP-UX,
    IRIX, NeXTStep, OSF/1, QNX, Solaris/SunOS, Ultrix.  Also the Intel C++ Compiler
    and other compilers might still work, but we haven't tested them this time.

    THIRD-PARTY LIBRARIES
    =====================

    DCMTK can make use of the following third-party libraries:

    - OpenSSL: Support for encryption and signatures
    - zlib:    Support for Deflated transfer syntax
    - libtiff: Support for creating TIFF images
    - libpng:  Support for creating PNG images
    - libxml2: Support for converting XML to DICOM
    - libwrap: Support for network access control (TCP wrapper)
    - For character set support, either one of:
      - oficonv (default, and built into DCMTK)
      - libiconv (GNU, standalone or provided by the C standard library)

    Further information about each of the libraries can be found below.  These
    libraries are usually detected automatically on Unix-like operating systems
    during build system configuration (CMake or Autoconf).  On Windows, some
    build settings are usually required, see section "BUILDING" for details.

    OpenSSL Support
    ---------------

    DCMTK supports encrypted network transmissions using the Transport Layer
    Security (TLS) protocol as defined in DICOM part 15, as well as digital
    signatures.  DCMTK relies on the OpenSSL toolkit (www.openssl.org) for the
    underlying cryptographic routines and the TLS protocol implementation.

    This release of DCMTK requires OpenSSL release 1.1.1 or newer.  Users should
    make sure that the most recent OpenSSL patch level is applied.  This release of
    DCMTK is known to compile with OpenSSL releases 1.1.1 as well as 3.0.x to 3.4.x.

    When using CMake, if support for security enhancements is desired, a compiled
    version of the OpenSSL libraries and include files must be available during
    compilation of DCMTK.  By default, DCMTK checks whether OpenSSL is installed
    and enables support automatically if present.  By default, DCMTK checks the
    standard paths on Unix platforms.  For Windows platforms, check the discussion
    on CMake below.

    KNOWN ISSUES RELATED TO OPENSSL

    The ABI of various DCMTK libraries changes when DCMTK is built with or without
    OpenSSL.  This may result in hard to locate bugs, e.g. when using a command
    line tool that depends on one of those libraries while mixing a non-OpenSSL
    build with an OpenSSL-enabled build of DCMTK (for example, when installing an
    OpenSSL-enabled DCMTK on top of a DCMTK installation without OpenSSL support).
    We have introduced a CMake variable called "DCMTK_TLS_LIBRARY_POSTFIX" as a
    workaround.  If you plan on mixing OpenSSL and non-OpenSSL enabled builds (or
    can't be sure that your builds won't be mixed by somebody else), we suggest
    setting "DCMTK_TLS_LIBRARY_POSTFIX" to some different string for the different
    builds (e.g. an empty string for the non-OpenSSL build and "-openssl" for the
    other).  This way, all affected libraries will be named including the chosen
    postfix, effectively preventing the unintended mixing and, therefore, preventing
    the bugs.

    Zlib Support
    ------------

    DCMTK supports the "Deflated Explicit VR Little Endian" Transfer Syntax, i.e.
    ZIP-compressed network transmission and media storage.  DCMTK relies on the
    zlib toolkit (www.zlib.org) for the underlying compression routines.  This
    release of DCMTK is known to compile with zlib releases 1.2.13 to 1.3.1,
    although other releases may work as well.

    When using CMake, a compiled version of the zlib libraries and include files
    must be available during compilation of DCMTK.  See discussion on CMake below.

    Libtiff Support
    ---------------

    DCMTK supports the conversion of DICOM images to TIFF.  DCMTK relies on the
    libtiff toolkit (www.libtiff.org) for this purpose.  This release of DCMTK is
    known to compile with libtiff releases 4.5.0 to 4.7.0, although other releases
    may work as well.

    When using CMake, a compiled version of the libtiff libraries and include files
    must be available during compilation of DCMTK.  See discussion on CMake below.

    Libpng Support
    --------------

    DCMTK supports the conversion of DICOM images to PNG.  DCMTK relies on the
    libpng toolkit (www.libpng.org) for this purpose.  This release of DCMTK is
    known to compile with libpng releases 1.6.39 to 1.6.44, although other releases
    may work as well.

    When using CMake, a compiled version of the libpng libraries and include files
    must be available during compilation of DCMTK.  See discussion on CMake below.

    Libxml2 Support
    ---------------

    DCMTK supports the conversion of XML documents to DICOM files.  DCMTK relies on
    the libxml2 toolkit (www.libxml.org) for this purpose.  This release of DCMTK
    is known to compile with libxml2 releases 2.9.14 to 2.13.4, although other
    releases may work as well.

    When using CMake, if support for XML import is desired, a compiled version of
    the libxml2 (and possibly iconv) libraries and include files must be available
    during compilation of DCMTK.  See discussion on CMake below.

    TCP Wrapper (libwrap) Support
    -----------------------------

    DCMTK supports Wietse Venema's TCP wrappers library (libwrap), which is freely
    available for most Unix platforms and part of the default installation of most
    recent Linux distributions.  This library allows for enforcing host-based
    access control via the "/etc/hosts.deny" and "/etc/hosts.allow" configuration
    files.  See "hosts_access(5)" man page for details.

    When using CMake, if support for TCP wrappers is desired, a compiled version of
    the libwrap library and include file "<tcpd.h>" must be available during
    compilation of DCMTK.  See discussion on CMake below.

    Since DCMTK uses the TCP wrappers from C++ code, an ANSI C compatible header
    file "<tcpd.h>" is required.  The official release 7.6 of the TCP wrappers
    library is not ANSI C compatible and does not work with DCMTK (i.e. will not be
    recognized by DCMTK's configure script).  However, many current Linux and BSD
    distributions ship with an ANSI C compatible header file.

    Character Set Conversion Support
    --------------------------------

    DCMTK supports the conversion between different character encodings, e.g. UTF-8
    and ISO Latin-1.  In DCMTK 3.6.8 and newer, three implementations of character
    set conversion can be used:

    - oficonv, a DCMTK module based on the Citrus iconv code in FreeBSD
    - GNU libiconv
    - iconv support provided by the C standard library

    DCMTK selects the built-in module oficonv by default.  Other implementations
    can be activated by the user via the "--enable-charconv" argument (Autoconf)
    or "DCMTK_ENABLE_CHARSET_CONVERSION" (CMake).  Selecting an implementation
    that is not available will be ignored, i.e. the user's choice will be
    overridden.

    The exact values that can be chosen for "--enable-charconv" and
    DCMTK_ENABLE_CHARSET_CONVERSION are:
    - "oficonv" (default)
    - "libiconv"
    - "stdlibc" (for DCMTK_ENABLE_CHARSET_CONVERSION: "stdlibc (iconv)")

    LIBICONV SUPPORT

    The libiconv toolkit (www.gnu.org/software/libiconv/) may be used as DCMTK's
    underlying character set conversion implementation.  This release of DCMTK is
    known to compile with the libiconv release 1.17, although other releases may
    work as well.

    When using CMake, a compiled version of the libiconv and libcharset libraries
    and include files must be available during compilation of DCMTK.  See discussion
    on CMake below.

    SUPPORT FOR ICONV PROVIDED IN THE C STANDARD LIBRARY

    DCMTK allows for using the iconv implementation provided as part of the C
    standard library on some platforms.  Building DCMTK with this implementation may
    be easier and reduce additional runtime dependencies, but this option should be
    used with caution: the iconv implementations from different C standard libraries
    may vary with regard to the supported character sets and functionalities.

    If possible, the built-in oficonv implementation should be preferred.  Most
    importantly, some iconv implementations provided by the C standard library do
    not support conversion to whatever character set the terminal is currently
    using, which we consider essential and, therefore, strongly suggest not to use
    those implementations (there is a new configure test for the issue, which allows
    for querying support for this on API level).

    KNOWN ISSUES

    If both the iconv implementation from the C standard library and the libiconv
    are available in the default search paths, the wrong "<iconv.h>" file might be
    included independently from the user's choice, i.e. "--enable-charconv" or
    "DCMTK_ENABLE_CHARSET_CONVERSION".

    DCMTK currently has no mechanism to force including a certain "<iconv.h>"
    instead, so this has to be achieved by manually modifying the include paths
    and/or DCMTK's code.  Some platforms (e.g. Arch Linux) even rename the
    "<iconv.h>" file provided as part of libiconv to "<libiconv.h>" or the like to
    avoid name collisions.  In this case, the user has to modify DCMTK's source code
    to include the correct file, since we currently don't provide a configuration
    test for it.

    USING THE NATIVE STL
    ====================

    DCMTK can be configured to use the STL (Standard Template Library) features
    provided by the compiler / runtime environment instead of its own fallback
    implementations that are used by default.

    This can be achieved with the "--enable-stl" argument (Autoconf) or by setting
    "DCMTK_ENABLE_STL" to "ON" (CMake).  This will, however, not forcibly enable
    using the native STL features but instead trigger running several configuration
    tests for detecting whether the individual features work as expected/required
    by DCMTK.  It is for example known that "std::error_code" is not implemented
    correctly in some versions of Visual Studio.

    It is furthermore possible to enable or disable individual STL features
    independently of the setting provided by "--enable-stl" or "DCMTK_ENABLE_STL"
    respectively: use "--enable-stl-<feature>" or "--disable-stl-<feature>", or
    set "DCMTK_ENABLE_STL_<FEATURE>" to "ON" or "OFF" as appropriate, e.g.
    "--disable-stl-vector" or "-DDCMTK_ENABLE_STL_STRING=ON".

    SUPPORT FOR MODERN C++ STANDARDS
    ================================

    DCMTK can be configured to use several features of modern C++ standards (e.g.
    C++11 move semantics, variadic templates and the like) instead of its own
    workarounds and fallback implementations.  This can be achieved using the CMake
    variable "CMAKE_CXX_STANDARD".

    By default, DCMTK will compile with "CMAKE_CXX_STANDARD" set to "11" (CXX11).
    The user can choose to build with a newer C++ standard by setting
    "CMAKE_CXX_STANDARD" accordingly.  The following versions are supported:
    - 11 (CXX11)
    - 14 (CXX14)
    - 17 (CXX17)
    - 20 (CXX20)

    DCMTK will still compile with "CMAKE_CXX_STANDARD" set to "98" (CXX98), but
    support will be removed in future versions of DCMTK.

    Using C++11 or later will change some parts of DCMTK's API, so a C++11 build of
    DCMTK is potentially incompatible with a classic (C++98) build of DCMTK.  This
    setting is, therefore, stored in "config/include/dcmtk/config/osconfig.h" and
    verified when compiling DCMTK itself or any program that includes it.

    Having "CMAKE_CXX_STANDARD" set to "11" (or some newer C++ standard) will not
    forcibly enable DCMTK to use the respective features but instead trigger running
    some configuration tests and only truly enable the features that are really
    supported (e.g. "std::error_code" is still not implemented as intended on newer
    versions of Visual Studio, so we keep using DCMTK's own implementation there).

    Please note that this setting does not depend on enabling the STL features, but
    not all combinations (e.g. enabling C++11 but disabling "std::string") may work.

    BUILDING
    ========

    CMake is now the default tool for configuring a DCMTK build.  CMake is a
    cross-platform, open-source make system which can be used to control the
    software compilation process using simple configuration files.  CMake can be
    obtained free of charge from https://cmake.org/.  For configuring the DCMTK,
    the toolkit contains corresponding "CMakeLists.txt" files in all necessary
    directories.  In detail, these "CMakeLists.txt" files will serve as an input to
    CMake which will generate suitable build files for all of DCMTK's projects from
    these files.

    DCMTK 3.6.9 requires CMake version 3.7.0 or later.  We recommend using the
    latest stable release of CMake (currently version 3.31.2) since newer versions
    of CMake often provide better output in case of errors and are generally easier
    to use (for example, by providing better support for detecting the availability
    of third-party libraries).  If possible, use the CMake version your operating
    system provides with its package manager.

    More info about building the DCMTK with CMake can be found in DCMTK's wiki:

      https://support.dcmtk.org/wiki/dcmtk/howto/cmakeconfiguration

    CMake and shared libraries
    --------------------------

    The CMake build system allows for building shared libraries instead of static
    libraries.  On Windows systems, these are dynamic link libraries (.dll).
    On Unix systems, these are shared objects (.so).  To enable this, set the
    "BUILD_SHARED_LIBS" option to "ON".

    Additionally, it is possible to produce a single shared library for the whole
    toolkit.  This mode is controlled by the "BUILD_SINGLE_SHARED_LIBRARY" option.
    If you don't want the whole toolkit in a single shared library, the
    "DCMTK_MODULES" cache variable can be modified to select a subset of the
    available modules.  Please note that this option is marked as advanced and thus
    is hidden by default.  Also, when building a single shared library, applications
    and tests cannot be built.

    Default value for CMAKE_BUILD_TYPE
    ----------------------------------

    "CMAKE_BUILD_TYPE" is set to value "Release" if none is specified by the
    selected build file generator.  For those generators that support multiple
    configuration types (e.g. Debug, Release), "CMAKE_CONFIGURATION_TYPES" holds
    possible values.  For other generators, this value is empty, and for those
    generators the build type is fixated by CMake and cannot be changed otherwise.
    Please note that Visual Studio ignores "CMAKE_BUILD_TYPE" and always starts off
    using "Debug", so you should best change it to "Release" manually before
    starting the build process.

    To disable the "CMAKE_BUILD_TYPE" default value, set "CMAKE_BUILD_TYPE" to value
    "None" during CMake configuration, e.g. use "-DCMAKE_BUILD_TYPE:STRING=None"
    on the command line.  This may be useful if the compiler flags should be
    controlled manually (e.g. as defined in environment variables like "CXXFLAGS")
    and no CMake defaults related to the selected configuration type kick in.

    DCMTKConfig.cmake AND DCMTKTargets.cmake
    ----------------------------------------

    CMake permits to write files that describe the DCMTK build configuration
    ("DCMTKConfig.cmake") as well as all targets (executables and libraries) that
    have been produced ("DCMTKTargets.cmake").  Those files can be utilized by
    external projects by using CMake's "find_package()" mechanism in "CONFIG" mode
    in order to adapt their own build configuration, and directly make use of all
    available target libraries and executables.

    These files are written during installation to the installation directory's
    subfolder "/cmake" on Windows systems, and "/lib/cmake/dcmtk" on Unix-like
    systems.  Additionally, these files are written to the main directory of
    CMake's build tree during the build, with all content (e.g. the include
    paths within "DCMTKConfig.cmake") pointing to the correct values for the build
    tree.  Thus, even a DCMTK build tree can be used by external projects that
    process these two files.

    Microsoft Windows with CMake
    ----------------------------

    Using CMake is the only supported way to compile DCMTK for Windows.  For being
    able to do so, perform the following steps to install CMake on your machine:

    1. Go to https://cmake.org/ to download the latest release version of CMake
       for Windows.
    2. Execute the file which was downloaded to install CMake on your machine.
       Follow all install instructions appropriately.

    In order to manually configure the support for the above mentioned external
    libraries (OpenSSL, zlib, libtiff, libpng, libxml2 and libiconv), there are
    basically two ways:

    a. Using the "DCMTK_SUPPORT_LIBRARIES_DIR" setting:

    On Windows, users sometimes consider these third-party libraries hard to
    compile and integrate with DCMTK.  Therefore, the DCMTK download page offers a
    package with pre-built versions of these libraries ("support libraries") for
    Windows.  When this library package should be used, there is a single CMake
    variable ("DCMTK_SUPPORT_LIBRARIES_DIR") that can be assigned to the main
    directory of the extracted third-party package.  In that case, CMake will find
    and make available all third-party libraries to the DCMTK build and no further
    steps are necessary.

    If this is not desired, e.g. since a user wants to use different versions or
    builds of these libraries, the libraries can be configured manually.  The
    following sections include some guidance how to accomplish that for each
    third-party library.

    b. Using the manual "per-library" configuration switches:

    Through CMake, perform the following steps:

    1. Go to Start -> Programs -> CMake -> "CMake" or "CMake (cmake-gui)" to start
       the CMake utility through which the configuration can be done.
    2. In the entry field "Where is the source code:" enter the directory in which
       the DCMTK source code resides, e.g. "C:\dcmtk-3.6.9".
    3. In the entry field "Where to build the binaries:" enter the directory in
       which the libraries and binaries are to be built, e.g. "C:\dcmtk-msvc16".
    4. In the combobox "Build for:" or "Specify the generator for this project:"
       select the corresponding development environment that shall be used to
       compile the DCMTK (e.g. "Visual Studio 16 2019 Win64").
    5. Go "Configure".  (CMake will look for a corresponding compiler, read in all
       of DCMTK's "CMakeLists.txt" files and perform some tests.  The variables in
       the tabular area will be displayed in red.  These variables can now be set
       in order to turn the support for any of the external libraries on or off.)
    6. Make the corresponding configurations in CMake's user interface.  For
       example, in order to turn on libxml2 support, set the value of variable
       "DCMTK_WITH_XML" to "ON" and set the value of variable "WITH_LIBXMLINC" to
       the path where the include files and libraries of libxml2 can be found, e.g.
       "C:\libxml2-2.13.4".  The support of all other external libraries can be
       turned on in a similar way:

         libpng support:
           set "DCMTK_WITH_PNG" to "ON" and
           set "WITH_LIBPNGINC" e.g. to "C:\libpng-1.6.44"

         libtiff support:
           set "DCMTK_WITH_TIFF" to "ON" and
           set "WITH_LIBTIFFINC" e.g. to "C:\libtiff-4.7.0"

         OpenSSL support:
           set "DCMTK_WITH_OPENSSL" to "ON" and
           set "WITH_OPENSSLINC" e.g. to "C:\openssl-3.4.0"

         zlib support:
           set "DCMTK_WITH_ZLIB" to "ON" and
           set "WITH_ZLIBINC" e.g. to "C:\zlib-1.3.1"

         libiconv support:
           set "DCMTK_WITH_ICONV" to "ON" and
           set "WITH_LIBICONVINC" e.g. to "C:\libiconv-1.17"

       In order to turn the support of a certain external library off, set the
       value of the corresponding variable ("DCMTK_WITH_XML", "DCMTK_WITH_PNG",
       "DCMTK_WITH_TIFF", "DCMTK_WITH_OPENSSL", "DCMTK_WITH_ZLIB" or
       "DCMTK_WITH_ICONV") to "OFF".

       (Please note that the include files of all external libraries are always
       expected in a directory named "include" below the directory that is
       specified in "WITH_LIBXMLINC", "WITH_LIBPNGINC", "WITH_LIBTIFFINC",
       "WITH_OPENSSLINC", "WITH_ZLIBINC" or "WITH_LIBICONVINC".)

       (Please note also that the library files of all external libraries are always
       expected in directory named "lib" below the directory that is specified in
       "WITH_LIBXMLINC", "WITH_LIBPNGINC", "WITH_LIBTIFFINC", "WITH_OPENSSLINC",
       "WITH_ZLIBINC" or "WITH_LIBICONV".  Moreover, note that the following
       filenames must be used for the corresponding lib files:

         libxml2:
           "iconv_d.lib"       - debug version (* See note below)
           "iconv_o.lib"       - release version (optimized) (* See note below)
           "libxml2_d.lib"     - debug version
           "libxml2_o.lib"     - release version (optimized)

         libpng:
           "libpng_d.lib"      - debug version
           "libpng_o.lib"      - release version (optimized)

         libtiff:
           "libtiff_d.lib"     - debug version
           "libtiff_o.lib"     - release version (optimized)

         openssl:
           "dcmtkcrypto_d.lib" - debug version
           "dcmtkcrypto_o.lib" - release version (optimized)
           "dcmtkssl_d.lib"    - debug version
           "dcmtkssl_o.lib"    - release version (optimized)

         zlib:
           "zlib_d.lib"        - debug version
           "zlib_o.lib"        - release version (optimized)

         libiconv: (* See note below)
           "libiconv_d.lib"    - debug version
           "libiconv_o.lib"    - release version (optimized)
           "libchset_d.lib"    - debug version
           "libchset_o.lib"    - release version (optimized)

       The debug versions of all libraries must be compiled for the multithread
       debug version of the runtime (/MTd), the release version must be compiled
       for the non-debug multithread runtime (/MT).  Precompiled versions of all
       libraries (*) can be downloaded from https://dcmtk.org/develop/#lib-win .

       (*) Starting with DCMTK 3.6.8, libiconv is no longer part of the download
           package.  That also means that libxml2 was built without this library.
           Therefore, DCMTK tools that read XML files will only support UTF-8 and
           Latin-1 encoding.

       In the CMake GUI, there are a few more settings that can be modified
       to affect the way DCMTK is compiled.  The most important of these are:

        - DCMTK_OVERWRITE_WIN32_COMPILER_FLAGS: By default, DCMTK will compile
          using the default compiler options selected by CMake.  When this macro
          is enabled, these default options are modified based on the value
          of the "DCMTK_COMPILE_WIN32_MULTITHREADED_DLL" setting (see below).
          Default: ON.
        - DCMTK_COMPILE_WIN32_MULTITHREADED_DLL: Controls the Windows build
          model.  When this setting is "ON", DCMTK is compiled with the
          "Multithreaded DLL" build model (/MD or /MDd); when the setting is
          "OFF", DCMTK is compiled with the "Multithreaded" build model
          (/MT or /MTd).  This setting is ignored unless the
          "DCMTK_OVERWRITE_WIN32_COMPILER_FLAGS" option is "ON".  Default: OFF.
        - BUILD_SHARED_LIBS: Build the DCMTK libraries as shared libraries.
          This setting overrides the value of the options
          "DCMTK_OVERWRITE_WIN32_COMPILER_FLAGS" and
          "DCMTK_COMPILE_WIN32_MULTITHREADED_DLL", which are both set to "ON".
          Default: OFF.
        - BUILD_SINGLE_SHARED_LIBRARY: Build a single shared library for the
          whole toolkit.  This setting overrides the value of the option
          "BUILD_SHARED_LIBS", which is set to "ON".  Default: OFF.
        - DCMTK_USE_WIN32_PROGRAMDATA: An experimental setting that will cause
          data files (such as the DICOM dictionary "dicom.dic" and the oficonv
          character set mapping tables) and configuration files to be installed
          and expected in a subdirectory of the "ProgramData" directory.

    7. Go "Configure" a second time.  (CMake will adjust the configuration
       according to the displayed specifications.)
    8. Go "OK" or "Generate".  (CMake will generate new project files in the
       corresponding directories.  These files will be adjusted according to the
       displayed specifications, i.e. support for the external libraries will be
       turned on or off.)

    Having performed these steps, the Microsoft Visual Studio IDE can be started,
    DCMTK's workspace file can be opened, and one or more of DCMTK's subprojects
    can be built.  In case you want to build all libraries and applications, mark
    the predefined target "ALL_BUILD" and build it.  The "INSTALL" target installs
    the executables, libraries, include, support and documentation files to the
    directory specified by the variable "CMAKE_INSTALL_PREFIX" (very similar to
    "make install-all" on Unix systems).

    Compilation and installation of the various command line applications
    (including the test programs) can be disabled by setting the "BUILD_APPS"
    option to "OFF" before configuring and generating the project files.  By
    default, all command line applications are built and installed.

    Please note that other Windows compilers, e.g. Borland C++ Builder, are
    currently not actively supported.  However, they may work.

    Known limitations of DCMTK on the Windows platform:

    - The dcmqrscp tool cannot spark multiple processes.  Every association must be
      handled completely before a new association is possible.

    Unix with CMake
    ---------------

    One key difference when using CMake for building on Unix-like systems is that we
    use the "find_package()" mechanism for all external libraries.  Most Unix-like
    systems provide a package manager or even if not at least have a consistent
    approach for where the libraries and include files are installed such that the
    CMake "find_package()" mechanism typically finds them out of the box.

    If that does not work or you want to use a different version of a library than
    the one in the default search paths, you should look at the documentation of
    the respective "find_package()" module to find out which variables need to be
    modified, e.g. "FindZLIB" to control which version of the zlib will be used,
    see: https://cmake.org/cmake/help/latest/module/FindZLIB.html .

    The typical way to build DCMTK on Unix-like systems with CMake is as follows
    (if not using the GUI, in that case look at the description for Windows above):

        mkdir dcmtk-3.6.9-build
        cd dcmtk-3.6.9-build
        cmake ../dcmtk-3.6.9
        make -j8
        make DESTDIR=../dcmtk-3.6.9-install install

    The above commands assume that the DCMTK source code was extracted to the
    current working directory into a folder named "dcmtk-3.6.9".  DCMTK will be
    configured using CMake with the default options, detecting and including all
    available support libraries and then compiled using eight CPU cores
    ("make -j8", adjust as needed).  The result will be installed to the directory
    "dcmtk-3.6.9-install" next to the source code directory.

    If you want to modify your build configuration, like enabling or disabling some
    features of DCMTK (e.g. PNG support), or if you need to modify the predefined
    build variables, you can use the curses-based CMake configuration tool ccmake.
    First, create the initial build setup (system check) and then call "ccmake":

        mkdir dcmtk-3.6.9-build
        cd dcmtk-3.6.9-build
        cmake ../dcmtk-3.6.9
        ccmake ../dcmtk-3.6.9

    Now you can modify the configuration values.  Please see the help on the bottom
    of the screen.  When finished, press "c" to generate a new build configuration,
    then quit ccmake.  Now you can continue to build by calling "make" etc.

    If you already know the variable names, types and values to set, you can skip
    the ccmake step above and call "cmake" directly with the desired values set.
    Example for a build with TCP wrapper disabled:

        mkdir dcmtk-3.6.9-build
        cd dcmtk-3.6.9-build
        cmake -DDCMTK_WITH_WRAP:BOOL=FALSE ../dcmtk-3.6.9
        ...

    The format is "NAME:TYPE=VALUE".  Use ccmake to find out the variable names and
    their types ("BOOL" with "TRUE"/"FALSE" or "STRING").  Some of the more
    important variables are:

      - BUILD_APPS: Build the DCMTK command line tools? Default: ON.
      - BUILD_SHARED_LIBS: Build the DCMTK libraries as shared libraries?
        Default: OFF.
      - CMAKE_BUILD_TYPE: Debug or Release build.  Default: Release.
      - CMAKE_INSTALL_PREFIX: Installation prefix.  Default: "/usr/local".
      - DCMTK_DEFAULT_DICT: Activate the builtin, external or no DICOM data
        dictionary on DCMTK startup?  Default: builtin on Windows, external on
        Linux/Posix.
      - CMAKE_CXX_STANDARD: C++ language version to be used.  Default: 11.
      - DCMTK_ENABLE_STL: Replace DCMTK's OFString, OFList, OFVector etc. by the
        STL classes std::string, std::list, std::vector etc.  Default: OFF.
      - OPENSSL_ROOT_DIR: Directory where OpenSSL is installed.  Default: search
        in standard directories for headers and libraries.

    HTML DOCUMENTATION AND MAN PAGES
    ================================

    Most DCMTK modules have been documented with Doxygen (www.doxygen.org), a free
    source code documentation system similar to Javadoc.  Unix users who have
    Doxygen installed can create a hypertext documentation with "make html" in the
    "dcmtk-3.6.9" or "doxygen" directory; Windows and other CMake users should
    build the "DOXYGEN" target.  A project file for Microsoft's HTML Help Workshop
    can also be generated allowing to create a single CHM file (compressed HTML)
    from the documentation.  Other output formats (e.g. LaTeX) can be enabled by
    changing the configuration file in the "doxygen" directory.

    Currently, dcmapps, dcmect, dcmfg, dcmiod, dcmimage, dcmimgle, dcmjpeg, dcmpmap,
    dcmpstat, dcmrt, dcmseg, dcmsign, dcmsr, dcmtls, dcmtract, dcmwlm, oficonv and
    ofstd are completely documented; dcmdata, dcmjpls, dcmnet, dcmqrdb and oflog
    are almost completely documented.  See FAQ entry: "Where is rest of the
    documentation?"

    On Unix platforms, man pages for all command line tools are installed during
    the "make install" step.  In order to use them, just add the directory (e.g.
    "/usr/local/share/man") to the "MANPATH" environment variable and call
    "man dcmdump" to check whether it works.

    In order to generate plain text files from the man pages call "make text" in
    the "doxygen" directory.  The output files are stored in "doxygen/man2text".

    DICOM DATA DICTIONARY
    =====================

    Almost all DCMTK tools and libraries require the so-called DICOM data dictionary
    (i.e. information from part 6 of the DICOM standard) to be available in order
    to map the Attribute Tags to their associated Value Representation (VR), Value
    Multiplicity (VM) and Attribute name (official keyword).  The data dictionary
    can either be loaded from file (default on Unix systems) or be built into the
    respective tool / dcmdata library (default on Windows systems).  The default
    behavior can be changed using appropriate configuration options.

    Details can be found in the documentation file at "dcmdata/docs/datadict.txt"
    (or "/usr/local/share/doc/dcmtk-<VERSION>/datadict.txt").

    OFICONV DATA FILES
    ==================

    When oficonv is used to implement character set conversion (which is the
    default, starting with DCMTK 3.6.8), then a set of binary data files containing
    mapping tables are used during the conversion process.  By default, these are
    installed and expected in DCMTK's data path ("/usr/local/share/dcmtk-<VERSION>/
    data") in the subdirectories "esdb" and "csmapper".  The data path can be
    overridden at runtime by setting the environment variable "DCMICONVPATH" to
    point to a different directory.

    It is possible to embed the mapping tables into the oficonv library, in which
    case no external files are needed at runtime.  This can be enabled by setting
    the CMake variable "DCMTK_ENABLE_BUILTIN_OFICONV_DATA" to "ON".  This behavior
    is enabled by default when DCMTK is compiled into shared libraries (option
    "BUILD_SHARED_LIBS" set to "ON"), and disabled by default otherwise.  Note that
    when using static libraries, the built-in mapping tables will increase the size
    of each executable by approx. 4 MBytes.

    The "DCMICONVPATH" environment variable is respected even when built-in mapping
    tables are available.  In this case, the files referred to by "DCMICONVPATH"
    override the built-in files, unless "DCMICONVPATH" points to DCMTK's default
    data path.

    COMPILE-TIME FLAGS AND ENVIRONMENT VARIABLES
    ============================================

    The behavior of several DCMTK tools and libraries can be modified by a number
    of compile-time flags (macros).  Those macros that are not automatically
    handled by the configure mechanism are documented in "config/docs/macros.txt"
    (or "/usr/local/share/doc/dcmtk-<VERSION>/macros.txt").

    There is also a number of environment variables that affect DCMTK's behavior.
    These are documented in "config/docs/envvars.txt" (or "/usr/local/share/doc/
    dcmtk-<VERSION>/envvars.txt").

    RUNNING THE TEST SUITE
    ======================

    DCMTK comes with a test suite that verifies that the toolkit works as expected.
    The tests are contained in a module's "tests" subdirectory.  Some tests are
    marked as exhaustive and are only run if explicitly enabled, see below.

    When using Autoconf for building DCMTK, all tests can be run via "make check".
    If a test fails, make will stop and the failure reason of the test that failed
    should be visible.  Additionally, you may run the exhaustive unit tests by
    typing "make check-exhaustive".

    You can also run the test suite with CMake.  However, the steps needed for
    running the test suite depend on the generator used.  The Visual Studio
    generators will create a "RUN_TESTS" target.  Building this project will call
    CTest and run all tests.  When using the Makefile generator, "make test" runs
    the test suite.  Additionally, you may run the exhaustive unit tests by typing
    "make test-exhaustive".  Other generators should use a similar approach.

    For closer inspection, individual tests can be run directly.  The Makefiles
    will build the test runner for each module as "<module>/tests/tests".  CMake
    will add the module name as a prefix to this file's name, e.g. "ofstd_tests".
    For more information, call this program with the "--help" option.

    CROSS COMPILING WITH CMAKE
    ==========================

    The main challenge when cross-compiling DCMTK is that some of the feature tests
    performed by CMake require certain small test programs to be compiled and run,
    which does not work in a cross-compilation setting.  Starting with DCMTK 3.6.8,
    basic support for cross-compilation has been added.  This can be enabled by
    setting the CMake variable "DCMTK_NO_TRY_RUN":

      cmake -DDCMTK_NO_TRY_RUN:BOOL=TRUE

    In this case, CMake expects all test results that are normally achieved by
    executing certain test programs to be provided by the user on the command line.
    In detail, these are the variables that need to be provided:

      The following variables are only used when compiling with libiconv support
      and can otherwise be set to default values:
      - DCMTK_ICONV_FLAGS_ANALYZED: should always be set to TRUE
      - DCMTK_FIXED_ICONV_CONVERSION_FLAGS: The output printed by the test program
        "config/tests/iconv.cc", when run on the target platform.  This value is
        only used when compiling with old libiconv versions (older than libiconv
        1.8) and determines the iconv behavior when encountering illegal byte
        sequences during a character set conversion.  Possible values are:
        - "AbortTranscodingOnIllegalSequence" (use as default)
        - "DiscardIllegalSequences"
      - DCMTK_STDLIBC_ICONV_HAS_DEFAULT_ENCODING: true if the test program
        "config/tests/lciconv.cc" exits with a return code of zero, false otherwise.
        This test determines if libiconv has a default encoding, i.e. if
        "iconv_open()" accepts "" as an argument.  Use FALSE as default.

    For further information on cross-compiling DCMTK, see:
    https://support.dcmtk.org/redmine/projects/dcmtk/wiki/Cross_Compiling

    BUILDING (Unix with Autoconf)
    =============================

    Configuring a DCMTK build with GNU Autoconf has been deprecated and will be
    removed in a future release.  In the current release, the "configure" script in
    DCMTK's top-level main directory has been removed as the final warning for users
    of the Autoconf toolchain.  If you prefer to build DCMTK with Autoconf, however,
    this is still possible.  Perform the following steps from the top-level
    ("dcmtk-3.6.9") directory to compile and install the software:

    Step 0:
        cd config
        ./rootconf
        cd ..

    Step 0 creates the configure script in DCMTK's top-level directory.

    Step 1:
        ./configure --ignore-deprecation

    Step 1 executes the configure scripts in each subdirectory.  First, the system
    capabilities are examined and then Makefiles are generated.  By default,
    executables and other files will be installed (in Step 3) in the directory
    "/usr/local" in the corresponding subdirectories.  If you wish to use another
    install prefix you can use the "--prefix=<path>" option to configure.  E.g., if
    you wish to install underneath your home directory in "~/dicom" then you should
    start configure as:

        ./configure --ignore-deprecation --prefix=$HOME/dicom

    Step 1 is also the place where support for the external libraries can be enabled
    or disabled.  By default, all libraries installed in the standard path are
    enabled automatically.  Use the "--without-openssl" switch to disable OpenSSL
    support.  The "--with-opensslinc" option allows for specifying the directory in
    which OpenSSL is installed.  This is usually the directory that has been used as
    "--prefix" when compiling and installing OpenSSL.

    For example, if you wish to enable the security enhancements, and OpenSSL is
    installed in "/usr/local/apps/openssl-3.4.0", you should start configure as:

        ./configure --ignore-deprecation
                    --with-opensslinc=/usr/local/apps/openssl-3.4.0

    Configure will assume that the OpenSSL include files are installed in
    "/usr/local/apps/openssl-3.4.0/include" and will expect the library in
    "/usr/local/apps/openssl-3.4.0/lib".  Appropriate options will be passed to
    the compiler and the linker.

    Support for zlib, libtiff, libpng, libxml2, libwrap, and/or libiconv can be
    enabled in a similar way (in case these libraries are not installed in the
    standard path), e.g.:

        ./configure --ignore-deprecation
                    --with-libzlibinc=/usr/local/apps/zlib-1.3.1
                    --with-libtiffinc=/usr/local/apps/libtiff-4.7.0
                    --with-libpnginc=/usr/local/apps/libpng-1.6.44
                    --with-libxmlinc=/usr/local/apps/libxml2-2.13.4
                    --with-libwrapinc=/usr/local/apps/tcp_wrappers-7.6
                    --with-libiconvinc=/usr/local/apps/libiconv-1.17

    Different configure options can be combined in any order.  "configure --help"
    will print a list of all existing configure options.  "configure --help=short"
    will display only those options that are specific to the DCMTK.  Useful
    configure options are:

      --enable-debug          compile with debug code, don't optimize
      --disable-debug         compile without debug code (default)
      --enable-threads=TYPE   compile with MT support (posix/solaris/auto=default)
      --disable-threads       compile without MT support
      --enable-lfs=TYPE       compile with LFS support (lfs/lfs64/auto=default)
      --disable-lfs           compile without LFS support
      --enable-default-dict=TYPE  enable default dictionary and specify type
                              (external=default/builtin)
      --disable-default-dict  disable default dictionary
      --enable-dcmdictpath    enable DCMDICTPATH environment variable (default)
      --disable-dcmdictpath   disable DCMDICTPATH environment variable
      --enable-private-tags   enable private tag dictionary
      --disable-private-tags  don't enable private tag dictionary (default)
      --disable-rpath         do not hardcode runtime library paths
      --enable-charconv=TYPE  enable character set conversion support
                              (libiconv/stdlibc/oficonv=default)
      --disable-charconv      disable character set conversion support
      --enable-cxx11          use C++11 (default)
      --disable-cxx11         do not use C++11
      --enable-stl            use C++ STL
      --disable-stl           do not use C++ STL (default)

    Step 2:
        make all

    Step 2 will build the libraries and executables.  If you run into problems see
    the section "Solving configuration and compilation problems" below.

    Step 3:
        make install

    Step 3 will install the executables and some support files (data dictionary,
    configuration and documentation files).  If you also wish to install the
    libraries and include files then use "make install-lib".  For the HTML
    documentation (see above) use "make install-html" (requires Doxygen to be
    installed); "make install-all" installs all of the above.

    In case the files should be installed in a temporary directory, e.g. in order
    to create a distribution package, use "make install DESTDIR=<path>" to prepend
    "<path>" to the installation directories specified for configure.

    Step 4:
        make distclean

    Step 4 will revert the source tree to the state prior to Step 1.  If you just
    want to get rid of object files and local executables use "make clean" instead.

    Note: In case you do not want to compile all modules, you can remove those
    modules from the text file "config/modules" prior to Step 1 and execute the
    following commands:

        cd config
        ./rootconf
        cd ..

    This generates a new Makefile and configure script in the top-level toolkit
    directory.

    Solving configuration and compilation problems
    ----------------------------------------------

    The configure script might not be able to guess the correct compiler and
    compiler flags to use.  For example, we have noticed that use of the "-pedantic"
    flag to the GNU C++ compiler causes compilation errors on some systems due to
    system include files with incorrect ANSI function prototypes.

    You can set environment variables to initialize configure before it is called
    (before Step 1 above):

      Set environment variable "CC" to the name of your C compiler.
      Set environment variable "CFLAGS" to the compile flags of your C compiler.
      Set environment variable "CXX" to the name of your C++ compiler.
      Set environment variable "CXXFLAGS" to the compile flags of your C++ compiler.
      Set environment variable "LDFLAGS" to your linker flags.
      Set environment variable "CPPFLAGS" to you preprocessor flags.

    You do not need to specify all the above environment variables since the
    default settings are sensible for most Unix compilers.  Further influential
    environment variables are listed in the output of "configure --help".

    If the configure script fails you may have to change the configuration settings
    in the "config" directory.  See the "config/docs" directory for more
    information.

    See also the FAQ at https://forum.dcmtk.org/faq for more hints.

    ---------

    Have fun.

    M. Eichelberg, J. Riesmeier, M. Onken, T. Xu
    DCMTK Development Team, Oldenburg, Germany.

    Last revised: 2024-12-10 (Onken)

Generated on Sat Mar 1 2025 for DCMTK Version 3.6.9 by Doxygen 1.13.2