9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Go tip build fails
@ 2013-05-01 18:26 sl
  0 siblings, 0 replies; 18+ messages in thread
From: sl @ 2013-05-01 18:26 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 17:55 Skip Tavakkolian
  2013-05-01 18:11 ` Rob Pike
  2013-05-01 18:30 ` David du Colombier
@ 2013-05-01 22:41 ` Rob Pike
  2 siblings, 0 replies; 18+ messages in thread
From: Rob Pike @ 2013-05-01 22:41 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 20:58               ` Skip Tavakkolian
@ 2013-05-01 21:32                 ` Rob Pike
  0 siblings, 0 replies; 18+ messages in thread
From: Rob Pike @ 2013-05-01 21:32 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 20:46             ` Russ Cox
  2013-05-01 20:49               ` Jacob Todd
@ 2013-05-01 20:58               ` Skip Tavakkolian
  2013-05-01 21:32                 ` Rob Pike
  1 sibling, 1 reply; 18+ messages in thread
From: Skip Tavakkolian @ 2013-05-01 20:58 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

386 here.


On Wed, May 1, 2013 at 1:46 PM, Russ Cox <rsc@swtch.com> wrote:

> Are you all using 386 or amd64 systems?
>
> Russ
>
>

[-- Attachment #2: Type: text/html, Size: 518 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 20:46             ` Russ Cox
@ 2013-05-01 20:49               ` Jacob Todd
  2013-05-01 20:58               ` Skip Tavakkolian
  1 sibling, 0 replies; 18+ messages in thread
From: Jacob Todd @ 2013-05-01 20:49 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

32 bit.


On Wed, May 1, 2013 at 4:46 PM, Russ Cox <rsc@swtch.com> wrote:

> Are you all using 386 or amd64 systems?
>
> Russ
>
>

