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 <rwbar...@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 < > simo...@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:rwbar...@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 <b...@well-typed.com> wrote: >> >> Simon Peyton Jones <simo...@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 >> > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs