date:20200330

Re: [go-nuts] Re: Mem-Leak in Go method

2020-03-30 Thread Tamás Gulácsi


2020. március 30., hétfő 19:44:05 UTC+2 időpontban Nitish Saboo a 
következőt írta:
>
> Hi,
>
> Requesting valuable inputs on this.
>
> Thanks,
> Nitish
>
> On Thu, Mar 26, 2020 at 5:08 PM Nitish Saboo  > wrote:
>
>> Hi Tamas,
>>
>> 1) There is no such option '--heap_inuse'. We have an -*-inuse_space* 
>> option. Is this what you are talking about?
>>
>> nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof --inuse_space main 
>> mem3.prof 
>> Fetched 1 source profiles out of 2
>> File: main
>> Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
>> Type: inuse_space
>> Time: Mar 22, 2020 at 6:32am (PDT)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) o
>>   call_tree = false
>>   compact_labels= true 
>>   cumulative= flat //: [cum | flat]
>>   divide_by = 1
>>   drop_negative = false
>>   edgefraction  = 0.001
>>   focus = ""   
>>   granularity   = filefunctions//: [addresses | 
>> filefunctions | files | functions | lines]
>>   hide  = ""   
>>   ignore= ""   
>>   mean  = false
>>   nodecount = -1   //: default
>>   nodefraction  = 0.005
>>   noinlines = false
>>   normalize = false
>>   output= ""   
>>   prune_from= ""   
>>   relative_percentages  = false
>>   sample_index  = inuse_space  //: [alloc_objects | 
>> alloc_space | inuse_objects | inuse_space]
>>   show  = ""   
>>   show_from = ""   
>>   tagfocus  = ""   
>>   taghide   = ""   
>>   tagignore = ""   
>>   tagshow   = ""   
>>   trim  = true 
>>   trim_path = ""   
>>   unit  = minimum   
>>
>>  2) When I don't pass the flag it defaults to *--inuse_space*:
>>
>> File: main
>> Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
>> Type: inuse_space
>> Time: Mar 22, 2020 at 6:32am (PDT)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) top
>> Showing nodes accounting for 3303.21kB, 100% of 3303.21kB total
>> Showing top 10 nodes out of 28
>>   flat  flat%   sum%cum   cum%
>>  1762.94kB 53.37% 53.37%  1762.94kB 53.37%  runtime/pprof.StartCPUProfile
>>   516.01kB 15.62% 68.99%   516.01kB 15.62% 
>>  runtime/pprof.(*profMap).lookup
>>   512.19kB 15.51% 84.50%   512.19kB 15.51%  runtime.malg
>>   512.08kB 15.50%   100%   512.08kB 15.50% 
>>  crypto/x509/pkix.(*Name).FillFromRDNSequence
>>  0 0%   100%   512.08kB 15.50%  crypto/tls.(*Conn).Handshake
>>  0 0%   100%   512.08kB 15.50% 
>>  crypto/tls.(*Conn).clientHandshake
>>  0 0%   100%   512.08kB 15.50% 
>>  crypto/tls.(*Conn).verifyServerCertificate
>>  0 0%   100%   512.08kB 15.50% 
>>  crypto/tls.(*clientHandshakeState).doFullHandshake
>>  0 0%   100%   512.08kB 15.50% 
>>  crypto/tls.(*clientHandshakeState).handshake
>>  0 0%   100%   512.08kB 15.50% 
>>  crypto/x509.(*CertPool).AppendCertsFromPEM
>>
>> Please correct me if I am missing something here.
>>
>> Thanks,
>> Nitish
>>
>>
>>>
" Showing nodes accounting for 3303.21kB, 100% of 3303.21kB total"

means Go has occupies only about 3.3MB of memory - if you see waay more 
RSS, than its somewhere else.
If you use cgo, than that's the principal suspect. I mean your C code.

Tamás

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/06b987a8-230b-4b66-bd9f-9805f9277ddd%40googlegroups.com.

Re: [go-nuts] Recommended way to prevent my project being built with an old Go version?

2020-03-30 Thread Ian Lance Taylor

On Mon, Mar 30, 2020 at 6:22 PM Tom Payne  wrote:
>
> Go's backwards compatibility guarantee is fantastic, but only applies to the 
> language, not the standard library. How to I cause a build-time failure if 
> someone tries to build my project with a too-old Go version?

Pedantically, I would say that Go's backward compatibility does apply
to the standard library, but that what you are talking about is
forward compatibility.