[-- Attachment #2: Type: text/html, Size: 516 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 19:59           ` Matthew Veety
  2013-05-01 20:46             ` Russ Cox
@ 2013-05-01 20:46             ` Rob Pike
  1 sibling, 0 replies; 18+ messages in thread
From: Rob Pike @ 2013-05-01 20:46 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 fine. But I would like to understand where the bad relocation value
is coming from. It's caused by something like a -4 becoming
0xFFFFFFFC, which doesn't matter when everything's 32 bits but is
caught by the error checking code that's using 64 bits.

-rob



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 19:59           ` Matthew Veety
@ 2013-05-01 20:46             ` Russ Cox
  2013-05-01 20:49               ` Jacob Todd
  2013-05-01 20:58               ` Skip Tavakkolian
  2013-05-01 20:46             ` Rob Pike
  1 sibling, 2 replies; 18+ messages in thread
From: Russ Cox @ 2013-05-01 20:46 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 49 bytes --]

Are you all using 386 or amd64 systems?

Russ

[-- Attachment #2: Type: text/html, Size: 89 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 19:25         ` Skip Tavakkolian
@ 2013-05-01 19:59           ` Matthew Veety
  2013-05-01 20:46             ` Russ Cox
  2013-05-01 20:46             ` Rob Pike
  0 siblings, 2 replies; 18+ messages in thread
From: Matthew Veety @ 2013-05-01 19:59 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

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
> 

[-- Attachment #2: Type: text/html, Size: 3497 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 19:14       ` Skip Tavakkolian
@ 2013-05-01 19:25         ` Skip Tavakkolian
  2013-05-01 19:59           ` Matthew Veety
  0 siblings, 1 reply; 18+ messages in thread
From: Skip Tavakkolian @ 2013-05-01 19:25 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

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
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3089 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 18:54     ` Rob Pike
  2013-05-01 19:14       ` Skip Tavakkolian
@ 2013-05-01 19:18       ` David du Colombier
  1 sibling, 0 replies; 18+ messages in thread
From: David du Colombier @ 2013-05-01 19:18 UTC (permalink / raw)
  To: 9fans

> 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.c	Wed May 01 10:00:05 2013 -0400
+++ b/src/cmd/ld/ldelf.c	Wed May 01 19:15:00 2013 +0000
@@ -706,7 +706,7 @@
 			else {
 				// load addend from image
 				if(rp->siz == 4)
-					rp->add = e->e32(sect->base+rp->off);
+					rp->add = (int32)e->e32(sect->base+rp->off);
 				else if(rp->siz == 8)
 					rp->add = e->e64(sect->base+rp->off);
 				else
diff -r 3478ecc801f6 src/cmd/ld/ldpe.c
--- a/src/cmd/ld/ldpe.c	Wed May 01 10:00:05 2013 -0400
+++ b/src/cmd/ld/ldpe.c	Wed May 01 19:15:00 2013 +0000
@@ -297,7 +297,7 @@
 				case IMAGE_REL_I386_DIR32:
 					rp->type = D_ADDR;
 					// load addend from image
-					rp->add = le32(rsect->base+rp->off);
+					rp->add = (int32)le32(rsect->base+rp->off);
 					break;
 				case IMAGE_REL_AMD64_ADDR64: // R_X86_64_64
 					rp->siz = 8;

--
David du Colombier



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 18:54     ` Rob Pike
@ 2013-05-01 19:14       ` Skip Tavakkolian
  2013-05-01 19:25         ` Skip Tavakkolian
  2013-05-01 19:18       ` David du Colombier
  1 sibling, 1 reply; 18+ messages in thread
From: Skip Tavakkolian @ 2013-05-01 19:14 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

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
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2558 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 18:30 ` David du Colombier
@ 2013-05-01 18:56   ` Skip Tavakkolian
  0 siblings, 0 replies; 18+ messages in thread
From: Skip Tavakkolian @ 2013-05-01 18:56 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

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 <0intro@gmail.com>wrote:

> > 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
> main.parseMetaGoImports: pc-relative relocation address is too big:
> 0x100049702
> main.init·1: pc-relative relocation address is too big: 0x10003b61a
> main.init·1: pc-relative relocation address is too big: 0x100000325
> main.init·1: pc-relative relocation address is too big: 0x100000317
> main.buildCompiler.Set: pc-relative relocation address is too big:
> 0x10003b5c7
> main.buildCompiler.Set: pc-relative relocation address is too big:
> 0x1000555a2
> main.buildCompiler.Set: pc-relative relocation address is too big:
> 0x100040b62
> main.buildCompiler.Set: pc-relative relocation address is too big:
> 0x100055508
> main.buildCompiler.Set: pc-relative relocation address is too big:
> 0x100040ad0
> main.buildCompiler.Set: pc-relative relocation address is too big:
> 0x100040b13
> main.buildCompiler.Set: pc-relative relocation address is too big:
> 0x10005f1ed
> main.buildCompiler.String: pc-relative relocation address is too big:
> 0x10003b3f7
> main.init·2: pc-relative relocation address is too big: 0x10003b3ca
> main.init·2: pc-relative relocation address is too big: 0x1000553a5
> main.init·2: pc-relative relocation address is too big: 0x100040965
> main.init·2: pc-relative relocation address is too big: 0x10005532f
> main.init·2: pc-relative relocation address is too big: 0x1000408f7
> main.addBuildFlags: pc-relative relocation address is too big: 0x10003b2b7
> main.addBuildFlags: pc-relative relocation address is too big: 0x10005a7fb
> too many errors
>
> --
> David du Colombier
>
>

[-- Attachment #2: Type: text/html, Size: 2625 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 18:31   ` Skip Tavakkolian
@ 2013-05-01 18:54     ` Rob Pike
  2013-05-01 19:14       ` Skip Tavakkolian
  2013-05-01 19:18       ` David du Colombier
  0 siblings, 2 replies; 18+ messages in thread
From: Rob Pike @ 2013-05-01 18:54 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

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
> 

[-- Attachment #2: Type: text/html, Size: 1276 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 18:11 ` Rob Pike
  2013-05-01 18:20   ` Jacob Todd
@ 2013-05-01 18:31   ` Skip Tavakkolian
  2013-05-01 18:54     ` Rob Pike
  1 sibling, 1 reply; 18+ messages in thread
From: Skip Tavakkolian @ 2013-05-01 18:31 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 587 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 17:55 Skip Tavakkolian
  2013-05-01 18:11 ` Rob Pike
@ 2013-05-01 18:30 ` David du Colombier
  2013-05-01 18:56   ` Skip Tavakkolian
  2013-05-01 22:41 ` Rob Pike
  2 siblings, 1 reply; 18+ messages in thread
From: David du Colombier @ 2013-05-01 18:30 UTC (permalink / raw)
  To: 9fans

> 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
main.parseMetaGoImports: pc-relative relocation address is too big: 0x100049702
main.init·1: pc-relative relocation address is too big: 0x10003b61a
main.init·1: pc-relative relocation address is too big: 0x100000325
main.init·1: pc-relative relocation address is too big: 0x100000317
main.buildCompiler.Set: pc-relative relocation address is too big: 0x10003b5c7
main.buildCompiler.Set: pc-relative relocation address is too big: 0x1000555a2
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040b62
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100055508
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040ad0
main.buildCompiler.Set: pc-relative relocation address is too big: 0x100040b13
main.buildCompiler.Set: pc-relative relocation address is too big: 0x10005f1ed
main.buildCompiler.String: pc-relative relocation address is too big: 0x10003b3f7
main.init·2: pc-relative relocation address is too big: 0x10003b3ca
main.init·2: pc-relative relocation address is too big: 0x1000553a5
main.init·2: pc-relative relocation address is too big: 0x100040965
main.init·2: pc-relative relocation address is too big: 0x10005532f
main.init·2: pc-relative relocation address is too big: 0x1000408f7
main.addBuildFlags: pc-relative relocation address is too big: 0x10003b2b7
main.addBuildFlags: pc-relative relocation address is too big: 0x10005a7fb
too many errors

-- 
David du Colombier



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 18:11 ` Rob Pike
@ 2013-05-01 18:20   ` Jacob Todd
  2013-05-01 18:31   ` Skip Tavakkolian
  1 sibling, 0 replies; 18+ messages in thread
From: Jacob Todd @ 2013-05-01 18:20 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 36 bytes --]

