I'm sure it's the runtime linker. Static linking is fine. The symbol is defined in Updates.cmm, and is there in Updates.o, and in ghc-stage2.exe | -----Original Message----- | From: Ben Gamari [mailto:ben@well-typed.com] | Sent: 27 October 2015 14:47 | To: Simon Peyton Jones; ghc-devs@haskell.org | Subject: Re: stg_upd_frame_info still broken | | Simon Peyton Jones writes: | | > Friends | > I still cannot build GHC on Windows. On Ben's advice I dumped my | > current msys setup and re-installed msys64 as described here | > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows | | I'm sorry to hear that updating msys2 didn't do the trick. I'm still trying | to reproduce this in the background. My previous builds were of the ghc-7.10 | branch so it's possible this regression was introduced into `master`. | | > I cloned an entirely new GHC repository. | > Then 'sh validate'. | > Same result as before: any attempt to run GHCi fails with an unresolved | symbol. | > | > bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive | > | > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ :? for help | > | > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0' | > | > ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist- | install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info' | > | > How could I actually find what the problem is? Trying random things | > and hoping the problem goes away clearly is not working. | > | I would first try to find the object file which is supposed to provide this | symbol and figure out whether the problem is one of the RTL (which is what I | would put my money on) or some part of the build toolchain. | | Cheers, | | - Ben

I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. Ah. That sounds very plausible Thanks S From: Reid Barton [mailto:rwbarton@gmail.com] Sent: 27 October 2015 14:57 To: Ben Gamari Cc: Simon Peyton Jones; ghc-devs@haskell.org Subject: Re: stg_upd_frame_info still broken On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari mailto:ben@well-typed.com> wrote: Simon Peyton Jones mailto:simonpj@microsoft.com> writes:

I cloned an entirely new GHC repository. Then 'sh validate'. Same result as before: any attempt to run GHCi fails with an unresolved symbol.

bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive

GHCi, version 7.11.20151026: http://www.haskell.org/ghc/https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce0433e9616f94207642908d2deded4ff%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=RYlwVuvgZKZDInxJ2iDfFNuxK0UX2FGcSeplXjv4Yg0%3d :? for help

ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0'

ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info'

How could I actually find what the problem is? Trying random things and hoping the problem goes away clearly is not working.

I would first try to find the object file which is supposed to provide this symbol and figure out whether the problem is one of the RTL (which is what I would put my money on) or some part of the build toolchain. I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the same problem I should be able to provide a quick fix. Regards, Reid Barton

I got lucky and found an error in the first place I looked. I have no way to test it, but I expect that https://phabricator.haskell.org/D1382 will fix the build on Windows, or at least make it closer to correct :) Regards, Reid On Tue, Oct 27, 2015 at 11:25 AM, Reid Barton wrote:

Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build on Linux did produce a working ghci, so I guess that leaves reviewing the likely culprit patch(es) very carefully...

Regards, Reid Barton

On Tue, Oct 27, 2015 at 10:57 AM, Simon Peyton Jones < simonpj@microsoft.com> wrote:

...

I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker.

Ah. That sounds very plausible Thanks

S

*From:* Reid Barton [mailto:rwbarton@gmail.com] *Sent:* 27 October 2015 14:57 *To:* Ben Gamari *Cc:* Simon Peyton Jones; ghc-devs@haskell.org *Subject:* Re: stg_upd_frame_info still broken

On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari wrote:

Simon Peyton Jones writes:

...

I cloned an entirely new GHC repository. Then 'sh validate'. Same result as before: any attempt to run GHCi fails with an unresolved symbol.

bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive

GHCi, version 7.11.20151026: http://www.haskell.org/ghc/ https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce0433e9616f94207642908d2deded4ff%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=RYlwVuvgZKZDInxJ2iDfFNuxK0UX2FGcSeplXjv4Yg0%3d :? for help

ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0'

ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info'

How could I actually find what the problem is? Trying random things and hoping the problem goes away clearly is not working.

I would first try to find the object file which is supposed to provide this symbol and figure out whether the problem is one of the RTL (which is what I would put my money on) or some part of the build toolchain.

I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker.

I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the same problem I should be able to provide a quick fix.

Regards,

Reid Barton

Well done Reid! That fixed it. Austin will commit it. Thanks for such timely help. You are a star Simon From: Reid Barton [mailto:rwbarton@gmail.com] Sent: 27 October 2015 15:54 To: Simon Peyton Jones Cc: Ben Gamari; ghc-devs@haskell.org Subject: Re: stg_upd_frame_info still broken I got lucky and found an error in the first place I looked. I have no way to test it, but I expect that https://phabricator.haskell.org/D1382 will fix the build on Windows, or at least make it closer to correct :) Regards, Reid On Tue, Oct 27, 2015 at 11:25 AM, Reid Barton mailto:rwbarton@gmail.com> wrote: Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build on Linux did produce a working ghci, so I guess that leaves reviewing the likely culprit patch(es) very carefully... Regards, Reid Barton On Tue, Oct 27, 2015 at 10:57 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. Ah. That sounds very plausible Thanks S From: Reid Barton [mailto:rwbarton@gmail.commailto:rwbarton@gmail.com] Sent: 27 October 2015 14:57 To: Ben Gamari Cc: Simon Peyton Jones; ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Re: stg_upd_frame_info still broken On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari mailto:ben@well-typed.com> wrote: Simon Peyton Jones mailto:simonpj@microsoft.com> writes:

I cloned an entirely new GHC repository. Then 'sh validate'. Same result as before: any attempt to run GHCi fails with an unresolved symbol.

bash$ c:/code/HEAD-1/inplace/bin/ghc-stage2 --interactive

GHCi, version 7.11.20151026: http://www.haskell.org/ghc/https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce0433e9616f94207642908d2deded4ff%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=RYlwVuvgZKZDInxJ2iDfFNuxK0UX2FGcSeplXjv4Yg0%3d :? for help

ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0'

ghc-stage2.exe: C:\code\HEAD-1\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o: unknown symbol `_stg_upd_frame_info'

How could I actually find what the problem is? Trying random things and hoping the problem goes away clearly is not working.

I would first try to find the object file which is supposed to provide this symbol and figure out whether the problem is one of the RTL (which is what I would put my money on) or some part of the build toolchain. I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", &foo }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but were moved to rts/RtsSymbols.c in commit abc214b77d. I guess that commit or a related one was not correct. Windows is the only (major?) platform on which the ghc executable is built statically by default, and therefore uses ghc's own runtime linker. I'll try building a Linux ghc with GHC_DYNAMIC=NO and if it exhibits the same problem I should be able to provide a quick fix. Regards, Reid Barton