#13818: ANN pragmas can cause compilation to fail if .dyn_o unavailable -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -1,2 +1,5 @@ - A Haskell source file with an ANN pragma will fail to compile with -static - if any packages do not have dynamic libraries installed. + An annotation pragma is similar to template haskell in that type-checking + it necessitates loading code into ghci. This means that if any package + dependency does not have a ghci library available, or if the annotation + payload's type is defined in a module that does not have a .dyn_o + available, then type-checking will fail. @@ -4,1 +7,8 @@ - Reproduction: + This problem manifests when compiling with -fno-code as .dyn_o files are + not usually generated. -fno-code does enable object file generation for + modules needed by template haskell(in --make mode), however this same + approach cannot be easily extended to annotations because there is no + annotations language extension. + + Here is a reproduction of the missing dynamic library issue: + @@ -20,2 +30,0 @@ - Presumably the ANN pragma causes ghci to load with all libraries which - must be dynamic. @@ -23,1 +31,10 @@ - Not sure which category is correct for Type of failure. + Note that this fails even though no module of the dependency is imported. + This is especially vexing since, to my knowledge, most annotations in + libraries are simple strings for HLint, which could easily be typechecked + if ghci didn't try to load libraries it didn't need.. + + I suggest the following fixes: + * Do not fail typechecking if an annotation fails in ghci, instead issue a + warning. Possibly suppress this warning by default in -fno-code + * Load libraries in ghci more lazily, or don't bail out in ghci until a + missing library is needed,. New description: An annotation pragma is similar to template haskell in that type-checking it necessitates loading code into ghci. This means that if any package dependency does not have a ghci library available, or if the annotation payload's type is defined in a module that does not have a .dyn_o available, then type-checking will fail. This problem manifests when compiling with -fno-code as .dyn_o files are not usually generated. -fno-code does enable object file generation for modules needed by template haskell(in --make mode), however this same approach cannot be easily extended to annotations because there is no annotations language extension. Here is a reproduction of the missing dynamic library issue: {{{ $ echo "module Bug where {-# ANN module \"just a string\" #-}" > Bug.hs $ cabal sandbox init $ cabal install transformers-compat --disable-shared $ ghc -static -package db ./.cabal-sandbox/x86_64-linux- ghc-8.2.0.20170522-packages.conf.d -package transformers-compat -c Bug.hs <command line>: can't load .so/.DLL for: libHStransformers- compat-0.5.1.4-DQiwI4tzfvoKHf8rERr8Q2.so (libHStransformers- compat-0.5.1.4-DQiwI4tzfvoKHf8rERr8Q2.so: cannot open shared object file: No such file or directory) $ cabal install transformers-compat --enable-shared --reinstall $ ghc -static -package db ./.cabal-sandbox/x86_64-linux- ghc-8.2.0.20170522-packages.conf.d -package transformers-compat -c Bug.hs -fforce-recomp }}} Note that this fails even though no module of the dependency is imported. This is especially vexing since, to my knowledge, most annotations in libraries are simple strings for HLint, which could easily be typechecked if ghci didn't try to load libraries it didn't need.. I suggest the following fixes: * Do not fail typechecking if an annotation fails in ghci, instead issue a warning. Possibly suppress this warning by default in -fno-code * Load libraries in ghci more lazily, or don't bail out in ghci until a missing library is needed,. -- Comment (by duog): Reword and generalize to include problems with -fno-code. Let me know if my solutions sound reasonable, I am happy to fix this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13818#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler