#15894 closed bug (fixed)

Cannot find symbol during interactive linking using new-repl on Windows

Reported by: YellPika Owned by:
Priority: normal Milestone: 8.6.3
Component: Compiler Version: 8.6.2
Keywords: Cc: Phyx-
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Other Test Case: T15894
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D5353
Wiki Page:


Originally from https://github.com/haskell/cabal/issues/5683.

I get the following error on Windows 10:

> cabal new-repl --build-depends=ieee754

... GHCi loads ...

Prelude> import Numeric.IEEE
Prelude Numeric.IEEE> infinity
ghc.exe:  | C:\Users\Anthony\AppData\Roaming\cabal\store\ghc-8.6.2\ieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266\lib\libHSieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266.a: unknown symbol `copysign'
ghc.exe: ^^ Could not load 'ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure', dependency unresolved. See top entry above.

During interactive linking, GHCi couldn't find the following symbol:
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:

This occurs with both cabal-install and HEAD. This does not occur if I install ieee754 into a sandbox and use cabal repl. It also works correctly on Ubuntu 18.04 (on both WSL and a full installation), so it looks like a Windows-specific problem.

Change History (4)

comment:1 Changed 13 months ago by Phyx-

Architecture: x86_64 (amd64)Unknown/Multiple
Differential Rev(s): Phab:D5353
Status: newpatch
Test Case: T15894

comment:2 Changed 12 months ago by Tamar Christina <tamar@…>

In a8b7cef4/ghc:

linker: store entire link map and use it.

This fixes a corner case in which we have seen the symbol multiple times in
different static libraries, but due to a depencency we end up loading the
symbol from a library other than the first one.

Previously the runtime linker would only track symbols from the first
library and did not store the full link map.  In this case it was unable
to find the address for the symbols in the second library during delay

This change stores the address of all symbols seen so a full link map
is generated, such that when we make a different decision later than what
was expected we're able to still correctly load the library.

Test Plan: ./validate, new testcase T15894

Reviewers: angerman, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15894

Differential Revision: https://phabricator.haskell.org/D5353

comment:3 Changed 12 months ago by Phyx-

Status: patchmerge

comment:4 Changed 12 months ago by bgamari

Resolution: fixed
Status: mergeclosed
Note: See TracTickets for help on using tickets.