Opened 10 years ago

Closed 9 years ago

#3798 closed bug (duplicate)

Problem with wxHaskell

Reported by: MNorrish Owned by:
Priority: low Milestone: 7.2.1
Component: GHCi Version: 7.0.3
Keywords: Cc:
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Other Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by igloo)

Hello.hs is a GUI hello world program I copied and pasted off I have wxHaskell and ghc, and my attempt to compile it gives

mark@mark-laptop:~/MyCode$ ghc -package wx Hello.hs -o bin
Binary: Int64 truncated to fit in 32 bit Int
ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.4 for i386-unknown-linux):
	Prelude.chr: bad argument

Meanwhile, running it off ghci gives a series of successfully linked and loaded packages, terminating with

Loading package wxdirect- ... linking ... done.
Loading package wxcore- ... <command line>: can't load .so/.DLL for: stdc++ ( cannot open shared object file: No such file or directory)

(I put type of failure as other because it's a GHC panic and a GHCi failure and probably some other sort of bug too.)

Change History (10)

comment:1 Changed 10 years ago by igloo

Description: modified (diff)

comment:2 Changed 10 years ago by igloo

Milestone: 6.12.2

Thanks for the report.

I think this is the program:

module Main where

import Graphics.UI.WX

main :: IO ()
main = start gui

gui :: IO ()
gui = do
  frame [text := "Hello World!"]
  return ()

comment:3 Changed 10 years ago by simonmar

Component: CompilerGHCi

The Prelude.chr: bad argument error is caused by GHC finding a .hi file that it didn't understand, perhaps created on a different machine. This bug is already fixed in GHC 6.12.1 (GHC ignores the unrecognised .hi file, as it should).

On my system, is found in /usr/lib/gcc/i486-linux-gnu/4.4.1, but it is a symlink to to .so.6 in /usr/lib. If you add that directory to the extra-libs of the wxcore package, it loads in GHCi (although there's another missing symbol error later). dlopen doesn't look here by default, as this directory is intended to be searched at link-time, not load-time. If you want to dlopen libstdc++, I guess you're supposed to either dlopen("") or use the full path name.

One possible plan here is to have GHCi call gcc -print-search-dirs, and pick out its library search paths. We could easily add those to the places we look for .sos.

comment:4 Changed 10 years ago by igloo


comment:5 Changed 10 years ago by igloo

Priority: normallow

comment:6 Changed 9 years ago by igloo


comment:7 Changed 9 years ago by freizl


I got same problem at GHC 6.12.1, platform LinuxMint 9. Any work around?

ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1

DISTRIB_DESCRIPTION="Linux Mint 9 Isadora"

comment:8 Changed 9 years ago by igloo


comment:9 Changed 9 years ago by prouxel

Operating System: LinuxWindows

I got the same problem with the platform 2011.2.0.1 on windows 7

comment:10 Changed 9 years ago by simonmar

Resolution: duplicate
Status: newclosed

Closing this one in favour of #5289

Note: See TracTickets for help on using tickets.