On Windows FLTKHS tries to link against fltk_png, fltk_jpeg and fltk_z even if they do not exist. about fltkhs

[darkf]

What is the correct way to handle this? Is linking against fltk_z/fltk_png not necessary on Windows, or does it need to be built specially?

[deech]

FLTK builds fltk_z, fltk_jpeg and fltk_png if it can't find lzlib, ljpeg, and lpng. If you already have those libs, they are not built and you get linker errors until I fix this you can probably just delete any mentions of the former from CMakeLists.txt and try rebuilding.

Also I'm a CMake noob so if you know how to change https://github.com/deech/fltkhs/blob/master/CMakeLists.txt#L5 to conditionally include those libs I'd be more than happy to take a patch.

[deech]

I think I fixed it. Would you mind trying out this branch? https://github.com/deech/fltkhs/tree/LinkErrorFix

[darkf]

That fixes the _z/_png linker errors.

I also get these errors when building the executables shipping with fltkhs (via stack build):

Setup.hs: Unknown build target 'exe:fltkhs-arc'.
There is no executable component 'fltkhs-arc'.
Unknown build target 'exe:fltkhs-bitmap'.
There is no executable component 'fltkhs-bitmap'.
[...]

This is a separate issue, and might be an issue with Stack, but nonetheless it causes the build to fail. The library itself builds correctly.

Now, I have a problem building my own version of fltk-simple. After adding

  ghc-Options: -Wall -threaded -fcontext-stack=220  -pgml g++ "-optl-Wl,--whole-archive" "-optl-Wl,-Bstatic" "-optl-Wl,-L.,-lfltkc" "-optl-Wl,-Bdynamic" "-optl-Wl,--no-whole-archive"

to the .cabal file (note the addition of the -L. linker flag, I had to copy lib/libfltkc.a in order for it to find it. Is it not supposed to locate and link it automatically?), I am left with:

    Linking .stack-work\dist\i386-windows\Cabal-1.22.4.0\build\fltk-test\fltk-test.exe ...
    c:/users/bak/appdata/local/programs/stack/i386-windows/ghc-7.10.2/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe: C:/fltk/lib/libfltk.a(Fl_Browser.cxx.obj): warning: duplicate section `.rdata$_ZTV16Fl_Multi_Browser[vtable for Fl_Multi_Browser]' has different size

    c:/users/bak/appdata/local/programs/stack/i386-windows/ghc-7.10.2/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe: C:/fltk/lib/libfltk.a(Fl_Input.cxx.obj): warning: duplicate section `.rdata$_ZTV12Fl_Int_Input[vtable for Fl_Int_Input]' has different size

    C:/fltk/lib/libfltk.a(Fl_Valuator.cxx.obj):Fl_Valuator.cxx:(.text$snprintf[_snprintf]+0x29): undefined reference to `__ms_vsnprintf'
    C:/fltk/lib/libfltk.a(fl_ask.cxx.obj):fl_ask.cxx:(.text$vsnprintf[_vsnprintf]+0x22): undefined reference to `__ms_vsnprintf'
    C:/fltk/lib/libfltk.a(Fl_File_Browser.cxx.obj):Fl_File_Browser.cxx:(.text+0x12e): undefined reference to `__chkstk_ms'
    C:/fltk/lib/libfltk.a(Fl_File_Browser.cxx.obj):Fl_File_Browser.cxx:(.text+0x493): undefined reference to `__chkstk_ms'
    C:/fltk/lib/libfltk.a(Fl_File_Browser.cxx.obj):Fl_File_Browser.cxx:(.text+0xa3f): undefined reference to `__chkstk_ms'
    C:/fltk/lib/libfltk.a(Fl_File_Chooser2.cxx.obj):Fl_File_Chooser2.cxx:(.text+0x324): undefined reference to `__chkstk_ms'
    C:/fltk/lib/libfltk.a(Fl_File_Chooser2.cxx.obj):Fl_File_Chooser2.cxx:(.text+0x1100): undefined reference to `__chkstk_ms'
    C:/fltk/lib/libfltk.a(Fl_File_Chooser2.cxx.obj):Fl_File_Chooser2.cxx:(.text+0x255b): more undefined references to `__chkstk_ms' follow
    collect2: ld returned 1 exit status

which I take to mean it's linking against an MSVC/CRT ABI library.

[deech]

Yes unfortunately stack isn't supported at the moment. The project was started well before stack came along and I haven't had time to migrate. cabal install is currently the smoothest route to a clean install.

I also notice you have -fcontext-stack set to 220. This version of the library has it bumped to 300 so please make sure you're using 0.2.0.1.

I don't know enough about Windows to understand the second set of errors but it sounds like you just want to build the library using Stack without any of the executables. I was able to do this by commenting out all the Executable sections in the Cabal file and doing stack build. Please note that unfortunately this means that fltkhs-fluidtohs the preprocessor that converts the Fluid GUI builder files into Haskell modules will not be built and installed so Fluid integration just won't work.

To summarize:
(1) I hope to have full stack support sometime soon but for now cabal install is the best way.
(2) If you just want to build the library just comment out the Executable sections in the .cabal file and stack build but then you won't have Fluid integration.

[deech]

Since the linker issues are resolved can I close this issue?

[darkf]

Yes, feel free, this should be solved now.

[deech]

Uploaded fix to Hackage http://hackage.haskell.org/package/fltkhs.