[go-nuts] Re: [golang-dev] Subject: Go 1.9.2 and Go 1.8.5 are released

[Michael Hudson-Doyle]

On 26 October 2017 at 18:56, Chris Broadfoot <c...@google.com> wrote:

> Nice! Thank you for maintaining these!
>

I hope people find them useful (I know quite a few people at Canonical are
using them but I don't know if many people outside are using them),


> BTW, if it helps, all tarballs are now gpg signed. (add .asc to the
> download URL)
>

Ah, that's interesting (also for the Debian packaging).

Currently I build the snaps from the tag in git but I should probably
switch to the source tarball really as that's the more of the official
definition of what the release is.

I notice that the signing key doesn't appear to be in the strong set, are
you planning to get it more signatures?

Cheers,
mwh


> On Oct 25, 2017 7:58 PM, "Michael Hudson-Doyle" <
> michael.hud...@canonical.com> wrote:
>
>> I've updated my snaps with both these releases, so users with the snap
>> already installed should get them soon, or snap install --classic --channel
>> 1.9/stable go on an ubuntu or ubuntu-like system if you want to try them
>> out :)
>>
>> Cheers,
>> mwh
>>
>> On 26 October 2017 at 12:51, Chris Broadfoot <c...@golang.org> wrote:
>>
>>> Hi gophers,
>>>
>>> We have just released Go versions 1.9.2 and 1.8.5, minor point releases.
>>>
>>> These releases include fixes to the compiler, linker, runtime,
>>> documentation, go command, and the crypto/x509, database/sql, log, and
>>> net/smtp packages. They include a fix to a bug introduced in Go 1.9.1 and
>>> Go 1.8.4 that broke "go get" of non-Git repositories under certain
>>> conditions.
>>>
>>> View the release notes for more information:
>>> https://golang.org/doc/devel/release.html#go1.9.minor
>>>
>>> You can download binary and source distributions from the Go web site:
>>> https://golang.org/dl/
>>>
>>> To compile from source using a Git clone, update to the release with
>>> "git checkout go1.9.2" and build as usual.
>>>
>>> Thanks to everyone who contributed to the release.
>>>
>>> Chris
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [golang-dev] Subject: Go 1.9.2 and Go 1.8.5 are released

[Michael Hudson-Doyle]

I've updated my snaps with both these releases, so users with the snap
already installed should get them soon, or snap install --classic --channel
1.9/stable go on an ubuntu or ubuntu-like system if you want to try them
out :)

Cheers,
mwh

On 26 October 2017 at 12:51, Chris Broadfoot  wrote:

> Hi gophers,
>
> We have just released Go versions 1.9.2 and 1.8.5, minor point releases.
>
> These releases include fixes to the compiler, linker, runtime,
> documentation, go command, and the crypto/x509, database/sql, log, and
> net/smtp packages. They include a fix to a bug introduced in Go 1.9.1 and
> Go 1.8.4 that broke "go get" of non-Git repositories under certain
> conditions.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.9.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with "git
> checkout go1.9.2" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Set LD_LIBRARY_PATH while executing go test

[Michael Hudson-Doyle]

On 16 June 2017 at 17:46,  wrote:

> Hello,
>
> Is there a way to set the LD_LIBRARY_PATH while executing go test command?
>
> My version is "go version go1.5.1 linux/amd64"
>

No. Why do you want to?

You can set the rpath of the generated executable with something like "go
test -ldflags='-r $foo'" or "go test -ldflags=-extldflags=-Wl,-rpath=$foo"
which might be another way to solve your problem. But I'm just guessing
really.

Cheers,
mwh

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [golang-dev] Go 1.9 Beta 1 is released

[Michael Hudson-Doyle]

Do you use -skip_tests though? Because I'd be surprised if you don't and
don't hit that issue. But maybe I'm missing something.

On 15 June 2017 at 13:35, Brad Fitzpatrick <bradf...@golang.org> wrote:

