Note that you are misreading the strace output. The strace is blocking on the waitid or futex call, and then the program prints an error message. For Go programs you must always use strace -f, and that will likely give you clearer output.

In general symbolic links are problematic for the go tool. It needs to know the import path of a directory, and using a symbolic link breaks that. I don't know if this particular case can be handled better.

Sorry about this. The correct strace output is:

$ strace -f go fmt |& grep \.\./src | grep main.go | grep ENOENT
[pid  5595] newfstatat(AT_FDCWD, "../src/github.com/.../main.go", 0xc0000c65e8, 0) = -1 ENOENT (No such file or directory)

Note that the problem does not occut with all symlinks (some of them just work). I did not manage to identify exactly why some do and why others don't.

There have been a number of symlink-related fixes since the go1.12 release. Does this still reproduce using go1.12.6? What about a go command built from head?

(You can obtain runnable wrappers for those using go get golang.org/dl/go1.12.6 and go get golang.org/dl/gotip respectively.)

I installed go1.12.16 and it still reproduces

$ ~/bin/go1.12.6 fmt
stat ../src/github.com/.../main.go: no such file or directory
exit status 2

I have to investigate a bit further why it works with some symlinks, please leave open, I will try to find more info soon.

So I managed to reproduce on my machine...

The problem happens only when source code is in a directory called src and GOPATH points to its parent.

It happened that my sources were in an src directory in my home.
It also happened that GOPATH was set by default to my home.
It also happened that I work from a symlink of my sources.

Steps to reproduce

$ env | grep GO
GOROOT=/usr/local/go
GOPATH=/home/rof/

$ cd ~

$ mkdir -p src/alpha/bravo

$ cp /tmp/main.go ./src/alpha/bravo/

$ ln -s /home/rof/src/alpha/bravo ./link

$ cd link

$ go fmt
stat ../src/alpha/bravo/main.go: no such file or directory
exit status 2

$ ls ../src/alpha/bravo/main.go
ls: cannot access '../src/alpha/bravo/main.go': No such file or directory

$ ls ..
bravo

$ unset GOPATH

$ go fmt

Once I am in link, .. does not point to my home anymore. I think Go takes a wrong assumption here. It should not resolve the symlink in that way (or it should not resolve it at all). It should not behave differently if the source dir is called src.

Or maybe this is the intended behavior of setting GOPATH to home but this is not intuitive (it was set by default by my CI and it is hard to debug).

Thank you

Thanks. What about a go command built from head, or go1.13beta1?

File reproduce.sh

#!/bin/bash
export GOPATH=/tmp/test

gotip version

mkdir -p /tmp/test || true

cd /tmp/test

mkdir -p src/alpha/bravo

echo "package main" > ./src/alpha/bravo/main.go

ln -s /tmp/test/src/alpha/bravo ./link 2>&- || true

cd link

gotip fmt

Output

/tmp/test/reproduce.sh 
go version devel +67f181b Thu Jun 27 22:31:35 2019 +0000 linux/amd64
stat ../src/alpha/bravo/main.go: no such file or directory
exit status 2

Ran the script from @sguillia above. Can confirm the same results:

> uname -a
Linux XXXX 5.8.0-7630-generic #32~1605108806~20.10~7e52b13-Ubuntu SMP Wed Nov 11 19:10:30 UTC  x86_64 x86_64 x86_64 GNU/Linux

> lsb_release -a
Distributor ID:	Pop
Description:	Pop!_OS 20.10
Release:	20.10
Codename:	groovy

> go version
go version go1.15.6 linux/amd64

> which go
/snap/bin/go