#14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Phyx- notes that while there's no obvious workaround for this on GHC 8.2, there is on GHC HEAD, where you can manually specify: {{{ $ runghc -licuuc.dll.a Bug2.hs }}} In theory, this should be equivalent: {{{ $ runghc -llibicuuc.dll.a Bug2.hs }}} But in practice, GHC doesn't permit this, as there's a case missing in the runtime linker code. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14456#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.2.1 => 8.2.2 Old description:

First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2):

{{{ $ pacman -S mingw-w64-x86_64-icu }}}

Now take this file:

{{{#!hs module Main where

import Data.Int import Foreign

foreign import ccall "ucnv_getMaxCharSize_58" c_ucnv_getMaxCharSize :: Ptr () -> IO Int8

main :: IO () main = c_ucnv_getMaxCharSize nullPtr >>= print }}}

GHC is able to compile this successfully:

{{{ $ ghc -licuuc Bug2.hs [1 of 1] Compiling Main ( Bug2.hs, Bug2.o ) Linking Bug2.exe ... }}}

But GHCi is unable to accomplish the same thing:

{{{ $ runghc -licuuc Bug2.hs ghc.exe: ^^ Could not load 'ucnv_getMaxCharSize_58', dependency unresolved. See top entry above.

Bug2.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: ucnv_getMaxCharSize_58 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 }}}

Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue.

New description: First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2): {{{ $ pacman -S mingw-w64-x86_64-icu }}} Now take this file: {{{#!hs module Main where import Data.Int import Foreign import Foreign.C.String import Foreign.C.Types type UErrorCode = CInt u_ZERO_ERROR :: UErrorCode u_ZERO_ERROR = 0 foreign import ccall "ucnv_open_58" c_ucnv_open :: CString -> Ptr UErrorCode -> IO (Ptr ()) foreign import ccall "ucnv_getMaxCharSize_58" c_ucnv_getMaxCharSize :: Ptr () -> IO Int8 main :: IO () main = with u_ZERO_ERROR $ \status -> do conv <- c_ucnv_open nullPtr status c_ucnv_getMaxCharSize conv >>= print }}} GHC is able to compile this successfully: {{{ $ ghc -licuuc Bug2.hs [1 of 1] Compiling Main ( Bug2.hs, Bug2.o ) Linking Bug2.exe ... $ ./Bug2.exe 1 }}} But GHCi is unable to accomplish the same thing: {{{ $ runghc -licuuc Bug2.hs ghc.exe: | C:\Users\RyanGlScott\Documents\Hacking\Haskell\Bug2.o: unknown symbol `ucnv_open_58' Bug2.hs: }}} Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue. -- Comment: Ah yes, `-llibicuuc` does indeed work with GHC HEAD. Thanks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14456#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4274 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14456#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4274 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3d17f1f10fc00540ac052f2fd03182906aa47e35/ghc" 3d17f1f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3d17f1f10fc00540ac052f2fd03182906aa47e35" Tweak link order slightly to prefer user shared libs before system ones. We currently always prefer shared libraries before import libraries and static libraries. This is because they're faster to load. The problem is when shared library are installed in the Windows directory. These would supersede any user specified ones. This is bad because e.g. Windows now ships icuuc, but an old version. If you try to use -licuuc then it would pick the Windows one instead of your user specified one. This patch slighly tweaks the ordering so user paths get prefered. Test Plan: ./validate Reviewers: RyanGlScott, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14456 Differential Revision: https://phabricator.haskell.org/D4274 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14456#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler