Opened 3 years ago

Closed 5 weeks ago

#7056 closed bug (duplicate)

Relax static-PE linker object checks

Reported by: songpp Owned by: thoughtpolice
Priority: normal Milestone: 7.10.1
Component: GHCi Version: 7.4.1
Keywords: loadArchive Unknown PEi386 Cc: sun.april.moon@…, jonas.fager@…, mikesteele81@…, nightski@…, hvr
Operating System: Windows Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #9907, #2487, #7103, #7889, #8546 Differential Revisions:

Description (last modified by simonmar)

cygwin 1.7

$ iconv --version
iconv (GNU libiconv 1.14)

E:/Develop/haskell/conv.hs :

import Codec.Text.IConv as IConv
import Data.ByteString.Lazy as ByteString

main :: IO ()
main = ByteString.interact (convert "UTF-8" "GBK")        

then

GHCi, version 7.4.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :load "e:/Develop/haskell/conv.hs"
[1 of 1] Compiling Main             ( E:\Develop\haskell\conv.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package iconv-0.4.1.0 ... ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for i386-unknown-mingw32):
	loadArchive "d:/cygwin/lib\\libiconv.a": failed

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

*Main> Leaving GHCi.
<interactive>: Unknown PEi386 section name `.drectve' (while processing: d:/cygwin/lib\libiconv.a)

Attachments (1)

20120707132609.png (84.2 KB) - added by songpp 3 years ago.
SORRY FOR THE TEXT FORMAT

Download all attachments as: .zip

Change History (28)

Changed 3 years ago by songpp

SORRY FOR THE TEXT FORMAT

comment:1 Changed 3 years ago by songpp

  • Cc sun.april.moon@… added

comment:2 Changed 3 years ago by jonke

  • Cc jonas.fager@… added

Loading package nano-md5-0.1.2 ... <interactive>: Unknown PEi386 section name `.drectve' (while processing: C:\openssl\lib\libcrypto.a)
ghc.exe: panic! (the 'impossible' happened)

(GHC version 7.4.1 for i386-unknown-mingw32):

loadArchive "C:
openssl
lib
libcrypto.a": failed

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

with openssl from http://gnuwin32.sourceforge.net/packages/openssl.htm

comment:3 Changed 3 years ago by simonmar

  • difficulty set to Unknown
  • Milestone set to 7.6.2
  • Priority changed from normal to high

See also #7103.

comment:4 Changed 3 years ago by simonmar

  • Description modified (diff)

comment:5 Changed 3 years ago by msieradzki

It also shows up (but with different unknown section) when linking with code built with gcc-4.7.0 on mingw.

comment:6 Changed 2 years ago by igloo

  • Blocked By 3658 added

This would be fixed by dynamic-by-default.

comment:7 Changed 2 years ago by batterseapower

Experienced this with Mingw GCC 4.7.2 on Windows 7 when building GHC:

"inplace/bin/ghc-stage2.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O    -package-name vector-0.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal   -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -package primitive-0.4.0.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2  -no-user-package-db -rtsopts      -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build  -dynamic-too -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o -dyno libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.dyn_o
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... ghc-stage2.exe: panic! (the 'impossible' happened)
  (GHC version 7.7.20130413 for i386-unknown-mingw32):
        loadArchive "C:\\MinGW\\msys\\1.0\\home\\Max\\Programming\\ghc\\libraries\\integer-gmp\\dist-install\\build\\libHSinteger-gmp-0.5.1.0.a": failed

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

ghc-stage2.exe: Unknown PEi386 section name `.drectve' (while processing: C:\MinGW\msys\1.0\home\Max\Programming\ghc\libraries\integer-gmp\dist-install\build\libHSinteger-gmp-0.5.1.0.a)

comment:8 Changed 21 months ago by schyler

May be related. Building GHC with mingw gcc 4.8.0 and ghc 7.6.3 on Windows 8 yields:

Loading package integer-gmp ... ghc-stage2.exe: Unknown PEi386 section name `.dr
ectve' (while processing: C:\MinGW\msys\1.0\home\Kyle\ghc\libraries\integer-gmp\
dist-install\build\libHSinteger-gmp-0.5.1.0.a)
ghc-stage2.exe: panic! (the 'impossible' happened)
  (GHC version 7.7.20130711 for i386-unknown-mingw32):
        loadArchive "C:\\MinGW\\msys\\1.0\\home\\Kyle\\ghc\\libraries\\integer-g