> I have a Go project that uses (or would like to use) a few features 
> introduced in the standard library more recently, e.g. the %w verb in 
> fmt.Errorf for wrapping errors (introduced in Go 1.13), and a fix to the 
> text/template library (merged for Go 1.14). The nature of these features and 
> fixes mean that my code will compile and build fine, but will fail at runtime 
> when a codepath that relies on the feature or fix is executed, which will 
> result in a late, weird error. I would like an early, loud failure at build 
> time instead.
>
> What's the best way to achieve this? As far as I can tell, there are a few 
> options:
>
>
> The Go version can be determined by either the runtime.Version() function or 
> by the presence of build flags (e.g. go1.13, go1.14, etc.).
>
>
> Calling runtime.Version() cannot result in a build time error (it can only be 
> called once the code is running, which can only happen after a successful 
> build) but could be used in either a test (so the old Go version gets caught 
> when "go test" is run) or in an init() function to (say) panic on startup 
> when tests or the program are run. This would look something like:
>
> import "runtime"
>
> func init() {
> if runtime.Version() < "1.13" { // string comparisons are not a good 
> way to compare version strings, but you get the idea
> panic("go version too old")
> }
> }
>
>
> I can create a Go file with build flags that is only built on older versions 
> of Go, something like:
>
> // +build !go1.13
>
> build with go 1.13 or later // this is deliberately not valid go syntax
>
> This causes an error if built with an earlier version of Go than 1.13, but 
> the error message isn't very intuitive (something like "filename.go:3:1: 
> expected 'package', found build") and the invalid Go syntax might confuse 
> other Go tooling which tends to assume that every .go file contains 
> more-or-less valid Go code.
>
>
> Please note that I want to use these Go standard library features and fixes 
> and provide an early, loud warning if they are not available. I know that I 
> can use build flags to provide different code to different Go versions, but 
> if I do that then I still have to maintain code for older Go versions. The 
> core of this question is: how do I get a build error if my Go version is too 
> old?
>
>
> What's the recommended way to ensure a minimum Go version at build time? One 
> of the above suggestions or another way?


I think that most people use build tags, but instead of introducing a
compilation error, they either provide reduced functionality when
built with older Go versions, or they write something like

const s = "this package requires Go 1.14" + 0

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVU4bvAwjRARnSc8B%2BdW55k1k7k8JT3K_Kp7TpyRHkEiA%40mail.gmail.com.

[go-nuts] Recommended way to prevent my project being built with an old Go version?

2020-03-30 Thread Tom Payne

Hi,

Go's backwards compatibility guarantee is fantastic, but only applies to 
the language, not the standard library. How to I cause a build-time failure 
if someone tries to build my project with a too-old Go version?

I have a Go project that uses (or would like to use) a few features 
introduced in the standard library more recently, e.g. the %w verb in 
fmt.Errorf for wrapping errors (introduced in Go 1.13 
), and a fix to the 
text/template library (merged for Go 1.14 
). The nature of these features 
and fixes mean that my code will compile and build fine, but will fail at 
runtime when a codepath that relies on the feature or fix is executed, 
which will result in a late, weird error. I would like an early, loud 
failure at build time instead.

What's the best way to achieve this? As far as I can tell, there are a few 
options:


The Go version can be determined by either the runtime.Version() function 
or by the presence of build flags (e.g. go1.13, go1.14, etc.).


Calling runtime.Version() cannot result in a build time error (it can only 
be called once the code is running, which can only happen after a 
successful build) but could be used in either a test (so the old Go version 
gets caught when "go test" is run) or in an init() function to (say) panic 
on startup when tests or the program are run. This would look something 
like:

import "runtime"

func init() {
if runtime.Version() < "1.13" { // string comparisons are not a 
good way to compare version strings, but you get the idea
panic("go version too old")
}
}


I can create a Go file with build flags that is only built on older 
versions of Go, something like:

// +build !go1.13

build with go 1.13 or later // this is deliberately not valid go syntax

This causes an error if built with an earlier version of Go than 1.13, but 
the error message isn't very intuitive (something like "filename.go:3:1: 
expected 'package', found build") and the invalid Go syntax might confuse 
other Go tooling which tends to assume that every .go file contains 
more-or-less valid Go code.


Please note that I want to use these Go standard library features and fixes 
and provide an early, loud warning if they are not available. I know that I 
can use build flags to provide different code to different Go versions, but 
if I do that then I still have to maintain code for older Go versions. The 
core of this question is: how do I get a build error if my Go version is 
too old?


What's the recommended way to ensure a minimum Go version at build time? 
One of the above suggestions or another way?

Many thanks,
Tom



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7c9f2948-4187-4ccf-aebe-c524965a8be4%40googlegroups.com.

Re: [go-nuts] Re: Mem-Leak in Go method

2020-03-30 Thread Robert Engels

It has already been answered. The alloc size is not the mem in use heap size. 

> On Mar 30, 2020, at 12:43 PM, Nitish Saboo  wrote:
> 
> 
> Hi,
> 
> Requesting valuable inputs on this.
> 
> Thanks,
> Nitish
> 
>> On Thu, Mar 26, 2020 at 5:08 PM Nitish Saboo  
>> wrote:
>> Hi Tamas,
>> 
>> 1) There is no such option '--heap_inuse'. We have an --inuse_space option. 
>> Is this what you are talking about?
>> 
>> nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof --inuse_space main mem3.prof 
>> Fetched 1 source profiles out of 2
>> File: main
>> Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
>> Type: inuse_space
>> Time: Mar 22, 2020 at 6:32am (PDT)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) o
>>   call_tree = false
>>   compact_labels= true 
>>   cumulative= flat //: [cum | flat]
>>   divide_by = 1
>>   drop_negative = false
>>   edgefraction  = 0.001
>>   focus = ""   
>>   granularity   = filefunctions//: [addresses | 
>> filefunctions | files | functions | lines]
>>   hide  = ""   
>>   ignore= ""   
>>   mean  = false
>>   nodecount = -1   //: default
>>   nodefraction  = 0.005
>>   noinlines = false
>>   normalize = false
>>   output= ""   
>>   prune_from= ""   
>>   relative_percentages  = false
>>   sample_index  = inuse_space  //: [alloc_objects | 
>> alloc_space | inuse_objects | inuse_space]
>>   show  = ""   
>>   show_from = ""   
>>   tagfocus  = ""   
>>   taghide   = ""   
>>   tagignore = ""   
>>   tagshow   = ""   
>>   trim  = true 
>>   trim_path = ""   
>>   unit  = minimum   
>> 
>>  2) When I don't pass the flag it defaults to --inuse_space:
>> 
>> File: main
>> Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
>> Type: inuse_space
>> Time: Mar 22, 2020 at 6:32am (PDT)
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) top
>> Showing nodes accounting for 3303.21kB, 100% of 3303.21kB total
>> Showing top 10 nodes out of 28
>>   flat  flat%   sum%cum   cum%
>>  1762.94kB 53.37% 53.37%  1762.94kB 53.37%  runtime/pprof.StartCPUProfile
>>   516.01kB 15.62% 68.99%   516.01kB 15.62%  runtime/pprof.(*profMap).lookup
>>   512.19kB 15.51% 84.50%   512.19kB 15.51%  runtime.malg
>>   512.08kB 15.50%   100%   512.08kB 15.50%  
>> crypto/x509/pkix.(*Name).FillFromRDNSequence
>>  0 0%   100%   512.08kB 15.50%  crypto/tls.(*Conn).Handshake
>>  0 0%   100%   512.08kB 15.50%  
>> crypto/tls.(*Conn).clientHandshake
>>  0 0%   100%   512.08kB 15.50%  
>> crypto/tls.(*Conn).verifyServerCertificate
>>  0 0%   100%   512.08kB 15.50%  
>> crypto/tls.(*clientHandshakeState).doFullHandshake
>>  0 0%   100%   512.08kB 15.50%  
>> crypto/tls.(*clientHandshakeState).handshake
>>  0 0%   100%   512.08kB 15.50%  
>> crypto/x509.(*CertPool).AppendCertsFromPEM
>> 
>> Please correct me if I am missing something here.
>> 
>> Thanks,
>> Nitish
>> 
>> 
>>> On Wed, Mar 25, 2020 at 12:16 AM Tamás Gulácsi  wrote:
>>> You've requested the total allocated space (--alloc_space), not only the 
>>> heap used (--heap_inuse, or no flag).
>>> So that 17GiB is the total allocated size, does NOT include the released!
>>> 
>>> 2020. március 24., kedd 15:16:46 UTC+1 időpontban Nitish Saboo a következőt 
>>> írta:
 
 Hi,
 
 I have already gone through those links. They helped me to gather the mem 
 profile and while analyzing the data(as given in those links) I have come 
 across the following issue:
 
 While I was running the service for 100 minutes the 'top' command output 
 was showing Mem% as 11.1. There was no increase in mem usage since I had 
 not called 'LoadPatternDB()' method. I have 8GB of memory on the node 
 where I am running the service. My issue is :
 
 Why is it showing memory accounting for around 17GB?  11.1 % of 8GB is 
 .88GB and my node is only of 8GB. I feel the way I gathered the mem 
 profiling was not correct ..is it ?
 Please let me know where am I going wrong?
 
 Thanks,
 Nitish
 
> On Tue, Mar 24, 2020 at 5:32 PM Nitish

Re: [go-nuts] Re: Mem-Leak in Go method

2020-03-30 Thread Nitish Saboo

Hi,

Requesting valuable inputs on this.

Thanks,
Nitish

On Thu, Mar 26, 2020 at 5:08 PM Nitish Saboo 
wrote:

> Hi Tamas,
>
> 1) There is no such option '--heap_inuse'. We have an -*-inuse_space*
> option. Is this what you are talking about?
>
> nsaboo@ubuntu:~/Desktop/memprof$ go tool pprof --inuse_space main
> mem3.prof
> Fetched 1 source profiles out of 2
> File: main
> Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
> Type: inuse_space
> Time: Mar 22, 2020 at 6:32am (PDT)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) o
>   call_tree = false
>   compact_labels= true
>   cumulative= flat //: [cum | flat]
>   divide_by = 1
>   drop_negative = false
>   edgefraction  = 0.001
>   focus = ""
>   granularity   = filefunctions//: [addresses |
> filefunctions | files | functions | lines]
>   hide  = ""
>   ignore= ""
>   mean  = false
>   nodecount = -1   //: default
>   nodefraction  = 0.005
>   noinlines = false
>   normalize = false
>   output= ""
>   prune_from= ""
>   relative_percentages  = false
>   sample_index  = inuse_space  //: [alloc_objects |
> alloc_space | inuse_objects | inuse_space]
>   show  = ""
>   show_from = ""
>   tagfocus  = ""
>   taghide   = ""
>   tagignore = ""
>   tagshow   = ""
>   trim  = true
>   trim_path = ""
>   unit  = minimum
>
>  2) When I don't pass the flag it defaults to *--inuse_space*:
>
> File: main
> Build ID: 99b8f2b91a4e037cf4a622aa32f2c1866764e7eb
> Type: inuse_space
> Time: Mar 22, 2020 at 6:32am (PDT)
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top
> Showing nodes accounting for 3303.21kB, 100% of 3303.21kB total
> Showing top 10 nodes out of 28
>   flat  flat%   sum%cum   cum%
>  1762.94kB 53.37% 53.37%  1762.94kB 53.37%  runtime/pprof.StartCPUProfile
>   516.01kB 15.62% 68.99%   516.01kB 15.62%  runtime/pprof.(*profMap).lookup
>   512.19kB 15.51% 84.50%   512.19kB 15.51%  runtime.malg
>   512.08kB 15.50%   100%   512.08kB 15.50%
>  crypto/x509/pkix.(*Name).FillFromRDNSequence
>  0 0%   100%   512.08kB 15.50%  crypto/tls.(*Conn).Handshake
>  0 0%   100%   512.08kB 15.50%
>  crypto/tls.(*Conn).clientHandshake
>  0 0%   100%   512.08kB 15.50%
>  crypto/tls.(*Conn).verifyServerCertificate
>  0 0%   100%   512.08kB 15.50%
>  crypto/tls.(*clientHandshakeState).doFullHandshake
>  0 0%   100%   512.08kB 15.50%
>  crypto/tls.(*clientHandshakeState).handshake
>  0 0%   100%   512.08kB 15.50%
>  crypto/x509.(*CertPool).AppendCertsFromPEM
>
> Please correct me if I am missing something here.
>
> Thanks,
> Nitish
>
>
> On Wed, Mar 25, 2020 at 12:16 AM Tamás Gulácsi 
> wrote:
>
>> You've requested the total allocated space (--alloc_space), not only the
>> heap used (--heap_inuse, or no flag).
>> So that 17GiB is the total allocated size, does NOT include the released!
>>
>> 2020. március 24., kedd 15:16:46 UTC+1 időpontban Nitish Saboo a
>> következőt írta:
>>>
>>> Hi,
>>>
>>> I have already gone through those links. They helped me to gather the
>>> mem profile and while analyzing the data(as given in those links) I have
>>> come across the following issue:
>>>
>>> While I was running the service for 100 minutes the 'top' command output
>>> was showing Mem% as 11.1. There was no increase in mem usage since I had
>>> not called 'LoadPatternDB()' method. I have 8GB of memory on the node where
>>> I am running the service. My issue is :
>>>
>>>
>>>- Why is it showing memory accounting for around 17GB?  11.1 % of
>>>8GB is .88GB and my node is only of 8GB. I feel the way I gathered the 
>>> mem
>>>profiling was not correct ..is it ?
>>>
>>> Please let me know where am I going wrong?
>>>
>>> Thanks,
>>> Nitish
>>>
>>> On Tue, Mar 24, 2020 at 5:32 PM Nitish Saboo 
>>> wrote:
>>>
 Hi,

 >>There is no root analysis available in Go. Read the paper I linked
 to.

 Sorry I did not get you. Which paper are you referring to?

 While I was running the service for 100 minutes the 'top' command
 output was showing Mem% as 11.1. There was no increase in mem usage since I
 had not called 'LoadPatternDB()' method.I have 8GB of memory on the node
 where I am running the service. My issue is :