> We use golang.org/x/build/cmd/release
>
>
> On Wed, Jun 14, 2017 at 6:32 PM, Michael Hudson-Doyle <
> michael.hud...@canonical.com> wrote:
>
>> I'm curious how you built your binaries with https://github.com/golang
>> /go/issues/20284 still open. Do you not run the tests on the built
>> binaries before packing them up?
>>
>> On 15 June 2017 at 10:15, Chris Broadfoot <c...@golang.org> wrote:
>>
>>> Hello gophers,
>>>
>>> We have just released go1.9beta1, a beta version of Go 1.9.
>>> It is cut from the master branch at the revision tagged go1.9beta1.
>>>
>>> There are no known problems or regressions.
>>> Please try running production load tests and your unit tests with the
>>> new version.
>>>
>>> Report any problems using the issue tracker:
>>> https://golang.org/issue/new
>>>
>>> If you have Go installed already, the easiest way to try go1.9beta1
>>> is by using this tool:
>>> https://godoc.org/golang.org/x/build/version/go1.9beta1
>>>
>>> You can download binary and source distributions from the usual place:
>>> https://golang.org/dl/#go1.9beta1
>>>
>>> To find out what has changed in Go 1.9, read the draft release notes:
>>> https://tip.golang.org/doc/go1.9
>>>
>>> Documentation for Go 1.9 is available at:
>>> https://tip.golang.org/
>>>
>>> Cheers,
>>> Chris
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [golang-dev] Go 1.9 Beta 1 is released

[Michael Hudson-Doyle]

I'm curious how you built your binaries with
https://github.com/golang/go/issues/20284 still open. Do you not run the
tests on the built binaries before packing them up?

On 15 June 2017 at 10:15, Chris Broadfoot  wrote:

> Hello gophers,
>
> We have just released go1.9beta1, a beta version of Go 1.9.
> It is cut from the master branch at the revision tagged go1.9beta1.
>
> There are no known problems or regressions.
> Please try running production load tests and your unit tests with the new
> version.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9beta1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9beta1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9beta1
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>
> Documentation for Go 1.9 is available at:
> https://tip.golang.org/
>
> Cheers,
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: About 64bits alignment

[Michael Hudson-Doyle]

On 29 March 2017 at 04:44, T L  wrote:

>
>
> On Thursday, February 2, 2017 at 12:03:59 AM UTC+8, T L wrote:
>>
>> the sync/atomic docs, https://golang.org/pkg/sync/atomic/, says in the
>> end of the docs
>>
>>
>> On x86-32, the 64-bit functions use instructions unavailable before the
>>> Pentium MMX.
>>>
>> On non-Linux ARM, the 64-bit functions use instructions unavailable
>>> before the ARMv6k core.
>>>
>>> On both ARM and x86-32, it is the caller's responsibility to arrange for
>>> 64-bit alignment of 64-bit words accessed atomically.
>>>
>>
> Does the "ARM" here include ARMv8 (64-bit)?
>

On a 64 bit platform, 64-bit integers are naturally aligned on 64 bits so
you shouldn't have to make any extra effort to arrange for it to happen.

Cheers,
mwh

> The first word in a global variable or in an allocated struct or slice can
>>> be relied upon to be 64-bit aligned.
>>>
>>
>> The last line says the first word in a global variable or in an allocated
>> struct or slice is 64-bit aligned for sure.
>> But what does an allocated struct or slice means? A struct or slice
>> allocated on heap, not stack?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go executable cross-compiled for arm5 works on amd64 (and arm5)

[Michael Hudson-Doyle]

Do you have qemu-user-static or a similarly named package installed? Then
the magic of binfmt_misc may be invoking it. For me:

$ cat /proc/sys/fs/binfmt_misc/qemu-arm
enabled
interpreter /usr/bin/qemu-arm-static
flags: OC
offset 0
magic 7f454c460101010002002800
mask ff00feff

Cheers,
mwh

On 16 February 2017 at 20:37, Dan Kortschak 
wrote:

