[GHC] #13845: Runtime linker too eagerly checks for symbol names

#13845: Runtime linker too eagerly checks for symbol names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I discovered this bug in https://github.com/haskell- foundation/foundation/issues/326. Take this file: {{{#!hs module Main (main) where foreign import ccall "notAThing" notAThing :: IO () main :: IO () main = putStrLn "Hello, World!" }}} Compiling and running this file works without issue. But if you try to use the runtime linker, things go haywire: {{{ $ C:\Users\RyanGlScott\Software\ghc\inplace\bin\runghc Bug.hs ghc-stage2.exe: ^^ Could not load 'notAThing', dependency unresolved. See top entry above. Bug.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: notAThing This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org }}} This isn't just limited to Windows, since the same thing happens on Linux. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13845 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13845: Runtime linker too eagerly checks for symbol names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As Phyx- notes, this is actually somewhat expected behavior. The reason this happens in `runghc` and not with compiled code is because interpreted mode loads //all// top-level definitions (even those that are not exported). This is a handy feature to have when tinkering around with code in GHCi, but it does mean that you'll need to load all the symbols being used, which results in the linker error. A "workaround" is to use `runghc` with the `-fobject-code` flag, i.e., `runghc --ghc-arg=-fobject-code Bug.hs`. Of course, this somewhat defeats the purpose of using `runghc` in the first place, but thems the breaks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13845#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13845: Runtime linker too eagerly checks for symbol names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Indeed, you can also work around this by using `-fobject-code`, which does //not// load all top-level definitions. {{{ $ runghc --ghc-arg=-fobject-code Bug.hs Hello, World! }}} In short, this isn't a real bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13845#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC