fltkhs
fltkhs copied to clipboard
deech
Why not use the fltk-1.3.4 library that comes with MSYS2?
The install instructions for Windows build fltk from source in a MSYS2 environment, why not use the package that is already present?
$ pacman -Ss fltk
mingw32/mingw-w64-i686-fltk 1.3.4-1
C++ user interface toolkit (mingw-w64)
mingw64/mingw-w64-x86_64-fltk 1.3.4-1
C++ user interface toolkit (mingw-w64)
The reason I'm recommending building from scratch using ./configure --enable-gl --enable-shared --enable-localjpeg --enable-localzlib --enable-localpng is to make sure:
- GL support is enabled
- both the shared and static versions of the libraries are built (I've found Pacman is a little flaky in this regard)
- use the FLTK bundled
zlib,jpegandpng. Without this the executables potentially have dependencies on the shared versions of these libs.
Could we perhaps make this the default to have the smallest number of steps to setup fltkhs on Windows? Also providing a more advanced option (cabal flags?) to use the library build from scratch. I'm for the moment only able to run my build applications in MSYS2 due to all dlls (mgwfltknox_forms-1.3, mgwfltknox_gl-1.3, mgwfltknox_images-1.3, mgwfltknox-1.3 and libstdc++-6). Some time ago I was able to build fltkhs applications with no dependencies, all static linked.
Are you proposing that we should bundle FLTK and having Cabal run the configure ...; make; make install step?
We could add pacman -S fltk... to the Windows installation step and use the fltk-config which is available at build time. Even if the library was build from scratch with other options, the fltk-config should provide the correct compiler options.
If you look in configure.ac I do use fltk-config to populate the compiler options. But how does pacman -S fltk resolve the issue of having minimal runtime dependencies? It seems like from the above snippet your executables are dependent on the shared DLLs which were presumably installed by pacman. From my testing using the configure ... command (vs. the package manager) above ensures that both the static and shared versions of all FLTK libs are built ensuring that executables are dependent on as little as possible.
I also like having as little runtime dependencies as possible, but even your current fltkhs-buttons.exe depends on 5 dlls (mgwfltknox... and libstdc++).
Suggest we close this discussion here and I try to use git branches to test some stuff and let you try my experiments.
Would love those see this package become popular by making it easy to install for everybody.
Thanks for the effort.
Oh wow, I just checked and you're right about the dependencies. I must have totally missed those. I wonder why it's not picking up on the static versions of those libs; they're definitely there. I'll look into it. Thanks for the feedback.
I just pushed a fix that (hopefully) removes those runtime FLTK dependencies. Unfortunately now the GHCi REPL doesn't work on Windows but I feel this is more important. Please test at your convenience.
Yes and I have no idea how to get rid of that. See the section on "Packaging A Windows Executable" here http://hackage.haskell.org/package/fltkhs-0.5.0.8/docs/Graphics-UI-FLTK-LowLevel-FLTKHS.html#g:8.
In previous version (which was using CMAKE) I was able to get rid of it using the following (don't know if it works):
SET(FLTKLINKFLAGS "${FLTKLINKFLAGS} -Wl,-Bstatic,-lstdc++,-lpthread,-Bdynamic")
In the application cabal:
-Wall -threaded -pgml g++ -static -optl-static-libstdc++
I did a brief experiment with this and got:
ld.exe: cannot find -lstdc++
ld.exe: cannot find -lpthread
Let me know if you come up with anything better. Thanks for your efforts on Windows. I definitely don't know it as well as Linux.
I did a little more research last night on libstdc++ and folks are recommending not linking that statically if the codebase uses dlopen. FLTK does use it in a number of places. Since you know more about this than I do, what do you think?