From mboxrd@z Thu Jan 1 00:00:00 1970 References:

From: Matthew Veety Content-Type: multipart/alternative; boundary=Apple-Mail-F66A985F-FF28-414D-8DB8-7F6D23A9B31C In-Reply-To: Message-Id: <02C52704-4155-474C-A722-45B2EC877927@gmail.com> Date: Wed, 1 May 2013 15:59:07 -0400 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [9fans] Go tip build fails Topicbox-Message-UUID: 4ed5843a-ead8-11e9-9d60-3106f5b1d025 --Apple-Mail-F66A985F-FF28-414D-8DB8-7F6D23A9B31C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I don't think changing ldelf.c would fix this issue. IIRC we don't use it on= Plan 9. On May 1, 2013, at 15:25, Skip Tavakkolian wrot= e: > found the other instance at line ldelf.c:681; the assignment from e32 is i= ndirect via "add". same results as before. >=20 >=20 > On Wed, May 1, 2013 at 12:14 PM, Skip Tavakkolian wrote: >> bootes% grep -n 'rp->add' *.[ch] | grep e32 >> ldelf.c:709: rp->add =3D e->e32(= sect->base+rp->off); >> ldmacho.c:807: rp->add =3D (int32)e->e32(s= ->p+rp->off) + rp->off + 4 - secaddr; >> ldmacho.c:809: rp->add =3D (int32)e->e32(s= ->p+rp->off); >> ldpe.c:294: rp->add =3D (int32)le32(rse= ct->base+rp->off); >> ldpe.c:300: rp->add =3D le32(rsect->bas= e+rp->off); >>=20 >> it seems that ldelf.c:709 is the only place that fits your instructions. = doing the cast has no effect (i.e. fails building cmd/go with the same erro= r messages) >>=20 >>=20 >> On Wed, May 1, 2013 at 11:54 AM, Rob Pike wrote: >>> that means you are building from source >>>=20 >>> in the ld directory, look for assignments to rd->add from calls to e32. t= wo do not do a cast to int32. try casting those two and let me know if you c= an >>>=20 >>> i will be at work in a couple of hours, not on a phone, and can offer mo= re help then.=20 >>>=20 >>>=20 >>> -rob >>>=20 >>> On May 1, 2013, at 11:31 AM, Skip Tavakkolian wrote: >>>=20 >>>> yes. >>>>=20 >>>>=20 >>>> On Wed, May 1, 2013 at 11:11 AM, Rob Pike wrote: >>>>> Are you using Plan 9? Because I don't understand how you could get >>>>> those messages on Plan 9, but I do on other systems. >>>>>=20 >>>>> -rob >=20 --Apple-Mail-F66A985F-FF28-414D-8DB8-7F6D23A9B31C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I don't think changing ldelf.c would fix this issue. IIRC we don't use it on Plan 9.

On May 1, 2013, at 15:25, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:

found the other instance at line ldelf.c:681; the assignment from e32 is indirect via "add". same results as before.

On Wed, May 1, 2013 at 12:14 PM, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:

bootes% grep -n 'rp->add' *.[ch] | grep e32
ldelf.c:709: rp->add = e->e32(sect->base+rp->off);

ldmacho.c:807: rp->add = (int32)e->e32(s->p+rp->off) + rp->off + 4 - secaddr;

ldmacho.c:809: rp->add = (int32)e->e32(s->p+rp->off);
ldpe.c:294: rp->add = (int32)le32(rsect->base+rp->off);

ldpe.c:300: rp->add = le32(rsect->base+rp->off);

it seems that ldelf.c:709 is the only place that fits your instructions. doing the cast has no effect (i.e. fails building cmd/go with the same error messages)

On Wed, May 1, 2013 at 11:54 AM, Rob Pike <robpike@gmail.com> wrote:

that means you are building from source

in the ld directory, look for assignments to rd->add from calls to e32. two do not do a cast to int32. try casting those two and let me know if you can

i will be at work in a couple of hours, not on a phone, and can offer more help then.

-rob

On May 1, 2013, at 11:31 AM, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:

yes.

On Wed, May 1, 2013 at 11:11 AM, Rob Pike <robpike@gmail.com> wrote:

Are you using Plan 9? Because I don't understand how you could get
those messages on Plan 9, but I do on other systems.

-rob

--Apple-Mail-F66A985F-FF28-414D-8DB8-7F6D23A9B31C--