Opened 3 years ago

Closed 3 months ago

#7103 closed bug (duplicate)

Compiler panic, when loading wxc in GHCi

Reported by: Henk-Jan Owned by:
Priority: normal Milestone: 7.10.1
Component: GHCi Version: 7.4.2
Keywords: Cc: hvr
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: GHCi crash Test Case:
Blocked By: Blocking:
Related Tickets: #9907, #10051, #7056, #8546 Differential Revisions:

Description (last modified by igloo)

Loading package wxc-0.90.0.4 ... <interactive>: Unknown PEi386 section name `.idata$4' (while processing: C:\Programs\wxWidgets-2.9.3\lib\gcc_dll\libwxmsw29u_xrc.a)
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.4.2 for i386-unknown-mingw32):
        loadArchive "C:\\Programs\\wxWidgets-2.9.3\\lib\\gcc_dll\\libwxmsw29u_xrc.a": failed

Attachments (1)

libwxmsw29u_xrc.7z (15.6 KB) - added by Henk-Jan 3 years ago.
A zipped (7zip) version of the offending .a file

Download all attachments as: .zip

Change History (15)

Changed 3 years ago by Henk-Jan

A zipped (7zip) version of the offending .a file

comment:1 Changed 3 years ago by Henk-Jan

The same happens with GHC version 7.6.1 for i386-unknown-mingw32

comment:2 Changed 3 years ago by simonmar

  • difficulty set to Unknown

See also #7056 (slightly different error, the section is .drectve).

Perhaps we should just ignore unrecognised sections?

comment:3 Changed 3 years ago by simonmar

  • Component changed from Compiler to GHCi
  • Milestone set to 7.6.2
  • Priority changed from normal to high

comment:4 Changed 3 years ago by igloo

  • Description modified (diff)

comment:5 Changed 3 years ago by igloo

  • Blocked By 3658 added

This would be fixed by dynamic-by-default.

comment:6 Changed 11 months ago by Henk-Jan

  • Cc hvr added

The problem still exists with GHC 7.8.2, compiled with DYNAMIC_GHC_PROGRAMS=YES. This is tested on Windows 8.1 (64-bit)

comment:7 Changed 11 months ago by thoughtpolice

  • Priority changed from high to normal

Lowering priority (these tickets are assigned to older versions, so they're getting bumped as they've been around for a while).

comment:8 Changed 11 months ago by thoughtpolice

  • Milestone changed from 7.6.2 to 7.10.1

Moving to 7.10.1.

comment:9 Changed 8 months ago by razvan.panda

Confirming bug on GHC 7.8.3 (Haskell Platform) Windows 8.1 64 bit:

Loading package network-2.6.0.2 ... ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.8.3 for x86_64-unknown-mingw32):
        loadArchive "c:/Program Files/Haskell Platform/2014.2.0.0/mingw/x86_64-w64-mingw32/lib\\libws2_32.a": failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

ghc.exe: Unknown PEi386 section name `.idata$4' (while processing: c:/Program Files/Haskell Platform/2014.2.0.0/mingw/x86_64-w64-mingw32/lib\libws2_32.a)
cabal.exe: Error: some packages failed to install:
persistent-1.3.3 failed during the building phase. The exception was:
ExitFailure 1
persistent-template-1.3.2.2 depends on persistent-1.3.3 which failed to
install.
yesod-form-1.3.16 depends on persistent-1.3.3 which failed to install.
yesod-markdown-0.9.2 depends on persistent-1.3.3 which failed to install.
yesod-persistent-1.2.3.1 depends on persistent-1.3.3 which failed to install.

comment:10 Changed 5 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:11 Changed 4 months ago by rwbarton

comment:12 Changed 4 months ago by darthdeus

I ran into the same thing while trying to get the mysql package working, where after many changes I was able to get the package to successfully compile on its own, but while linking with a larger application this error essentially killed the deployment, since there doesn't seem to be a way to work around it.

Removing the idata$4 section with --no-idata4 yielded the same error with idata$5, so we tried removing that with --no-idata5, but then ran into the same issue with idata$7.

ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of imp_inet_ntoa
ghc.exe: warning: getnameinfo from ws2_32 is linked instead of
imp_getnameinfo
ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of imp_getaddrinfo
ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of
imp_freeaddrinfo
ghc.exe: warning: accept from ws2_32 is linked instead of imp_accept
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of
imp_WSACleanup
ghc.exe: warning: WSAStartup from ws2_32 is linked instead of imp_WSAStartup
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of
imp_WSACleanup
ghc.exe: Unknown PEi386 section name `.idata$7' (while processing: C:\Haskell\ert\.cabal-sandbox\x86_64-windows- 7\libmysql.a)
cabal: Error: some packages failed to install:

We also tried modifying dlltool to remove the idata$7 section as well (source https://sourceware.org/git/?p=binutils.git;a=blob;f=binutils/dlltool.c), but without any success.

comment:13 Changed 3 months ago by Austin Seipp <austin@…>

In a293925d810229fbea77d95f2b3068e78f8380cc/ghc:

rts/linker: ignore unknown PE sections

Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed.

Test Plan:
See the file `ghcilinkerbug.zip` in #9907.

 1) unzip file content.
 2) open examplecpp.cabal and change base <4.8 to <4.9.
 3) execute cabal file with cabal repl.

Applying the patch makes `cabal repl` in step 3) work.

Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99.

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #9907, #7103, #10051, #7056, #8546

comment:14 Changed 3 months ago by thoughtpolice

  • Blocked By 3658 removed
  • Milestone changed from 7.12.1 to 7.10.1
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #9907, which will be merged to 7.10.1.

Note: See TracTickets for help on using tickets.