Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#9524 closed bug (fixed)

GHC uses wrong linker when cross compiling

Reported by: Kritzefitz Owned by: rwbarton
Priority: normal Milestone: 8.0.1
Component: Build System Version: 7.8.4
Keywords: Cross compiling Cc:
Operating System: Linux Architecture: x86
Type of failure: Building GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Greetings,

I tried to compile a cross compiler for x86_64-w64-mingw32. Most of GHC compiles fine. However, after a while there's an error that ld can't find a reference to "GetModuleFileNameW". I tried compiling a dummy C program with that symbol and it compiles fine. My guess is that GHC is using the wrong linker during cross-compiling, whereas GCC uses the right one. But I may be totally wrong, so please don't rely on that judgement. The log of the make run is attached.

Regards Sven

Attachments (4)

make.log (3.2 KB) - added by Kritzefitz 3 years ago.
threadfail.log (5.1 KB) - added by Kritzefitz 3 years ago.
0001-Fix-cross-compiling-from-Linux-to-Windows.patch (1.5 KB) - added by erikd 3 years ago.
Potential fix for cross-compiling to windows.
0001-Fix-cross-compiling-from-Linux-to-Windows-Closes-952.patch (864 bytes) - added by erikd 3 years ago.
Updated fix as suggested by @rwbarton

Download all attachments as: .zip

Change History (20)

Changed 3 years ago by Kritzefitz

Attachment: make.log added

comment:1 Changed 3 years ago by Kritzefitz

Architecture: Unknown/Multiplex86
Component: Compiler (FFI)Build System
Keywords: Cross compiling added
Operating System: Unknown/MultipleLinux

comment:2 Changed 3 years ago by rwbarton

Owner: set to rwbarton

It's not that GHC is using the wrong linker, it's that GHC built the wrong code: this hsc2hs is supposed to run on your host system which is Linux (you can tell because it is being built by /usr/bin/ghc, which is not a cross-compiler), so it should not be calling GetModuleFileNameW.

comment:3 Changed 3 years ago by Kritzefitz

Version: 7.8.37.8.4

That makes sense. Thanks for clarification, I just reproduced this with GHC 7.8.4 and had the same result.

Last edited 3 years ago by Kritzefitz (previous) (diff)

comment:4 Changed 3 years ago by rwbarton

I suspect the fix is just to delete the first three non-comment lines of hsc2hs's Main.hs, but my GHC HEAD cross-compiling setup is failing for an unrelated reason so I can't test it right now.

comment:5 Changed 3 years ago by Kritzefitz

I tested it (with 7.8.4) and the problem with GetModuleFileNameW went away. It's now failing with the failure message that threads aren't supported. Is this related or should I open another ticket?

Changed 3 years ago by Kritzefitz

Attachment: threadfail.log added

comment:6 Changed 3 years ago by rwbarton

It looks like a different bug (probably of the same type) so please open another ticket, thanks.

comment:7 Changed 3 years ago by Kritzefitz

done: #9932

comment:8 Changed 3 years ago by erikd

Working on a patch for this. Have actually made is past the hsc2hs part, but don't have a complete build yet.

@rwbarton : Mind if I steal this ticket ?

comment:9 Changed 3 years ago by erikd

The problem was that the hsc2hs code has a number of code blocks wrapped in:

#if defined(mingw_HOST_OS)

and mingw_HOST_OS is defined when cross compiling from Linux/OSX to Windows.

If I change the above to:

#if (defined(mingw32_HOST_OS) && HostPlatform_TYPE == mingw32_HOST_OS)

the cross-compile process proceeds past this issue and runs into other issues later in the compile process.

I don't have a Windows machine to test that this doesn't break MinGW native builds but the above certainly seems sensible.

Version 0, edited 3 years ago by erikd (next)

Changed 3 years ago by erikd

Potential fix for cross-compiling to windows.

comment:10 Changed 3 years ago by rwbarton

Oh, I was going to batch this with some other hsc2hs fixes, and then I got sidetracked.

I think the fix of simply removing the #include "../../includes/ghcconfig.h" is better though. #including that file in a Haskell program is risky business, since the foo_HOST_OS CPP symbol it defines is in the same namespace as the bar_HOST_OS CPP symbol that is automatically defined by any run of GHC. For example, in the case under discussion here, both linux_HOST_OS and mingw_HOST_OS are defined since hsc2hs is being built with the bootstrap compiler.

There should be no need for hsc2hs to know about the eventual target machine type, only the machine type that it is being built to run on. Or in other words, it is sensible to build hsc2hs independently of the GHC build process. So, let's just remove that #include to ensure that we only get the right versions of the foo_HOST_OS symbols, the ones that come from whatever GHC is building hsc2hs, and which are correct for the machine hsc2hs is to run on.

comment:11 Changed 3 years ago by erikd

Status: newpatch

comment:12 Changed 3 years ago by rwbarton

Yep, looks good to me.

Changed 3 years ago by erikd

Updated fix as suggested by @rwbarton

comment:13 Changed 3 years ago by erikd

Status: patchmerge

comment:14 Changed 3 years ago by Austin Seipp <austin@…>

In 2aef3205115b88be8c068739c136eadc8c07e886/ghc:

hsc2hs: update submodule

This includes the fix for #9524.

Signed-off-by: Austin Seipp <austin@well-typed.com>

comment:15 Changed 3 years ago by thoughtpolice

Milestone: 7.12.1
Resolution: fixed
Status: mergeclosed

Merged, thanks Eric!

comment:16 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

Note: See TracTickets for help on using tickets.