> Can someone explain to me why this works? I am cross-compiling for
> arm5, but the executable works on amd64.
>
> $ cat hello.go
> package main
>
> import "fmt"
>
> func main() {
> fmt.Println("hello")
> }
> $ GOARCH=arm GOARM=5 go build hello.go
> $ ./hello
> hello
> $ go env
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/daniel"
> GORACE=""
> GOROOT="/home/daniel/go"
> GOTOOLDIR="/home/daniel/go/pkg/tool/linux_amd64"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-
> map=/tmp/go-build014006335=/tmp/go-build -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
> $ go version
> go version go1.7.4 linux/amd64
>
>
> The executable also works on the arm5 device. I'm not worried, but I
> don't understand how this works.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] GoLang assembly support shifted operands?

[Michael Hudson-Doyle]

It doesn't look like they're supported on arm64 though. File a bug?

Cheers,
mwh


> On 15 November 2016 at 06:26, Rob Pike  wrote:

> They are supported. Please read the ARM section of golang.org/doc/asm.html
> to see the syntax.
>
>
> On Sunday, November 13, 2016, wei.x...@arm.com 
> wrote:
>
>> I'm trying to rewrite following two ARM64 assembly instructions into
>> GoLang assembly instructions
>> add x0, x3, x6, lsr #1
>> neg x4, x4, lsl #1
>>
>> But it seems that GoLang ARM64 assembly don't support shifted operands.
>> So i need to write following 4 GoLang assembly instructions?
>> LSL $1, R4, R4
>> NEG R4, R4
>> LSR $1, R6, R6
>> ADD R6, R3, R0
>>
>>
>> My question is: GoLang assembly support shifted operands?
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 1.7.3 is released

[Michael Hudson-Doyle]

That's https://github.com/golang/go/issues/17276, which if I'd been paying
a bit more attention I'd have suggested go into 1.7.3 :( It's not an
indicator of a real problem fortunately.

Cheers,
mwh