mp\\dist-install\\build\\libHSinteger-gmp-0.5.1.0.a": failed

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

make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Mona
dic.o] Error 1
make: *** [all] Error 2
Last edited 21 months ago by schyler (previous) (diff)

comment:9 Changed 21 months ago by thoughtpolice

I looked into this. See http://msdn.microsoft.com/en-us/library/ms809762.aspx

The .drective section only appears in OBJ files. It contains text representations of commands for the linker. For example, in any OBJ I compile with the Microsoft compiler, the following strings appear in the .drectve section...

This is with Microsoft compilers. Presumably, MinGW or something is doing this now too? Some searching suggests ld generally doesn't understand the directives placed in .drectve, although maybe something changed or it puts something else there.

It's probably just best to ignore the section (a simple fix); I'll try to get GCC 4.8 on my Windows build machine and reproduce it.

comment:10 Changed 19 months ago by simonpj

Wait! The ghc-tarballs repo contains gcc for exactly this reason. The build system is supposed to use that, not any random gcc that comes with mingw. So why is it using the mingw one?

Simon

comment:11 Changed 19 months ago by msieradzki

In my case I manually modified GHC directory layout so that "mingw" points to recent mingw installation. It contained GCC 4.7. It's important if one wants to use C++ libraries built with more recent GCC.

As far as I know one can't mix code built with different GCC major versions so forcing use of GCC 4.5 isn't exactly the solution.

comment:12 Changed 19 months ago by thoughtpolice

  • Milestone changed from 7.6.2 to 7.8.1

Perhaps then we should simply upgrade the GCC release included in ghc-tarballs. I'm not sure if I will get to this before 7.8.1 (there's some cleanup on top of the fix for this that's needed,) although tenatively we can try.

comment:13 Changed 19 months ago by thoughtpolice

  • Owner set to thoughtpolice

comment:14 Changed 19 months ago by simonmar

We should probably just ignore section names that we don't understand. I think the linker is just being extra paranoid in making sure it understands the whole contents of the object file, but this breaks with pretty much every new gcc/binutils.

comment:15 Changed 19 months ago by simonmar

  • Priority changed from high to highest

comment:16 Changed 19 months ago by thoughtpolice

comment:17 Changed 19 months ago by Rothiph

  • Cc mikesteele81@… added

comment:18 Changed 19 months ago by Edward Z. Yang <ezyang@…>

In 24b791f9618e263d0a972be0ea4883d8f582d0fe/ghc:

Ignore drectve sections, partially fixing #7056

Signed-off-by: Edward Z. Yang <[email protected]>

comment:19 Changed 19 months ago by ezyang

  • Priority changed from highest to high

comment:20 Changed 17 months ago by nightski

  • Cc nightski@… hvr added

comment:21 Changed 17 months ago by ezyang

  • Blocking 8530 added

comment:22 Changed 16 months ago by 3noch

I just got this trying to load libHSpersistent-sqlite-1.2.1.a. Any idea when it will be solved?

comment:23 Changed 12 months ago by ezyang

3noch: The fix for drectve should have made it into GHC 7.8.2. This bug is still open because we ostensibly want to relax the Windows linker's object checks.

comment:24 Changed 11 months ago by thoughtpolice

  • Blocked By 3658 removed
  • Blocking 8530 removed
  • Milestone changed from 7.8.3 to 7.10.1
  • Priority changed from high to normal
  • Summary changed from GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' to Relax static-PE linker object checks
  • Type of failure changed from GHCi crash to None/Unknown

comment:25 Changed 3 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:26 Changed 5 weeks 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:27 Changed 5 weeks ago by thoughtpolice

  • 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.