Autotools build on Windows tries to link with libtiff when it's not available

[danpla]

Current Behavior

When I build v5.3.1 on Windows under MSYS2 without libtiff, the configure script clearly tells that the library is not available:

checking for tiffio.h... no

Yet, linking tesseract.exe gives an error:

-ltiff: No such file or directory

It looks like the libtiff is unconditionally linked on Windows:

tesseract/Makefile.am

Lines 758 to 761 in f1e3697

	if T_WIN
	tesseract_LDADD += -ltiff
	tesseract_LDADD += -lws2_32
	endif

[stweil]

Did you try a build with line 759 removed or deactivated to avoid linking libtiff? Does it work and produce usable binaries?

For some special options Tesseract tries to write TIFF files. That options won't work without libtiff.

[danpla]

I didn't, but there's a HAVE_TIFFIO_H macro in tesseract.cpp, which suggest that libtiff support was probably designed to be optional.

[stweil]

Even if tiffio.h is not available, libtiff might still be used by the Leptonica library which is used by Tesseract. That situation could cause problems on Windows.

So either a build for Windows must provide both tiffio.h and libtiff, or it should be done without any tiff component (also no indirect tiff in Leptonica). Maybe that 2nd alternative does not work at all. The existing HAVE_TIFFIO_H does not indicate that it was designed to be supported.

[danpla]

Even if tiffio.h is not available, libtiff might still be used by the Leptonica library which is used by Tesseract

But if tiffio.h is not available, in practice this means that the development version of libtiff is not available as well. Anyway, the code in tesseract.cpp compiles fine, which suggest that the HAVE_TIFFIO_H macro is not defined, so the TIFF-related code in the file is not used and there's no sense to link with the library.

BTW, the issue only affects the tesseract program, not the library.

it should be done without any tiff component (also no indirect tiff in Leptonica)

This is exactly my case, as I use a custom Leptonica build configured with --without-libtiff.

[stweil]

We have two options for the Tesseract builds for Windows:

1. Require development version of libtiff with tiffio,h and linkable library and fail if that is missing.
2. Support builds without libtiff. If there is a need for such builds and the resulting binaries are good enough (although they won't support options which would write TIFF files), that can be implemented. There remains the risk that such a build still uses a Leptonica library which uses libtiff, resulting in potential problems when TIFF images are processed.

Option 1 is our current solution, but currently fails too late at the link stage. It should fail right at the beginning when configure is run.

Option 2 could be implemented by making tesseract_LDADD += -ltiff conditional. Then the risk is high that omitting the full TIFF support was not intentional. Adding a new configure option --disable-tiff would make it more explicit and could also disable other TIFF related Tesseract code (also for non Windows host). So a Windows build with a missing development version of libtiff would still fail like in option 1 unless TIFF support was disabled when running configure.

[fschutt]

2. Support builds without libtiff. If there is a need for such builds and the resulting binaries are good enough (although they won't support options which would write TIFF files), that can be implemented. There remains the risk that such a build still uses a Leptonica library which uses libtiff, resulting in potential problems when TIFF images are processed.

@stweil yes, I use a statically linked build with a statically linked version of Leptonica, where I disable every image format except for PNM and BMP (so I can pass images to libtesseract). This issue is annoying because I have to hack / modify the CMakeLists.txt at build time to work around this. I thought I indicated through -DHAVE_TIFFIO_H=OFF that I don't want TIFF support.

# CMakeLists.txt

  if(WIN32)
    find_package(TIFF) # for tesseract
    if(NOT TIFF_FOUND AND PKG_CONFIG_EXECUTABLE)
      # try PKG_CONFIG to find libtiff if cmake failed
      pkg_check_modules(TIFF libtiff-4)
    endif()
    if(TIFF_FOUND)
      set(HAVE_TIFFIO_H ON) # <--------------------------------- ignores user setting
      include_directories(${TIFF_INCLUDE_DIRS})
    endif(TIFF_FOUND)
  endif(WIN32)

[stweil]

So not only autotools but also cmake builds have a similar problem.

[zdenop]

We have several issues here:

1. cmake build does not allow to turn off tiff support when libtiff is detected (ignores -DHAVE_TIFFIO_H=OFF). I thing the same problem should have autotools build.
2. autotools windows build tries to link libtiff even configure did not find its development files.
3. problematic behavior if leptonica and tesseract have different build support for tiff.

=>

• we should allow the user to enable/disable optional dependencies
• build system should respect configuration (not use missing optional libraries)
• find the way how to detect tiff support in leptonica during configuration phase and produce relevant info/warning in case of "miss-configuration" with tesseract

[zdenop]

IMHO cmake part should be fixed (1. with -DDISABLE_TIFF=ON 37a9fa9, 3. with 58b75b3)

[danpla]

IMHO, due to the fact that Leptonica is dynamically linked (i.e. it's a DLL), it doesn't make much sense to do a build-time check if it was built with libtiff. Strictly speaking, the DLL can later be replaced with the one that has/lacks TIFF support.

If these two functions are the only ones that are needed in tesseract.cpp, it would probably be easier to just use them if libtiff was found and not disabled explicitly by DISABLE_TIFF. It looks unlikely that using these functions will do any harm in case Leptonica was build without libtiff.

Another solution is to load these functions dynamically (LoadLibrary/GetProcAddress) to avoid any #ifdef or build switches altogether, but that's probably too much of a burden.

[fschutt]

IMHO, due to the fact that Leptonica is dynamically linked (i.e. it's a DLL), it doesn't make much sense to do a build-time check if it was built with libtiff. Strictly speaking, the DLL can later be replaced with the one that has/lacks TIFF support.

Please don't assume that, I link leptonica statically (because I want a single .exe file for simplicity).