Go build is failing today and no mention of it in issue tracker. Anyone
else seeing this problem?
...
cmd/go
main.parseMetaGoImports: pc-relative relocation address is too big:
0x10003b677
main.parseMetaGoImports: pc-relative relocation address is too big:
0x100040cf3
main.parseMetaGoImports:
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
I'm experiencing the same problem.
troubleshooting
First
* STATE YOUR ASSUMPTIONS.
* cat /etc/os-release to verify you are not, in fact, running Ubuntu Linux with
a
Plan 9 theme.
* Try the latest ISO image.
-sl
Go build is failing today and no mention of it in issue tracker.
Anyone else seeing this problem?
Same problem here.
cmd/go
main.parseMetaGoImports: pc-relative relocation address is too big: 0x10003b677
main.parseMetaGoImports: pc-relative relocation address is too big: 0x100040cf3
yes.
On Wed, May 1, 2013 at 11:11 AM, Rob Pike robp...@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
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
the diagnostic string only appears in one place; it's in this presumably
abandoned patch:
https://codereview.appspot.com/9036046/
On Wed, May 1, 2013 at 11:30 AM, David du Colombier 0in...@gmail.comwrote:
Go build is failing today and no mention of it in issue tracker.
Anyone else seeing
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 =
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 made this change and it doesn't seem to fix the problem.
diff -r 3478ecc801f6 src/cmd/ld/ldelf.c
--- a/src/cmd/ld/ldelf.cWed May 01
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.tavakkol...@gmail.com wrote:
bootes% grep -n 'rp-add' *.[ch] | grep e32
ldelf.c:709: rp-add = e-e32(sect-base+rp-off);
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.tavakkol...@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,
The patch was not abandoned; that message was a codereview glitch.
It's checked in.
We need to find where the bogus relocation is coming from. It *is*
bogus, but the error catching it is new. To make progress, feel free
to comment out the code that prints the error. I'm pretty sure you'll
be
Are you all using 386 or amd64 systems?
Russ
386 here.
On Wed, May 1, 2013 at 1:46 PM, Russ Cox r...@swtch.com wrote:
Are you all using 386 or amd64 systems?
Russ
It would be easier to debug this if there was a way I could log in to
a Plan 9 machine (or virtual machine) capable of compiling and running
the Go distribution. Such public services have existed in the past;
does one exist today? Please contact me privately if you can help.
-rob
Thanks to machines offered by Erik Quanstrom and David du Colombier, I
found the bug. Trivial fix is out for review.
C's usual integer conversions apply.
-rob
17 matches
Mail list logo
