fltkhs
fltkhs copied to clipboard
deech
REPL is broken and possible fixes are undocumented
The documentation on running FLTKHS in a REPL is quite extensive: it consists of a title.
Naively running stack repl, stack ghci, stack exec -- ghci, stack exec -- cabal repl or any variants just creates opaque errors about missing libraries (libfltkc-dyn.so) and undefined symbols (Fl_Adjuster_New). The packaging tricks kill stack-less ways to run ghci. Normally this is a sign that something is missing in the .cabal file. In this case it's probably just some flag. But I have no idea what it could be. The general result is the same in bundled and unbundled builds, and it persists since I first took a look a few weeks ago. I am not certain if the missing parts changed in the meantime though.
All the type level trickery, lack of naming conventions, documentation-by-error-messages and the fact that types are spread all over the libraries seems to imply that these libraries were designed to be explored interactively. The downside is that it's almost impossible for a newcomer to get a grip on things without help by ghci. Therefore, this is an important part of the environment that should be documented.
Encountered in fltkhs-demos, fltkhs-fluid-demos, fltkhs-hello-world, and fltkhs on Debian 8 with stack 1.1.2, ghc 8.0.2, cabal-install 1.24.0.2.
That is an unfortunate doc bug. I know I had something, must have inadvertently deleted it in a commit. Sorry about that. I'll write something up and upload. Thanks for reporting!
For now with fltkhs-{fluid}-hello-world, you can do stack repl --flag fltkhs:bundled and run :main at the prompt to run the app. Unfortunately I'm having an issue with the REPL where closing the app doesn't dispose of the window, not sure why.
Mh. The error persists if I try it that way. That tells me two things:
- The main contribution of missing documentation was to make the distinction between different kinds of errors harder, but it may not have hidden anything vital
- There's probably something wrong with a dependency
The symbol in the error message seems to point to a missing fltkhs dependency. That's weird, because it even remains with the bundled flag. Either the "Fl" is a red herring and there's an additional system library I need or something goes wrong when setting up the bundled library. What's even weirder is that non-interactive builds work, but anything interactive fails. Because of that my gut tells me it's the latter of these possibilities, but I have no idea if the error is on my side or fltkhs'.
There is no way for me to start a ghci session while keeping the bundled flag, and without it :set -lfltkc-dyn fails. Which makes sense I guess. Sadly I have no idea how to debug this.
Could it be hurting that I have FLTK 1.3.4 installed on the system?
Unfortunately I can't seem to reproduce. If you installed FLTK using apt-get there's a chance it didn't build the libraries the right way, which is why the docs suggest going with the bundled build or compiling it yourself manually. Just for the sake of checking off that box can you try re-cloning either one of the skeletons in a fresh directory and doing stack repl --flag fltkhs:bundled?
Same result from fresh clones. Same thing with a fresh clone under a fresh user so that no old cabal- or stack-remains interfere. I didn't install FLTK through apt-get though, but from source. So now it's almost impossible to purge from the system because who knows where it has put all its parts.
I guess I'll try to purge and/or reinstall it later when I have some time. Maybe the build is broken or something. Oh, and I installed GHC from binaries, not through apt-get or stack, so maybe that has some non-standard flags set as well that interfere with linking or something.
If you do make uninstall in the fltk source folder it will remove the libraries and executables it installed.
I don't have access to Debian so I'll have to do a little more exploring to figure out what's going on. Thanks for the bug report!
My Windows 7 installation is also complaining about the shared library:
> runhaskell App
ghc.exe: addDLL: libfltkc-dyn (Win32 error 126): The specified module could not be found.
KateSmibConfig: <command line>: can't load .so/.DLL for: libfltkc-dyn.dll (addDLL: could not load DLL)
Same problem when using intero with visual studio code or emacs.
Could be the Windows shared library support.
Perhaps one way around this is to build/link the fltk C wrapper statically with the haskell library.
I've never actually used FLTKHS with runhaskell. Regarding intero, can you try a stack build --flag fltkhs:bundled in your app before starting it?
Currently I'm not able to build the bundled version, but don't think that will fix this: haskell shared libraries are not that well supported on Windows, and in case they were, we need *.dll, not the *.so which I see in the fltkhs build directory. To avoid the shared library dependency I was thinking the wrapper library could be a static library which links with the haskell fltkhs library.
To my knowledge it is statically linking. If stack build --flag fltkhs:bundled is no longer working for you then it's a regression bug and I'd like to fix it. Please open an issue with the version of GHC/Stack/Windows you're using and I'll do my best but bear in mind I don't have access to a Windows 7 only Windows 10.
I've found the issue with my build, the PATH was confusing my stack to use the wrong compilers. Clearing my PATH before calling stack build --flag fltkhs:bundled fixed it and no longer complains about the shared library.
On Windows 7 I've worked around the issue of the missing libfltkc-dyn.so. Windows doesn't use this extension but rather .dll, so in the build output of fltkhs I made a copy of this file but with a .dll extension and now Intero loads without warning.
@jputcu can you provide the ghc version? On ghc822 on a recent commit
https://github.com/deech/fltkhs/commit/6a6ff05d80b77b645fa288d4a0d23a4a422944e5
I get the same error with
nix-shell --pure
which cleans the environment (hides most environment variables, file paths etc). So, I think the problem is something missing more than something, but I don't know much about this stuff. I'll try cleaning / rerunning things again when I get home.
Also, do you know if only Fl_Adjuster_New is listed because it's first alphabetically and the linking short circuits, or if it's the only missing symbol.
Also, fwiw, I'm using non-bundled fltk-1.3.4 (not 1.3.4.1, I think) on Ubuntu. I can also build and run it and other depending packages.
Not sure about Nix but I was able to get the REPL working with I added the object-code flag.
Also FYI the Ubuntu version of FLTK just doesn't work right. This is why I added the bundled option, even on Linux I found that packages were either behind or not compiled correctly (eg. do not provide static libs or aren't compiled with OpenGL).
Please see the REPL docs for more info.
I use nix instead of apt on ubuntu, and nixpkgs unstable (the latest channel?) works well.
(btw, opengl links correctly on machine, so I've been able to test the build files, but doesn't run correctly (blank screen), due to some known ubuntu LTS14 bug. So hopefully I didn't miss anything wrt the opengl flag).
On Jan 23, 2018 5:39 PM, "deech" [email protected] wrote:
Not sure about Nix but I was able to get the REPL working with I added the object-code flag https://github.com/deech/fltkhs-hello-world/blob/master/.ghci#L1.
Also FYI the Ubuntu version of FLTK just doesn't work right. This is why I added the bundled option, even on Linux I found that packages were either behind or not compiled correctly (eg. do not provide static libs or aren't compiled with OpenGL).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/deech/fltkhs/issues/63#issuecomment-359991917, or mute the thread https://github.com/notifications/unsubscribe-auth/ACNoMXc7P9V8_fkXp2wpTiSWC8LagmIRks5tNonNgaJpZM4OR6oV .
@sboosali: I'm using ghc-8.0.2 on Windows 7.
I think all these issues will be fixed by statically linking the c-wrapper library!
EDIT: Using the above-linked flags from https://github.com/deech/fltkhs-hello-world/blob/master/.ghci#L1 the repl now works for me.
I believe I'm seeing a similar problem. Ghci crashes with a symbol error on any executable more complex than the hello-world app [which works fine]. This is on Ubuntu 18.04.
uranium@Hex:~/projects/fltkhs-demos$ stack --version Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
uranium@Hex:~/projects/fltkhs-demos$ git reflog a8c52cb (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: clone: from https://github.com/deech/fltkhs-demos.git
uranium@Hex:~/projects/fltkhs-demos$ stack build --flag fltkhs:bundled
Warning: Cabal file warning in /home/uranium/projects/fltkhs-demos/fltkhs-demos.cabal@ 377:3: Unknown field: "extra-source-files" uranium@Hex:~/projects/fltkhs-demos$ stack ghci fltkhs-demos:exe:fltkhs-arc --flag fltkhs:bundled
Warning: Cabal file warning in /home/uranium/projects/fltkhs-demos/fltkhs-demos.cabal@ 377:3: Unknown field: "extra-source-files" Using main module: 1. Package `fltkhs-demos' component exe:fltkhs-arc with main-is file: /home/uranium/projects/fltkhs-demos/src/Examples/arc.hs The following GHC options are incompatible with GHCi and have not been passed to it: -threaded Configuring GHCi with the following packages: fltkhs-demos GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/uranium/projects/fltkhs-demos/src/Examples/arc.hs, interpreted ) Ok, one module loaded. Loaded GHCi configuration from /tmp/haskell-stack-ghci/9eb6573d/ghci-script *Main> :main /home/uranium/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/bin/ghc: symbol lookup error: /home/uranium/projects/fltkhs-demos/.stack-work/install/x86_64-linux/lts-12.12/8.4.3/lib/x86_64-linux-ghc-8.4.3/libHSfltkhs-0.7.0.0-8BkUMqgnQ0PDZzznxgBtad-ghc8.4.3.so: undefined symbol: Fl_Window_default_virtual_funcs