On 20 October 2016 at 09:10, Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Oct 19, 2016 at 9:45 PM Chris Broadfoot  wrote:
>
> > We have just released Go version 1.7.3, a minor point release.
>
> Package time fails test.
>
> jnml@4670:~$ cd ~/go/src/
> jnml@4670:~/go/src$ go env
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/jnml"
> GORACE=""
> GOROOT="/home/jnml/go"
> GOTOOLDIR="/home/jnml/go/pkg/tool/linux_amd64"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build529084731=/tmp/go-build
> -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
> jnml@4670:~/go/src$ git status
> HEAD detached at go1.7.3
> nothing to commit, working directory clean
> jnml@4670:~/go/src$ ./all.bash
> # Building Go bootstrap tool.
> cmd/dist
>
> # Building Go toolchain using /home/jnml/go1.4.
> bootstrap/internal/sys
> bootstrap/asm/internal/flags
> bootstrap/internal/bio
> bootstrap/compile/internal/big
> bootstrap/internal/obj
> bootstrap/internal/gcprog
> bootstrap/internal/obj/arm
> bootstrap/internal/obj/arm64
> bootstrap/internal/obj/mips
> bootstrap/internal/obj/ppc64
> bootstrap/internal/obj/s390x
> bootstrap/internal/obj/x86
> bootstrap/asm/internal/lex
> bootstrap/link/internal/ld
> bootstrap/compile/internal/ssa
> bootstrap/asm/internal/arch
> bootstrap/asm/internal/asm
> bootstrap/asm
> bootstrap/link/internal/amd64
> bootstrap/link/internal/arm
> bootstrap/link/internal/arm64
> bootstrap/link/internal/mips64
> bootstrap/link/internal/ppc64
> bootstrap/link/internal/s390x
> bootstrap/link/internal/x86
> bootstrap/link
> bootstrap/compile/internal/gc
> bootstrap/compile/internal/amd64
> bootstrap/compile/internal/arm
> bootstrap/compile/internal/arm64
> bootstrap/compile/internal/mips64
> bootstrap/compile/internal/ppc64
> bootstrap/compile/internal/s390x
> bootstrap/compile/internal/x86
> bootstrap/compile
>
> # Building go_bootstrap for host, linux/amd64.
> runtime/internal/sys
> runtime/internal/atomic
> runtime
> encoding
> errors
> internal/race
> internal/syscall/windows/sysdll
> math
> sort
> sync/atomic
> unicode
> unicode/utf16
> unicode/utf8
> sync
> container/heap
> io
> syscall
> internal/singleflight
> bytes
> hash
> strings
> strconv
> hash/adler32
> bufio
> path
> reflect
> encoding/base64
> crypto
> regexp/syntax
> crypto/sha1
> internal/syscall/windows
> internal/syscall/windows/registry
> time
> regexp
> os
> os/signal
> path/filepath
> io/ioutil
> encoding/binary
> fmt
> context
> flag
> go/token
> log
> net/url
> text/template/parse
> compress/flate
> encoding/json
> debug/dwarf
> go/scanner
> os/exec
> go/ast
> text/template
> compress/zlib
> debug/macho
> debug/elf
> go/parser
> go/doc
> go/build
> cmd/go
>
> # Building packages and commands for linux/amd64.
> runtime/internal/sys
> runtime/internal/atomic
> runtime
> errors
> internal/race
> sync/atomic
> unicode
> unicode/utf8
> math
> sync
> sort
> io
> syscall
> hash
> hash/adler32
> bytes
> strings
> bufio
> path
> strconv
> text/tabwriter
> hash/crc32
> compress/bzip2
> container/heap
> container/list
> container/ring
> crypto/subtle
> math/rand
> time
> crypto/cipher
> reflect
> regexp/syntax
> crypto
> crypto/aes
> crypto/sha512
> crypto/hmac
> os
> crypto/md5
> internal/syscall/unix
> regexp
> crypto/rc4
> crypto/sha1
> crypto/sha256
> path/filepath
> encoding/base64
> io/ioutil
> internal/nettrace
> internal/singleflight
> encoding
> encoding/ascii85
> encoding/base32
> encoding/pem
> unicode/utf16
> vendor/golang_org/x/net/lex/httplex
> hash/crc64
> hash/fnv
> html
> image/color
> internal/syscall/windows/sysdll
> image
> image/color/palette
> runtime/debug
> encoding/binary
> fmt
> cmd/internal/sys
> crypto/des
> image/internal/imageutil
> image/draw
> image/jpeg
> index/suffixarray
> runtime/trace
> math/cmplx
> os/signal
> runtime/race
> cmd/compile/internal/test
> cmd/internal/pprof/svg
> cmd/vet/internal/whitelist
> flag
> log
> debug/dwarf
> compress/flate
> debug/gosym
> cmd/internal/obj
> debug/plan9obj
> cmd/vendor/golang.org/x/arch/arm/armasm
> compress/zlib
> cmd/vendor/golang.org/x/arch/x86/x86asm
> debug/elf
> cmd/internal/goobj
> debug/macho
> debug/pe
> archive/tar
> archive/zip
> compress/gzip
> compress/lzw
> cmd/internal/objfile
> context
> math/big
> encoding/hex
> go/token
> os/exec
> go/scanner
> cmd/addr2line
> database/sql/driver
> go/ast
> database/sql
> encoding/csv
> encoding/gob
> encoding/json
> go/parser
> crypto/dsa
> crypto/elliptic
> encoding/asn1
> crypto/rand
> go/printer
> crypto/rsa
> encoding/xml
> vendor/golang_org/x/net/http2/hpack
> crypto/ecdsa
> crypto/x509/pkix
> mime
> mime/quotedprintable
> cmd/cgo
> net/http/internal
> net/url
> text/template/parse

Re: [go-nuts] Any reason make.bash does not allow you to pass asmflags?

[Michael Hudson-Doyle]

On 19 October 2016 at 07:53, Parker Evans  wrote:

> I was recently playing around with the assembler and compiler -trimpath
> option to remove build machine prefixes from the built from source
> toolchain and I realized that make.bash allows you to pass gcflags via the
> GO_GCFLAGS environment variable but there is no equivalent GO_ASMFLAGS
> environment variable that allows you to pass -asmflags.  As properly
> trimming all the paths involves passing the -trimpath option via -asmflags
> and -gcflags, this seems to be required.  Is there another way to do this?
> Or would this be a good patch for future Go releases?
>

