Go: build: bootstrapping Go 1.n on macOS Sierra from source

[bradfitz]

@andlabs pointed out in https://github.com/golang/go/issues/16272#issuecomment-232444173 that as of macOS Sierra, we'll have no way to bootstrap Go 1.N from source.

Maybe we need to backport @ianlancetaylor's time fix to Go 1.4?

[bradfitz]

Nevermind. @ianlancetaylor says it works fine on Sierra. You can build Go 1.4 there and time won't work and tests will fail, but it will successfully build Go 1.7.

[andlabs]

Good to know. I'm fine with untested 1.4s (the tests take too long to run on my virtual machines so I don't have a choice in those cases =P ); hopefully this won't break something else in the future.

[ianlancetaylor]

I'm closing this because I believe that it works fine today.

[bradfitz]

As of Sierra Beta 4, this issue is again relevant.

[kirillDanshin]

I think we need to backport this fix in 1.4.4 as soon as possible.
we could also wait for Sierra stable release but now folks can't install Go from source.

[bradfitz]

@kirillDanshin, we're going to wait until Sierra is released. It's already changed twice during Sierra betas.

[kirillDanshin]

ok @bradfitz ping me here when we'll going to backport the fix, I'll do it.

[ianlancetaylor]

@kirillDanshin People using a beta version of Sierra and building Go from source should, I hope, be able to apply a patch to their 1.4.3 sources. It doesn't make sense for us to release 1.4.4 now, given that the code in Sierra has changed twice already.

[tattwamasi]

