[M3devel] bootstrap and Compiler.i3 change?

Jay jayk123 at hotmail.com
Fri Apr 18 13:28:43 CEST 2008


I really thought I did the right thing. Hm. I will have to start over.

And I'm seeing this again on birch, alas:

    at ../src/runtime/ex_frame/RTExFrame.m3:29
#17 0x082a394b in RTHooks__ReportFault (M3_AJWxb1_module=0x8359be0, M3_AcxOUs_info=6500)
    at ../src/runtime/common/RTHooks.m3:110
#18 0x082a5dbd in _m3_fault (M3_AcxOUs_arg=6500)
---Type  to continue, or q  to quit---
#19 0x082a4aba in RTAllocator__GetTracedObj (M3_Eic7CK_def=0x0)
    at ../src/runtime/common/RTAllocator.m3:203
#20 0x082a4660 in RTHooks__AllocateTracedObj (M3_AJWxb1_defn=0x0)
    at ../src/runtime/common/RTAllocator.m3:131
#21 0x082730ea in Pathname__Decompose (M3_Bd56fi_pn=0xb7e1302c)
    at ../src/os/POSIX/PathnamePosix.m3:31
#22 0x08104ed1 in PathRepr__Root (M3_Bd56fi_pn=0xb7e1302c) at ../src/PathReprCommon.m3:37
#23 0x08104fbb in PathReprCommon_M3 (M3_AcxOUs_mode=1) at ../src/PathReprCommon.m3:45
#24 0x082b6fd7 in RTLinker__RunMainBody (M3_DjPxE3_m=0x830b4c0)

I have AMD64 host building an x86 hosted x86/AMD64 target compiler now..and if you change "make" to "make all-gcc", it does a lot less...though still wastes time building unneeded stuff.

 - Jay

> Date: Fri, 18 Apr 2008 12:40:02 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] bootstrap and Compiler.i3 change?
>
> Quoting Jay :
>
>> What is the deal with building and the Compiler.i3 change?
>> I had difficulty here, despite using upgrade.py and upgrade.sh that
>> have gotten things correct before (and I understand what they are
>> doing).
>>
>> I ended up doing something that didn't make sense to me and I got
>> past it, but then I had another problem.
>>
>> I ran ugprade until it failed -- it built/shipped compiler and
>> m3core; then libm3 fails.
>> Then I think I ran either do-cm3-front.py, or I rolled back tools
>> and then ran do-cm3-front.py.
>>
>> I understand the change to Compiler.i3. It should be ok. It is in
>> m3core, build/ship that and then build libm3 should work, right?
>>
>> The code that is actually using Compiler.i3 is for fairly unused
>> targets, however it actually sets a good example I intend to follow.
>> Rather than probing for what Pathname.Join returns a\b or a/b, you
>> can check Compiler.Platform or whatnot directly.
>> But if there are more uses of this, outside m3core, this build
>> problem needs to be understood.
>> Probably I'm just missing something?
>
> Are you sure you didn't just forget to clean everything after
> building the first cm3? upgrade.sh should do it right though...
>
> My own regression tests at home seem to have recoverd from the
> target extension without further help (except for the new required
> libraries), too, so I'm quite sure that upgrade.sh does the right
> things.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>



More information about the M3devel mailing list