-asmpath is a fairly new thing (added in 1.5?) so it's probably just an
oversight.

Cheers,
mwh

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] ARM Cortex-R52 real time chip announced today

[Michael Hudson-Doyle]

On 22 September 2016 at 05:54, Ian Lance Taylor  wrote:

> On Wed, Sep 21, 2016 at 7:16 AM, Ged Wed  wrote:
> >
> > Today ARM announced a new real time chip for cars.
> >
> > http://www.anandtech.com/show/10690/arm-announces-the-
> cortexr52-cpu-deterministic-safe-for-adas-more
> >
> > https://github.com/golang/go/wiki/GoArm
> >
> > I am curious how hard it would be for golang to target this ??
> > Not that i would be anytime soon, but its seems like it would be great
> for
> > drones, robotics, and hardware that needs to be deterministic in the
> time it
> > takes to complete tasks.
>
> As far as I can see, the Go toolchain should be able to generate code
> today that will run on this processor.


I think the code might be OK (not sure how much the ISA for userland
differs between -A and -R) but I think getting the runtime to work on a
system without an MMU might be an adventure. I'm hardly an expert in such
things though!

Cheers,
mwh

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Cross-compilation of golang assembly via 'go tool asm'

[Michael Hudson-Doyle]

On 13 September 2016 at 13:43,  wrote:

> I'm implementing cross-compilation support in rules_go
> .  This takes a low-level
> approach to building golang targets that involves use of the individual
> toolchain components such as 'go tool asm', 'go tool compile', 'go tool
> link', etc...
>
> Cross-compilation of pure-go inputs is working swimmingly.  However, I'm
> wondering how to cross-compile assembly inputs correctly.  Consider the
> following assembly file that defines an 'add' method.
>
> *#include "textflag.h"*
>
> *TEXT ·add(SB),NOSPLIT,$0*
> * MOVQ x+0(FP), BX*
> * MOVQ y+8(FP), BP*
> * ADDQ BP, BX*
> * MOVQ BX, ret+16(FP)*
> * RET*
>
> For example, this works:
>
> *$ go tool asm -I $(go env GOROOT)/pkg/include -o add.o add.s*
> *$ hexdump add.o*
>
> *000 67 6f 20 6f 62 6a 65 63 74 20 64 61 72 77 69 6e*
>
> *010 20 61 6d 64 36 34 20 67 6f 31 2e 36 2e 32 0a 21*
>
> *020 0a 00 00 67 6f 31 33 6c 64 01 00 fe 02 0c 22 22*
>
> *030 2e 61 64 64 00 00 40 00 00 40 48 8b 5c 24 08 48*
>
> *040 8b 6c 24 10 48 01 eb 48 89 5c 24 18 c3 cc cc cc*
>
> *050 cc cc cc cc cc cc cc cc cc cc 00 ff ff ff ff 0f*
>
> *060 00 02 00 00 06 02 20 00 06 02 20 00 16 0a 05 02*
>
> *070 05 02 03 02 05 02 0e 00 00 02 28 22 22 2e 61 64*
>
> *080 64 2e 61 72 67 73 5f 73 74 61 63 6b 6d 61 70 00*
>
> *090 00 02 52 2f 55 73 65 72 73 2f 70 63 6a 2f 67 69*
>
> *0a0 74 68 75 62 2f 67 72 70 63 2d 67 72 65 65 74 65*
>
> *0b0 72 74 69 6d 65 72 2f 61 64 64 2e 73 02 ff ff 67*
>
> *0c0 6f 31 33 6c 64 *
>
> *0c5*
>
>
> Given the magic of "goose" and "garch" (and it is magical), I expected
> this to work:
>
> *$ env GOOS=linux GOARCH=arm go tool asm -I $(go env GOROOT)/pkg/include
> -o add.o add.s*
>
> *add.s:4: unrecognized instruction "MOVQ"*
>
> *add.s:5: unrecognized instruction "MOVQ"*
>
> *add.s:6: unrecognized instruction "ADDQ"*
>
> *add.s:7: unrecognized instruction "MOVQ"*
>
> *asm: asm: assembly of add.s failed*
>