Has anyone filed a radar with Apple, and would it be worth it to? I was about to, and reference this and related issues, but will reference other IDs if already filed. (Edit: based on conversation in the other issues re: the change, seems like it isn't worth bringing up)

I had a working Go, but the b4 broke it, or I did with something else, so I was (re)installing with brew. Is there a easy(ish) way to build using the 1.4.3 patch with brew, or am I better off just pulling 1.4.3 from git and going from source?

[bradfitz]

Apple knows. The right people on both sides know the details. It's Go's fault, anyway, not Apple's.

[tattwamasi]

Thanks. And to follow up on the remainder of my comment, I didn't actually need to install from source, and had no reason to have to use brew, so I downloaded the pkg file for 1.7b5 from the main site.

It seems to work fine, and based on the git history should contain the fixes for Sierra (for now at least 😁 )
Now to rebuild Hugo and hopefully stop the frequent, but intermittent, crashes.

[bradfitz]

macOS Sierra GM (Gold Master) came out yesterday. The time system call interface is unchanged from Beta 4.

I confirmed that all.bash passes on macOS 10.12 Sierra, using Go 1.7.1 as the GOROOT_BOOTSTRAP. It fails to bootstrap using Go 1.4.3.

So, should we cherry-pick the time fix back to Go 1.4.4 so there's a source-only way to bootstrap on macOS 10.12+?

The cherry picks would be:

fad2bbdc6a686a20174d2e73cf78f1659722bb39 (the first change, for Sierra beta2)
2da5633eb9091608047881953f75b489a3134cdc (the fix for Sierra beta4, and final)
da070bed19fb23a8dd1b9f974c7fdf1f247fdba0 (the syscall package too)

@ianlancetaylor, @rsc?

[ianlancetaylor]

I suppose I am mildly in favor of doing a 1.4.4 release for better Darwin support going forward. We should also consider #14795 (https://golang.org/cl/21190) and #13114 (https://golang.org/cl/16982).

[mwhudson]

I fixed #13114 on release-branch.go1.4 already (https://go-review.googlesource.com/c/21598/)

[marcopeereboom]

This is what I see when building golang relase-branch.go1.4 on macOS sierra 10.12.1 Beta (16B2338c)

[release-branch.go1.4]$ ./all.bash

Building C bootstrap tool.

cmd/dist

Building compilers and Go bootstrap tool for host, darwin/amd64.

lib9
libbio
liblink
cmd/cc
cmd/gc
cmd/6l
cmd/6a
cmd/6c
cmd/6g
runtime
errors
sync/atomic
sync
io
unicode
unicode/utf8
unicode/utf16
bytes
math
strings
strconv
bufio
sort
container/heap
encoding/base64
syscall
time
os
reflect
fmt
encoding
encoding/json
flag
path/filepath
path
io/ioutil
log
regexp/syntax
regexp
go/token
go/scanner
go/ast
go/parser
os/exec
os/signal
net/url
text/template/parse
text/template
go/doc
go/build
cmd/go
failed MSpanList_Insert 0x475688 0x898f2c5a50 0x0
fatal error: MSpanList_Insert

runtime stack:
runtime.MSpanList_Insert(0x40afd0, 0x475688)
/Users/marco/go1.4/src/runtime/mheap.c:692 +0x8f
runtime.MHeap_Free(0x40af60, 0x475688, 0x0)
/Users/marco/go1.4/src/runtime/mheap.c:500 +0x5b
runtime.MCentral_FreeSpan(0x4148f8, 0x475688, 0x2, 0xc2082e2000, 0xc2082e3000, 0x0, 0x64)
/Users/marco/go1.4/src/runtime/mcentral.c:181 +0x1bb
runtime.MSpan_Sweep(0x475688, 0x10900000100, 0x101)
/Users/marco/go1.4/src/runtime/mgc0.c:1099 +0x477
runtime.MHeap_Alloc(0x40af60, 0x1, 0x1000000000a, 0x77549)
/Users/marco/go1.4/src/runtime/mheap.c:240 +0x66
runtime.MCentral_CacheSpan(0x4123d8, 0x24f0c0)
/Users/marco/go1.4/src/runtime/mcentral.c:85 +0x167
runtime.MCache_Refill(0x45c000, 0xc20000000a, 0x4755b8)
/Users/marco/go1.4/src/runtime/mcache.c:90 +0xa0

goroutine 1 [running]:
runtime.switchtoM()
/Users/marco/go1.4/src/runtime/asm_amd64.s:198 fp=0xc20802b760 sp=0xc20802b758
runtime.mallocgc(0x90, 0x291a20, 0x1, 0x82ab4)
/Users/marco/go1.4/src/runtime/malloc.go:178 +0x849 fp=0xc20802b810 sp=0xc20802b760
runtime.newobject(0x291a20, 0x3)
/Users/marco/go1.4/src/runtime/malloc.go:353 +0x49 fp=0xc20802b838 sp=0xc20802b810
os.Lstat(0xc2081b33b0, 0x2a, 0x0, 0x0, 0x0, 0x0)
/Users/marco/go1.4/src/os/file_unix.go:146 +0x4e fp=0xc20802b878 sp=0xc20802b838
os.(_File).readdir(0xc2080342f8, 0xffffffffffffffff, 0xc2082dba70, 0x8, 0x9, 0x0, 0x0)
/Users/marco/go1.4/src/os/file_unix.go:162 +0x225 fp=0xc20802b970 sp=0xc20802b878
os.(_File).Readdir(0xc2080342f8, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/marco/go1.4/src/os/doc.go:115 +0x9e fp=0xc20802b9b0 sp=0xc20802b970
io/ioutil.ReadDir(0xc208100ed0, 0x22, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/marco/go1.4/src/io/ioutil/ioutil.go:105 +0xe9 fp=0xc20802ba38 sp=0xc20802b9b0
main.clean(0xc208116800)
/Users/marco/go1.4/src/cmd/go/clean.go:118 +0x1bb fp=0xc20802bd18 sp=0xc20802ba38
main.runClean(0x3f9ae0, 0xc20800a030, 0x1, 0x1)
/Users/marco/go1.4/src/cmd/go/clean.go:79 +0x9c fp=0xc20802bd98 sp=0xc20802bd18
main.main()
/Users/marco/go1.4/src/cmd/go/main.go:163 +0x608 fp=0xc20802bf98 sp=0xc20802bd98
runtime.main()
/Users/marco/go1.4/src/runtime/proc.go:63 +0xf3 fp=0xc20802bfe0 sp=0xc20802bf98
runtime.goexit()
/Users/marco/go1.4/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20802bfe8 sp=0xc20802bfe0

goroutine 5 [syscall]:
os/signal.loop()
/Users/marco/go1.4/src/os/signal/signal_unix.go:21 +0x1f
created by os/signal.init·1
/Users/marco/go1.4/src/os/signal/signal_unix.go:27 +0x35
[release-branch.go1.4]$

[bradfitz]

@marcopeereboom, we know. That's what this bug is about.

[nathany]

@marcopeereboom If you are just trying to bootstrap Go 1.7 or master/tip, a temporary workaround is to use the Go 1.7 binaries to compile Go 1.7+ by setting GOROOT_BOOTSTRAP to an existing Go 1.7 installation (I found this out via https://github.com/golang/go/issues/17182#issuecomment-248818344).

[marcopeereboom]

I missed the point of the bug; I thought I was seeing something different hence I wrote it up. @nathany I have bootstrapped it but thanks for pointing it out!

[shakeel]

FYI: I encounter fatal errors with MSpanList_Insert after upgrading to MacOS Sierra, however I am not building a Go distribution. I am trying to build fuchsia, specifically the mojom tool in fuchsia which is trying to generate bindings for a mojom file. This error occurs consistently and for different mojom files. The mojom binaries are built by Google and shipped along with the fuchsia source code. Not sure what version of Go is being used to build it. I am on Go 1.7.1

[bradfitz]

@shakeel, those mojom binaries would need to be rebuilt with Go 1.7+.

[shakeel]

Thanks @bradfitz, now I need to convince somebody on Go Fuchsia team to actually rebuild mojom, it is pre-built and downloaded as part of the fuchsia repository. A lot of folks are shocked when I mention it on IRC but so far I have not been able to convince anybody that this is indeed the problem.

[bradfitz]

Um, @crawshaw certainly knows. Or maybe he's not the "Go Fuchsia team".

[crawshaw]

@shakeel, I am the one porting Go to Fuchsia, but oddly I don't do the mac prebuilt toolchain. Even more oddly, mojom is not in the prebuilt toolchain, it has its own prebuilt binary. I'll see if I can find the owner.

Probably the best forum for this in the future is the fuchsia IRC channel. Feel free to @-mention me there for Go-related stuff, though I might respond in email-time.

[rsc]

I agree with Ian about doing a 1.4.4 release to keep it working on Sierra.

[shakeel]

@crawshaw thanks for the follow-up, I have been pestering a lot of folks on the #fuchsia IRC channel and thanks for helping me out with my dumb questions. It looks like somebody called azani is responsible for the mojom binary, that is the last conversation I had with smklein on #fuchsia IRC. My guess is that it was built with an older version of Go, but cannot tell for sure.

Until mojom is rebuilt, the ninja build for Fuchsia is broken on MacOS Sierra.

[nathany]

My guess is that it was built with an older version of Go, but cannot tell for sure.

@shakeel You can try strings mybinary | grep go1 to see what version of Go a binary was built with.

[shakeel]

@nathany the answer is go1.6

Thanks that is nice to know and now I can confirm that it is built with go version prior to 1.6..3 and hence the failures.

[fazalmajid]

Another vote for a 1.4.4 release for Sierra. I bootstrap from source and 1.4.3 breaks with the same error as reported by marcopeereboom above.

[bradfitz]

No voting is necessary. This will happen. Also: https://golang.org/wiki/NoMeToo

[marcopeereboom]

Is there an ETA on this?

Having a castrated laptop is kind of annoying. Not being pushy but I need to plan upgrades in my org to sierra.

[quentinmit]

@marcopeereboom The only thing this issue is blocking is bootstrapping Go 1.7 from C on Sierra. You can always either deploy a binary built elsewhere (such as the ones on golang.org or your own machine) or in fact build your own 1.7 from source using a newer compiler. I haven't tested it but you should be able to bootstrap with Gccgo as well.

[marcopeereboom]

So let me make sure I understand this right, though. There is not going to be a go 1.4.4 that bootstraps latest go ever?

I got the impression from @bradfitz's comment that there is going to be one.

[bradfitz]

@marcopeereboom, you do not understand correctly. I'm not sure how you jumped to that conclusion from @quentinmit's reply.

There will be a Go 1.4.4 release to restore the ability to bootstrap on a Mac from C and Go source code only.

But nobody should be working that way day-to-day, so it's not super urgent priority. Even if you need to compile Go from source (which few people do), you can place the Go 1.7 binary download files at $HOME/go1.4 or to /any/path and set $GOROOT_BOOTSTRAP to /any/path and it'll work fine on Sierra.

[marcopeereboom]

@bradfitz no I did understand it but was confused by @quentinmit comment of bootstrapping go 1.7 from C on sierra :)

And just as an FYI. We run all our development machines with go1.4 in home that bootstraps latest go release. We have always run that way because prepackaged go versions in different OS' are always a mishmash of versions and frankly don't always work right (just this morning a new hire found out Debian is on Go 1.3 the hard way). When run this way multiuser machines can run whatever go version a user needs without stepping on some system default. We also use this to test code with multiple versions of go by simply flipping GOPATH. I truly appreciate the fact that go let's us do that easily. FWIW.

[quentinmit]

@marcopeereboom You can bootstrap from any working Go compiler. You don't have to bootstrap from go1.4 in home. It's unfortunate but the set of "working Go compiler" for Sierra is smaller than the set on other platforms.

Basically what I'm trying to say is there's nothing magic about Go 1.4 for your usecase. You should just bootstrap from Go 1.7 instead.

[marcopeereboom]

@quentinmit sure, but that does mean I need a working go first. I am resisting the copying/using binary built elsewhere bit.

[fazalmajid]

@bradfitz I apologize for my breach of etiquette.

That said, more people than you think rely on bootstrapping from source. My company has a policy of using only fully repeatable builds of its entire dependency stack from source, including Go, and it also customizes some aspects like the default trusted SSL certificate authority search path. Mac OS X is not a core production platform for them, unlike Solaris, FreeBSD and Linux, but we use the same automated build process for our developers' Macs. For Go, the process builds 1.4.3 from source, then uses that to bootstrap 1.7.1. Things like OpenSSL security releases trigger full rebuilds of our /usr/local, a process that takes about 6.5 hours.

[fazalmajid]

@marcopeereboom
applying the patch sierra-clock_gettime copy.patch from comment 13 of https://trac.macports.org/ticket/52041 fixes 1.4.3, at least enough to bootstrap 1.7.1.
It's a combo of https://go-review.googlesource.com/#/c/24812/ and https://go-review.googlesource.com/#/c/25400/

[marcopeereboom]

@fazalmajid thank you! Very helpful.

[josharian]

CLs 31729, 31750, and 31751 are the cherry-picks of the Sierra time changes (fad2bbd, 2da5633, da070be) to release-branch.go1.4.

Ian also suggests pulling in #14795 (https://golang.org/cl/21190), which I have not done, since it does not apply cleanly and I am not set up to test it myself. Help requested on that CL.

[ianlancetaylor]

I must admit that I do not know how to create a CL on a branch.

The patch for #14795 is:

diff -r 4857784ba342 src/runtime/sys_linux_386.s
--- a/src/runtime/sys_linux_386.s   Thu Jan 08 14:10:03 2015 +1100
+++ b/src/runtime/sys_linux_386.s   Sat Oct 22 22:52:26 2016 -0700
@@ -379,9 +379,18 @@
 #define SEG_NOT_PRESENT 0x20
 #define USEABLE 0x40

+// `-1` means the kernel will pick a TLS entry on the first setldt call,
+// which happens during runtime init, and that we'll store back the saved
+// entry and reuse that on subsequent calls when creating new threads.
+DATA  runtime·tls_entry_number+0(SB)/4, $-1
+GLOBL runtime·tls_entry_number(SB), NOPTR, $4
+
 // setldt(int entry, int address, int limit)
+// We use set_thread_area, which mucks with the GDT, instead of modify_ldt,
+// which would modify the LDT, but is disabled on some kernels.
+// The name, setldt, is a misnomer, although we leave this name as it is for
+// the compatibility with other platforms.
 TEXT runtime·setldt(SB),NOSPLIT,$32
-   MOVL    entry+0(FP), BX // entry
    MOVL    address+4(FP), CX   // base address

    /*
@@ -400,18 +409,19 @@
    ADDL    $0x8, CX    // address
    MOVL    CX, 0(CX)

+   // get entry number
+   MOVL    runtime·tls_entry_number(SB), DX
+
    // set up user_desc
    LEAL    16(SP), AX  // struct user_desc
-   MOVL    BX, 0(AX)
-   MOVL    CX, 4(AX)
-   MOVL    $0xfffff, 8(AX)
+   MOVL    DX, 0(AX)   // unsigned int entry_number
+   MOVL    CX, 4(AX)   // unsigned long base_addr
+   MOVL    $0xfffff, 8(AX) // unsigned int limit
    MOVL    $(SEG_32BIT|LIMIT_IN_PAGES|USEABLE|CONTENTS_DATA), 12(AX)   // flag bits

-   // call modify_ldt
-   MOVL    $1, BX  // func = 1 (write)
-   MOVL    AX, CX  // user_desc
-   MOVL    $16, DX // sizeof(user_desc)
-   MOVL    $123, AX    // syscall - modify_ldt
+   // call set_thread_area
+   MOVL    AX, BX  // user_desc
+   MOVL    $243, AX    // syscall - set_thread_area
    CALL    *runtime·_vdso(SB)

    // breakpoint on error
@@ -419,10 +429,18 @@
    JLS 2(PC)
    INT $3

-   // compute segment selector - (entry*8+7)
-   MOVL    entry+0(FP), AX
+   // read allocated entry number back out of user_desc
+   LEAL    16(SP), AX  // get our user_desc back
+   MOVL    0(AX), AX
+
+   // store entry number if the kernel allocated it
+   CMPL    DX, $-1
+   JNE 2(PC)
+   MOVL    AX, runtime·tls_entry_number(SB)
+
+   // compute segment selector - (entry*8+3)
    SHLL    $3, AX
-   ADDL    $7, AX
+   ADDL    $3, AX
    MOVW    AX, GS

    RET

[josharian]

I believe that all 1.4.4 CLs have now been submitted in the release branch. Should we ask in golang-dev about other CLs? Or just tag this and call it done?

[bradfitz]

You could ask. There will be a lot of requests for random things to be backported. Making the latest tz database work (#17276), or at least skipping the time tests, or making the time tests only use the included tzdata.zip file (instead of the system tzdat) might be sane. But probably pushing it.

[josharian]

Hmm. I think I won't ask. So I guess this is in @broady's court now.

Also, for those in this thread who want to bootstrap from source and don't want to wait for the actual release: You can always use the release-branch.go1.4 branch rather than a tagged (go1.4.4) commit.

[andlabs]

Awesome. I can confirm it works myself once I make the jump to Sierra (this was one of the things holding me back; the other being that I would need to make a 10.11 VM for my own testing afterward and I'm not sure if I should just download the Install El Capitan app again from the App Store or not).

[josharian]

In fact, given that people basically only want Go 1.4 in order to be able to bootstrap from source, is there any reason to do any more Go 1.4.x releases at all, as opposed to just pulling in commits as necessary to the release branch?

[rasky]

@josharian people don't know that they need the get the release-branch.go1.4 branch to bootstrap. They will hit errors, Google them, find patches in bugs, try to apply them, etc.

What you could do is a source-only release, but I think a release in the Downloads page is what will help people bootstrap Go.

[bradfitz]

Or we release "go-bootstrap-YYYYMMDD.tar.gz" which is a source-only release, without a Go version number, and remove everything from it that's not required to bootstrap Go 1.N. For instance, we remove net/http and friends, so nobody can really use it for anything other than bootstrapping.

[nathany]

Confirming that release-branch.go1.4 compiled and tests ran without issues on macOS Sierra 10.12. Go release-branch.go1.7 also built and tests ran without issue using 1.4 to bootstrap.

FYI, Go 1.4 still reports itself as go1.4.3 rather than a dev/bootstrap version.

❯ go14 version
go version go1.4.3 darwin/amd64

❯ echo $GOROOT_BOOTSTRAP
/Users/nathany/src/go.googlesource.com/go1.4

[bradfitz]

Decision from meeting: we'll release a "go-bootstrap-YYYYMMDD.tar.gz" source-only release, with a VERSION file saying "go1.4bootstrap20161024" and not remove any packages from it.

But per https://github.com/golang/go/issues/17545#issuecomment-255832513 we'll skip the time test that fails with the latest tzdata release.

[marcopeereboom]

Sweet mother of working go 1.4!

Thanks everyone!

[gopherbot]

CL https://golang.org/cl/31930 mentions this issue.

[andlabs]

So out of curiosity, which CL fixes the MSpanList_Insert bug? I'd like to know more about what happened there. Is it 21598?

[ianlancetaylor]

@andlabs I assume it's the fix for #16570. That fixed a problem in which fetching the current time would corrupt a random memory location.

[andlabs]

Ah yes, I had forgotten about that bit and overlooked it thinking something not time-related had happened. Thanks.

[c4milo]

I'm trying to upgrade from 1.7.1 to 1.7.3 via go1.4bootstrap20161024 and there is no love.

c4milo at camilompb in ~/Projects/c4milo/go/src on release-branch.go1.7 [!?]
$ ./make.bash
##### Building Go bootstrap tool.
cmd/dist
failed MSpanList_Insert 0x752080 0x43d98fd7ea1eb 0x0
fatal error: MSpanList_Insert

runtime stack:
runtime.MSpanList_Insert(0x6a1730, 0x752080)
    /usr/local/go/src/runtime/mheap.c:692 +0x8f
runtime.MHeap_Free(0x6a16c0, 0x752080, 0xc200000000)
    /usr/local/go/src/runtime/mheap.c:500 +0x5b
runtime.MCentral_FreeSpan(0x6ab058, 0x752080, 0x2, 0xc2080ec000, 0xc2080ed000, 0x0, 0x64)
    /usr/local/go/src/runtime/mcentral.c:181 +0x1bb
runtime.MSpan_Sweep(0x752080, 0x2900000000, 0x1)
    /usr/local/go/src/runtime/mgc0.c:1099 +0x477
runtime.MHeap_Alloc(0x6a16c0, 0x1, 0x1000000001c, 0x791d9)
    /usr/local/go/src/runtime/mheap.c:240 +0x66
runtime.MCentral_CacheSpan(0x6a9f78, 0x7520e8)
    /usr/local/go/src/runtime/mcentral.c:85 +0x167
runtime.MCache_Refill(0x74c000, 0x1c, 0x7520e8)
    /usr/local/go/src/runtime/mcache.c:90 +0xa0

goroutine 1 [running]:
runtime.switchtoM()
    /usr/local/go/src/runtime/asm_amd64.s:198 fp=0xc2080e8408 sp=0xc2080e8400
runtime.mallocgc(0x2c0, 0x401560, 0xc200000000, 0x2)
    /usr/local/go/src/runtime/malloc.go:178 +0x849 fp=0xc2080e84b8 sp=0xc2080e8408
runtime.newarray(0x401560, 0x2, 0x2c)
    /usr/local/go/src/runtime/malloc.go:365 +0xc1 fp=0xc2080e84f0 sp=0xc2080e84b8
runtime.hashGrow(0x34bfe0, 0xc2081129f0)
    /usr/local/go/src/runtime/hashmap.go:744 +0x86 fp=0xc2080e8520 sp=0xc2080e84f0
runtime.mapassign1(0x34bfe0, 0xc2081129f0, 0xc2080e8aa0, 0xc2080e8bc8)
    /usr/local/go/src/runtime/hashmap.go:456 +0x568 fp=0xc2080e85c0 sp=0xc2080e8520
go/build.(*Context).Import(0x691820, 0xc208099ce1, 0x7, 0xc208091350, 0x2d, 0x4, 0xc208169200, 0x0, 0x0)
    /usr/local/go/src/go/build/build.go:731 +0x41d1 fp=0xc2080e8eb0 sp=0xc2080e85c0
main.loadImport(0xc208099ce1, 0x7, 0xc208091350, 0x2d, 0xc20801efc0, 0xc20806b9a0, 0x3, 0x4, 0x0)
    /usr/local/go/src/cmd/go/pkg.go:267 +0x4d9 fp=0xc2080e9068 sp=0xc2080e8eb0
main.(*Package).load(0xc20806d000, 0xc20801efc0, 0xc2080b4300, 0x0, 0x0, 0x4)
    /usr/local/go/src/cmd/go/pkg.go:584 +0x3d88 fp=0xc2080e9620 sp=0xc2080e9068
main.loadImport(0xc208098fb0, 0xa, 0x7fff5fbffb6f, 0x24, 0xc20801efc0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/cmd/go/pkg.go:275 +0x635 fp=0xc2080e97d8 sp=0xc2080e9620
main.loadPackage(0xc208098fb0, 0xa, 0xc20801efc0, 0x0)
    /usr/local/go/src/cmd/go/pkg.go:867 +0xf7c fp=0xc2080e9a18 sp=0xc2080e97d8
main.packagesAndErrors(0xc208098fe0, 0x1, 0x1, 0x0, 0x0, 0x0)
    /usr/local/go/src/cmd/go/pkg.go:906 +0x366 fp=0xc2080e9b30 sp=0xc2080e9a18
main.packagesForBuild(0xc20800a040, 0x1, 0x1, 0x0, 0x0, 0x0)
    /usr/local/go/src/cmd/go/pkg.go:919 +0x74 fp=0xc2080e9c40 sp=0xc2080e9b30
main.runBuild(0x68c900, 0xc20800a040, 0x1, 0x1)
    /usr/local/go/src/cmd/go/build.go:266 +0x78 fp=0xc2080e9d98 sp=0xc2080e9c40
main.main()
    /usr/local/go/src/cmd/go/main.go:163 +0x608 fp=0xc2080e9f98 sp=0xc2080e9d98
runtime.main()
    /usr/local/go/src/runtime/proc.go:63 +0xf3 fp=0xc2080e9fe0 sp=0xc2080e9f98
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc2080e9fe8 sp=0xc2080e9fe0

goroutine 5 [syscall]:
os/signal.loop()
    /usr/local/go/src/os/signal/signal_unix.go:21 +0x1f
created by os/signal.init·1
    /usr/local/go/src/os/signal/signal_unix.go:27 +0x35

c4milo at camilompb in ~/Projects/c4milo/go/src on release-branch.go1.7 [!?]
$ go version
go version go1.4-bootstrap-20161024 darwin/amd64

[bradfitz]

@c4milo, I don't think you're doing it correctly. Do you have GOROOT_BOOTSTRAP set? What is it pointing to?

[c4milo]

I set GOROOT_BOOTSTRAP to go1.4-bootstrap-20161024. It worked now. My mistake was switching to 1.7 branch from the same repo as you pointed out.

[bsiegert]

From a distro packager's point of view, it would be preferable to have a
"real" 1.4.4 release.
Brad Fitzpatrick [email protected] schrieb am Mo. 24. Okt. 2016 um
21:08:

Decision from meeting: we'll release a "go-bootstrap-YYYYMMDD.tar.gz"
source-only release, with a VERSION file saying "go1.4bootstrap20161024"
and not remove any packages from it.

But per #17545 (comment)
https://github.com/golang/go/issues/17545#issuecomment-255832513 we'll
skip the time test that fails with the latest tzdata release.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16352#issuecomment-255835099, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA04Ghy-VaV47Svt5UrauX0AZFULFAJ4ks5q3QITgaJpZM4JLtk3
.

[bradfitz]

@bsiegert, elaborate.

[andlabs]

For a distro that does their own local patching I'm not sure how this would interfere...

[minux]

Yeah, I think we can rely on github's "download branch" feature, and not
release any more binaries for Go 1.4.

[bradfitz]

Here's a Go 1.4 source-only snapshot for building on Sierra: https://storage.googleapis.com/golang/go1.4-bootstrap-20161024.tar.gz

[gopherbot]

CL https://golang.org/cl/32312 mentions this issue.

[bradfitz]

@broady deployed the docs: https://golang.org/doc/install/source#go14

Closing this.

[hartzell]

Here's a Go 1.4 source-only snapshot for building on Sierra: https://storage.googleapis.com/golang/go1.4-bootstrap-20161024.tar.gz

@bradfitz -- My reading of the full set of comments here is that if there are other changes needed to keep 1.4 building in the future (even if Apple drops MacOS, etc...) there will be new date-stamped tarballs. Is that correct?

I'm touching up the spack packaging for the bootstrap and can either track the tip of the 1.4 release branch or use tarballs. The project has a mild preference for tarballs because one can verify them with digests.

[bradfitz]

@bradfitz -- My reading of the full set of comments here is that if there are other changes needed to keep 1.4 building in the future (even if Apple drops MacOS, etc...) there will be new date-stamped tarballs. Is that correct?

Yup. That's the idea. If there are changes needed in the future.

[hartzell]

@bradfitz Thanks!

[gunsluo]

download https://storage.googleapis.com/golang/go1.4-bootstrap-20161024.tar.gz
compile success

@bradfitz Thanks!

[StudioEtrange]

Still need a "real" binary release of 1.4.4, for some packaging system, some fast bootstraping purpose (without having to build go 1.4.4), or use gonative+gox tools on macos, and so on.

I dont know which problem does it generate to make a binary release instead of just source release ?

Please just release a binary go1.4.4 !

[broady]

You can use 1.9.2 for that purpose.

On Nov 8, 2017 7:38 PM, "StudioEtrange" [e-mail] wrote:

Still need a "real" binary release of 1.4.4, for some packaging system,
some fast boostraping purpose (without having to build go 1.4.4) and so on.

I dont know which problem does it generate to make binary release instead
of just source release ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/16352#issuecomment-343038008, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABhlvlPzDBhOwgAw5OkexqckNNuuwnNks5s0nO-gaJpZM4JLtk3
.

[StudioEtrange]

No, I cannot use 1.9.2 in some use case, for example for gonative+gox.
At this time gonative+gox on macos sierra is broken. And we just need a binary 1.4.4 release to not have to prebuilt a go1.4.4 before all our other task. Making too long bootstraping.

So, what is the exact problem of releasing 1.4.4 binary ?

[broady]

Can you help me understand why you need a 1.4.x binary release?

You can use any recent version of Go to bootstrap an environment to compile from source.

You only need the 1.4.x source to bootstrap if you want to build entirely from source.
If you want a binary release to bootstrap, use the latest stable version (i.e., 1.9.2).

I thought there was an explanation of this somewhere, but I can't find it.

[StudioEtrange]

Ok
Crosscompiling chain use gonative+gox. (https://github.com/inconshreveable/gonative)
I think you know this set up.

gonative is a simple tool which creates a build of Go that can cross compile to all platforms while still using the Cgo-enabled versions of the stdlib packages. It does this by downloading the binary distributions for each platform and copying their libraries into the proper places.

Some go application use this setup to cross compile go application.

And for now, gonative needs go1.4 to work. Then it download binaries and prepare cross compiling toolchain, then we use gox to cross compile.

So, getting in first place go1.4.4 (so with patches for macos included) to be built before cross compilation take a while in case of bootstraping chain.

That's a use case of having 1.4.4 binary available

[broady]

Why does gonative require go1.4? I find that hard to believe. This sounds like an issue with gonative.

/cc @inconshreveable

[StudioEtrange]

Dont know yet.
I investigate in the two direction

• why gonative works only on 1.4.x
• why there is not a go binary 1.4.4

[inconshreveable]

@StudioEtrange gonative is very, very old and almost certainly no longer necessary or the right way to do whatever it is that you're trying to do. i no longer use it and you should consider it a deprecated tool. any issue with it also belongs on that repository and not here

[rsc]

Please don't comment on long-closed issues. We don't track them.