I'm experiencing the same problem.

[-- Attachment #2: Type: text/html, Size: 47 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [9fans] Go tip build fails
  2013-05-01 17:55 Skip Tavakkolian
@ 2013-05-01 18:11 ` Rob Pike
  2013-05-01 18:20   ` Jacob Todd
  2013-05-01 18:31   ` Skip Tavakkolian
  2013-05-01 18:30 ` David du Colombier
  2013-05-01 22:41 ` Rob Pike
  2 siblings, 2 replies; 18+ messages in thread
From: Rob Pike @ 2013-05-01 18:11 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 18+ messages in thread

* [9fans] Go tip build fails
@ 2013-05-01 17:55 Skip Tavakkolian
  2013-05-01 18:11 ` Rob Pike
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Skip Tavakkolian @ 2013-05-01 17:55 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

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: pc-relative relocation address is too big:
0x100049702
main.init·1: pc-relative relocation address is too big: 0x10003b61a
main.init·1: pc-relative relocation address is too big: 0x100000325
main.init·1: pc-relative relocation address is too big: 0x100000317
main.buildCompiler.Set: pc-relative relocation address is too big:
0x10003b5c7
main.buildCompiler.Set: pc-relative relocation address is too big:
0x1000555a2
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100040b62
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100055508
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100040ad0
main.buildCompiler.Set: pc-relative relocation address is too big:
0x100040b13
main.buildCompiler.Set: pc-relative relocation address is too big:
0x10005f1ed
main.buildCompiler.String: pc-relative relocation address is too big:
0x10003b3f7
main.init·2: pc-relative relocation address is too big: 0x10003b3ca
main.init·2: pc-relative relocation address is too big: 0x1000553a5
main.init·2: pc-relative relocation address is too big: 0x100040965
main.init·2: pc-relative relocation address is too big: 0x10005532f
main.init·2: pc-relative relocation address is too big: 0x1000408f7
main.addBuildFlags: pc-relative relocation address is too big: 0x10003b2b7
main.addBuildFlags: pc-relative relocation address is too big: 0x10005a7fb
too many errors

[-- Attachment #2: Type: text/html, Size: 2011 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2013-05-01 22:41 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-01 18:26 [9fans] Go tip build fails sl
  -- strict thread matches above, loose matches on Subject: below --
2013-05-01 17:55 Skip Tavakkolian
2013-05-01 18:11 ` Rob Pike
2013-05-01 18:20   ` Jacob Todd
2013-05-01 18:31   ` Skip Tavakkolian
2013-05-01 18:54     ` Rob Pike
2013-05-01 19:14       ` Skip Tavakkolian
2013-05-01 19:25         ` Skip Tavakkolian
2013-05-01 19:59           ` Matthew Veety
2013-05-01 20:46             ` Russ Cox
2013-05-01 20:49               ` Jacob Todd
2013-05-01 20:58               ` Skip Tavakkolian
2013-05-01 21:32                 ` Rob Pike
2013-05-01 20:46             ` Rob Pike
2013-05-01 19:18       ` David du Colombier
2013-05-01 18:30 ` David du Colombier
2013-05-01 18:56   ` Skip Tavakkolian
2013-05-01 22:41 ` Rob Pike

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).