gt; On Tue, Nov 7, 2017 at 1:28 AM, Howard Guo > wrote:
> > Just noticed this statement from src/net/net.go:
> >
> > --
> > On Unix systems, the resolver has two options for resolving names.
> > It can use a pure Go resolver that sends DN
Thanks for the info!
Kind regards,
Howard
On Tuesday, 7 November 2017 12:15:46 UTC+1, Dave Cheney wrote:
>
> Until recently some functions in the os/user package were only available
> via glibc.
>
> The net package links to cgo by default to pick up the nss libraries,
> which are important if y
Do you by any chance know what the rationale would be?
Kind regards,
Howard
On Tuesday, 7 November 2017 11:55:22 UTC+1, Dave Cheney wrote:
>
> The net and os/user packages will force dynamic linking unless
> CGO_ENABLED=0 or you are cross compiling.
--
You received this message because you ar
Thanks very much Karan, that's indeed a good approach for this challenge.
Here is the output from a dynamically linked executable:
abort
__errno_location
fprintf
fputc
free
freeaddrinfo
fwrite
gai_strerror
getaddrinfo
getnameinfo
malloc
mmap
munmap
nanosleep
pthread_attr_destroy
pthread_attr_gets
routines such as getaddrinfo and getnameinfo.
-
However, using its recommended method to force usage of Go resolver still
results in a dynamic binary:
export GODEBUG=netdns=go
Welp, have to dig deeper.
On Sunday, 5 November 2017 17:12:52 UTC+1, Howard Guo wrote:
>
>
Hello fellow gophers.
I've a small number of go programs that only use standard library functions
without any 3rd party library dependency. A strange behaviour was observed
during compilation (go build) - most of them compile into static
executable, but few of them end up linking to glibc. With
ell Hashimoto's talk from GopherCon from about 39m30s:
> https://youtu.be/8hQG7QlcLBk?t=2368
>
> http://github.com/mitchellh/go-testing-interface
>
> On Mon, Jul 24, 2017 at 1:44 AM, roger peppe > wrote:
>
>>
>>
>> On 24 July 2017 at 09:12, Howard Guo >
bug report for go:
https://github.com/golang/go/issues/21141
Kind regards,
Howard
On Sunday, 23 July 2017 06:54:28 UTC+2, Nigel Tao wrote:
>
> On Sat, Jul 22, 2017 at 7:08 PM, Howard Guo > wrote:
> > https://github.com/HouzuoGuo/laitos
>
> It's tangential to your quest
Good day fellow gophers.
Can anyone please help me to understand, why the command line help refers
to test flags (e.g. test.bench) once this program is compiled?
https://github.com/HouzuoGuo/laitos
Thanks & kind regards,
Howard
--
You received this message because you are subscribed to the Go
Hey fellow gophers.
As it is currently implemented, if http.ServerMux serves a FileServer on a
path beyond "/", for example "/mydir", and then serves a very different
document on "/", the FileServer handler will not be triggered at all and
the "/" handler gets all the requests.
Is there a work
Hey fellow Gophers.
This is a small but rather complete exercise to demonstrate writing a Go
web service that runs on AWS Lambda while retaining the capability of
running it off-cloud as a stand-alone server:
https://github.com/HouzuoGuo/optionalcloud
Features:
- Authenticate a user via usern
It is a known issue, file server treats index.html differently:
https://github.com/golang/go/issues/9876
On Tuesday, 16 August 2016 10:03:21 UTC+2, Howard Guo wrote:
>
> Hello fellow gophers.
>
> I'm starting a very trivial file server in a directory where there are
> file
Hello fellow gophers.
I'm starting a very trivial file server in a directory where there are
files called "index.html" and "LICENSE":
http.Handle("/", http.FileServer(http.Dir(".")))
It has no trouble serving file LICENSE, however, the web server always
responds with HTTP 301 when serving "ind
13 matches
Mail list logo
