Error on freebsd with $PWD != $(realpath $PWD)

[dropwhile]

On FreeBSD /home is often a symlink to /usr/home. This seems to not agree with gb for some reason, and I have to specify the -R path directly.

$ pwd
/home/user/projects/rollcage

$ realpath $(pwd)
/usr/home/user/projects/rollcage

$ gb build -v
DEBUG project root "/usr/home/user/projects/rollcage"
DEBUG matchPackages: /usr/home/user/projects/rollcage/src ../../../../../../home/user/projects/rollcage/...
DEBUG args: []
DEBUG removing work directory: /tmp/gb148345295
FATAL command "build" failed: no packages supplied

$ gb build -R $(realpath $(pwd)) -v
DEBUG project root "/usr/home/user/projects/rollcage"
DEBUG matchPackages: /usr/home/user/projects/rollcage/src ...
DEBUG args: [rollcage rollcage/commands]
DEBUG build duration: 15.232µs map[]
DEBUG removing work directory: /tmp/gb435798870

Using gb fetched via go get today (Oct 6).

[davecheney]

Thanks for the report. I'll look into it soon.

On Wed, 7 Oct 2015 09:11 eli notifications@github.com wrote:

On FreeBSD /home is often a symlink to /usr/home. This seems to not agree
with gb for some reason, and I have to specify the -R path directly.

$ pwd
/home/user/projects/rollcage

$ realpath $(pwd)
/usr/home/user/projects/rollcage

$ gb build -v
DEBUG project root "/usr/home/user/projects/rollcage"
DEBUG matchPackages: /usr/home/user/projects/rollcage/src ../../../../../../home/user/projects/rollcage/...
DEBUG args: []
DEBUG removing work directory: /tmp/gb148345295
FATAL command "build" failed: no packages supplied

$ gb build -R $(realpath $(pwd)) -v
DEBUG project root "/usr/home/user/projects/rollcage"
DEBUG matchPackages: /usr/home/user/projects/rollcage/src ...
DEBUG args: [rollcage rollcage/commands]
DEBUG build duration: 15.232µs map[]
DEBUG removing work directory: /tmp/gb435798870

—
Reply to this email directly or view it on GitHub
#422.

[dropwhile]

@davecheney I think I found the root cause.
In cmd/gb/main.go

cwd, err := filepath.Abs(cwd) // if cwd was passed in via -R, make sure it is absolute

It appears that filepath.Abs does not resolve symlinks on its own.
The following (added after the above line and subsequent error check) gets it to work -- but I admit to not knowing how portable it would end up being.

diff --git a/cmd/gb/main.go b/cmd/gb/main.go
index 4a5a311..469311f 100644
--- a/cmd/gb/main.go
+++ b/cmd/gb/main.go
@@ -107,12 +107,16 @@ func main() {
        args = append([]string{name}, args...)
    }
    cwd, err := filepath.Abs(cwd) // if cwd was passed in via -R, make sure it is absolute
    if err != nil {
        log.Fatalf("could not make project root absolute: %v", err)
    }
+   cwd, err = filepath.EvalSymlinks(cwd)
+   if err != nil {
+       log.Fatalf("could not resolve symlinks for project root: %v", err)
+   }

    ctx, err := cmd.NewContext(
        cwd, // project root
        gb.GcToolchain(),
        gb.Gcflags(gcflags...),
        gb.Ldflags(ldflags...),

edit: updated diff with a few more lines of context

[davecheney]

Thanks. I agree with your diagnosis. That check was added a while back. The
details escape me, but I believe it was also symlinks related, before
changing that path, I'd like to review the reason that line was added.

On Wed, 7 Oct 2015 12:56 eli notifications@github.com wrote:

@davecheney https://github.com/davecheney I think I found the root
cause.
In cmd/main.go

cwd, err := filepath.Abs(cwd) // if cwd was passed in via -R, make sure it is absolute

It appears that filepath.Abs does not resolve symlinks on its own.
The following gets it to work -- but I admit to not knowing how portable
it would end up being.

diff --git a/cmd/gb/main.go b/cmd/gb/main.go
index 4a5a311..469311f 100644
--- a/cmd/gb/main.go
+++ b/cmd/gb/main.go
@@ -110,6 +110,10 @@ func main() {
if err != nil {
log.Fatalf("could not make project root absolute: %v", err)
}

• cwd, err = filepath.EvalSymlinks(cwd)
• if err != nil {

•   log.Fatalf("could not make project root absolute: %v", err)
  

• }

ctx, err := cmd.NewContext(
cwd, // project root

—
Reply to this email directly or view it on GitHub
#422 (comment).

[dropwhile]

I updated the diff to show a bit more context, and to make it clear that resolving symlinks would be additive, not intended to replace the existing absolutification (that isn't a real word is it?!) of the path.

[dropwhile]

Forgot to mention that I am in no hurry, as I do have a valid workaround (via -R).
Thanks!

[dropwhile]

@davecheney any further thoughts on this?

[dropwhile]

Awesome. Thanks @davecheney.
Just tested on my FreeBSD box and it indeed appears to be fixed!

[davecheney]

Thanks for confirming.

On 15 Dec 2015, at 10:54, eli notifications@github.com wrote:

Awesome. Thanks @davecheney.
Just tested on my FreeBSD box and it indeed appears to be fixed!

—
Reply to this email directly or view it on GitHub.