FLTK_OPTION_PRINT_SUPPORT=OFF still requires linking winspool

[Jeff Paranich]

Hi All,

I am trying to get my cross-compiled binary size down. (Compiling Windows executable in Linux using x86_64-w64-mingw32-g++) by removing printer support as I definitely don't need it in 2025.

So I compiled 1.4.4 with CMake using a custom toolchain file that uses x86_64-w64-mingw32-g++, and set FLTK_OPTION_PRINT_SUPPORT=OFF

$> cmake . -DCMAKE_TOOLCHAIN_FILE=mingw-toolchain.cmake -D FLTK_OPTION_PRINT_SUPPORT=OFF

My GUI builds and runs fine against the resulting library however I still have to link against -lwinspool or I get linker errors, even though I'm using nothing else that would require it.

Am I missing something? Thanks in advance.

[Greg Ercolano]

    Hmm, I'm not an expert on this subject, but looking at the README.CMake.txt about the FLTK_OPTION_PRINT_SUPPORT option, there is something  (underlined below) about only making sense for unix builds:

FLTK_OPTION_PRINT_SUPPORT - default ON
    When turned off, the Fl_Printer class does nothing and the
    Fl_PostScript_File_Device class cannot be used, but the FLTK library
    is somewhat smaller. This option makes sense only on the Unix/Linux
    platform or on macOS when FLTK_BACKEND_X11 is ON.

Other devs will probably chime in as to why that is, but I'm guessing there might be some dependency on winspool.h for e.g. rendering a canvas straight to PDF, or some such.

[Manolo]

Option FLTK_OPTION_PRINT_SUPPORT=OFF has an effect only under Linux/Unix where

it removes the source code of the PostScript driver. Other platforms, Windows included,

have full support for printing included in the OS, so there's virtually no cost in terms

of code size of print support in FLTK.