- Why is it showing memory accounting for around 17GB?  11.1 % of
8GB is .88GB and my node is only of 8GB. I feel the way I gathered the 
 mem
profiling was not correct

Re: [go-nuts] Fresh install of go from here: https://golang.org/doc/install but errors out with: import path does not begin with hostname

2020-03-30 Thread Ian Lance Taylor

On Mon, Mar 30, 2020 at 10:18 AM  wrote:
>
> Hi everyone,
>
> hoping someone can help.
>
> I did a brand new install of 'go' using the instructions from here: 
> https://golang.org/doc/install
>
> I have no knowlege of 'go' but thought I would take a look.
>
> I tried to install some software from another source using the command given:
>
> go get github.com/linkedin/Burrow
>
> And all I get is a load of errors about the import path not beginning with 
> the hostname, and nothing to help fix it?
>
> I have googled this issue, and the responses are somewhat confusing to say 
> the least.  Some solutions about unsetting go path etc, etc.
>
> I tried this.
>
> unset GOROOT
>
> But it does not help.
>
> This is the output from running go env.
>
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/root/.cache/go-build"
> GOENV="/root/.config/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOINSECURE=""
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/root/go"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct;
> GOROOT="/usr/local/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD=""
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build039360015=/tmp/go-build 
> -gno-record-gcc-switches"
>
>
>
> As a newbie to 'go' I expected it to work out of the box and was not 
> expecting a load of errors and no hint of what is wrong.
>
> Can anyone help please, I am now stuck.

Please show us the exact command that you ran and the exact output
that you got.  Thanks.

Ian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU8xvj_uhKPVs-M7QRy2kJNj6jUz1yRrDkOxvu_fVPTOw%40mail.gmail.com.

[go-nuts] Fresh install of go from here: https://golang.org/doc/install but errors out with: import path does not begin with hostname

2020-03-30 Thread pgoudman

Hi everyone,

hoping someone can help.

I did a brand new install of 'go' using the instructions from here: 
https://golang.org/doc/install

I have no knowlege of 'go' but thought I would take a look.

I tried to install some software from another source using the command 
given: 

go get github.com/linkedin/Burrow

And all I get is a load of errors about the import path not beginning with 
the hostname, and nothing to help fix it?

I have googled this issue, and the responses are somewhat confusing to say 
the least.  Some solutions about unsetting go path etc, etc.

I tried this.

unset GOROOT

But it does not help.

This is the output from running go env.

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct;
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 -fdebug-prefix-map=/tmp/go-build039360015=/tmp/go-build 
-gno-record-gcc-switches"



As a newbie to 'go' I expected it to work out of the box and was not 
expecting a load of errors and no hint of what is wrong.

Can anyone help please, I am now stuck.



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/07277736-b9e3-401e-b6fe-360ff7378128%40googlegroups.com.

Re: [go-nuts] Re: Mem-Leak in Go method

Re: [go-nuts] Recommended way to prevent my project being built with an old Go version?

[go-nuts] Recommended way to prevent my project being built with an old Go version?

Re: [go-nuts] Re: Mem-Leak in Go method

Re: [go-nuts] Re: Mem-Leak in Go method

Re: [go-nuts] Fresh install of go from here: https://golang.org/doc/install but errors out with: import path does not begin with hostname

[go-nuts] Fresh install of go from here: https://golang.org/doc/install but errors out with: import path does not begin with hostname

7 matches

Site Navigation

Mail list logo

Footer information