stg_upd_frame_info still broken

[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 <rwbarton at 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 <
> simonpj at 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 at gmail.com]
>> *Sent:* 27 October 2015 14:57
>> *To:* Ben Gamari
>> *Cc:* Simon Peyton Jones; ghc-devs at haskell.org
>> *Subject:* Re: stg_upd_frame_info still broken
>>
>>
>>
>> On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari <ben at well-typed.com> wrote:
>>
>> Simon Peyton Jones <simonpj at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151027/95d34923/attachment.html>