The problem here is that MOVQ is not a valid instruction for arm.


> This was the initial issue for this post.  However, I figured that part
> out (the std library needs to be compiled first).  So this works:
>
> *$ env GOOS=linux GOARCH=arm go install std && go tool asm -I $(go env
> GOROOT)/pkg/include -o add.o add.s*
>

And here, the GOOS/GOARCH settings only apply to the first command that is
run, not the asm invocation.

Cheers,
mwh


> However, now I'm curious why whatever platform GOOS_GOARCH I choose, the
> file is exactly the same (see hexdump above).
>
> So i'm wondering why that is.  Am I doing something wrong?  If not, why
> are GOOS and GOARCH needed at all at this stage?
>
> Thanks for helping me clear this up, and thanks for golang!
> Paul
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What 5 things does Go need in 2017?

[Michael Hudson-Doyle]

On 12 September 2016 at 21:53, Dave Cheney  wrote:

> Ubuntu 12.04 LTS ships with Go 1.0.
> Ubuntu 14.04 LTS ships with Go 1.2
> Ubuntu 16.04 LTS ships with Go 1.6 (I hope)
>

Yeah, 1.6 got into 16.04.


> None of the LTS versions of Ubuntu ship with a supporter version of Go.
> This is a policy decision by Ubuntu.
>

Indeed. Updating whole new versions of things into released versions just
isn't how things are expected to work. Things are changing here (snaps,
etc) but that's where we are.


> What Go needs is an official repo, just like Chrome has.


In the mean time, there's
https://code.launchpad.net/~gophers/+archive/ubuntu/archive for your Go 1.X
versions on Ubuntu (and probably Debian, but not tested) needs.

Cheers,
mwh


> > On 12 Sep 2016, at 19:41, Russel Winder  wrote:
> >
> >> On Mon, 2016-09-12 at 17:21 +1000, Dave Cheney wrote:
> >> Distros are always out of date, sometimes hilariously. Official in my
> >> parlance means "from the go team"
> >
> > If the official distro repository is not as up-to-date as is should be
> > then fix it, either by helping the current packagers or by becoming the
> > official packagers. To ignore the official repository and yet replicate
> > exactly the same work seems significantly less than optimal.
> >
> > Debian Sid and Fedora Rawhide seem fairly up to date, at least for core
> > Go stuff.
> >
> > Though Fedora packaging of Go is somewhat at odds with the packaging of
> > GCCGo, and indeed does need fixing.
> >
> > --
> > Russel.
> > 
> =
> > Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 1.7 is released

[Michael Hudson-Doyle]

On 17 August 2016 at 08:31, Dave Cheney  wrote:
> Stripping go binaries is not tested and known to produce broken binaries.

Stripping should be fine, and any problems produced by it should be
reported as bugs. Please.

> I recommend not doing this until strip/upx/whatever are tested as part of the 
> unit tests which are run before each commit lands.

upx, on the other hand, I have no idea about.

Cheers,
mwh

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Increase speed of repeated builds

[Michael Hudson-Doyle]

On 12 August 2016 at 15:01, James Pettyjohn  wrote:
> I have a project which has become fairly large, I simple check of *.go, no
> _test files (including all modules), it's up to 1300 files.
>
> The main module though is 60 files, about 1MB of go source. It is taking to
> about 20 seconds to compile for a single change in the main module using go
> 1.6.2 darwin/amd64.
>
> Using -x on go install I'm seeing half the time on build and half the time
> on linking.
>
> I think I've gotten all the direct CGO dependencies moved to submodules but
> I'm not sure what would indicates if it is going through a cgo phase or not.
>
> Any input on other things to look for or tune on what is making the build
> time so long?

1.7 should be much faster (the linker is about 3 times faster on some
things I tried).

Cheers,
mwh

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.