Singularity: Build fails if Go workspace crosses thru symlinks

[LaHaine]

Version of Singularity:

3.1.0-640.gb368579.el7
This is on Centos 7.

Expected behavior

rpmbuild should build a rpm

Actual behavior

 GO singularity
    [+] GO_TAGS "containers_image_openpgp sylog apparmor selinux seccomp"
go: directory /tmp/waschk/rpmbuild/BUILD/singularity-3.1.0/gopath/src/github.com/sylabs/singularity/cmd/singularity outside available modules
make: *** [singularity] Error 1

Steps to reproduce behavior

Build according to the instructions, it is building fine and creating singularity-3.1.0.tar.gz. Then run rpmbuild -ta singularity-3.1.0.tar.gz

[LaHaine]

Oh well, go broke from the symlink I have, from ~/rpmbuild/BUILD to /tmp/waschk/rpmbuild/BUILD, the compiler failed there. So I guess this isn't really a bug.

[jscook2345]

@LaHaine

Is it OK to close this up or do you still have questions?

[LaHaine]

Yes, it is not a singularity bug.

[michaelkarlcoleman]

Tripped across a very similar issue just now, except that it blocks the initial 'make', with a mystifying error message:

swmgr@talapas-ln2 /packages/src/singularity/singularity-3.3.0/builddir 130$ make
go: directory /gpfs/packages/src/singularity/singularity-3.3.0/cmd/singularity outside available modules
go: directory /gpfs/packages/src/singularity/singularity-3.3.0/cmd/starter outside available modules
 GO singularity
    [+] GO_TAGS "containers_image_openpgp sylog apparmor selinux"
go: directory /gpfs/packages/src/singularity/singularity-3.3.0/cmd/singularity outside available modules
make: *** [singularity] Error 1

If it's not obvious, /packages is a symlink to /gpfs/packages. This is apparently a "feature" of Go itself, but it'd be very helpful to put a hint in the mconfig output, as many would be stymied by the mysterious error message. Thanks.

[jscook2345]

@michaelkarlcoleman

If I added something to the INSTALL.md along the lines of common build issues, would that of been of help? Or should there be more in the guides as well?

[michaelkarlcoleman]

Either would be fine. But given that mconfig spits out the command to run next, you might just add a comment right there that says something like

# yes, this full path required--go doesn't like symlinks

That's my thought, anyway.

[ekven]

Bless you, for leaving this helpful comment! Not being a Go Pro, I was stumped by this error message.

[michaelkarlcoleman]

@ekven Thanks--I'll take every blessing I can get these days. :-)

[dtrudg]

Have used something like this elsewhere as I keep bashing my head against this issue in other places :-)

if [[ "$(readlink -e ${PWD})" != "${PWD}" ]]; then
     echo "Go builds cannot be run inside a path with symlinks."
     echo "Please cd to $(readlink -e $PWD)"
     exit 1
fi

[dtrudg]

We've removed this from the milestone for 3.5, but would be glad to consider a patch if this is a painful issue for people.

[Usman095]

@LaHaine were you able to find a workaround for this?

[LaHaine]

@LaHaine were you able to find a workaround for this?

The workaround is simply to not use symlinks for the build directory.

[michaelkarlcoleman]

@LaHaine To elaborate, you can use the _physical_ name of the directory (which includes no symlinks) instead of the _logical_ name (which might). The catch is that if you ever move the symlinks around, or if they're different on different hosts sharing the directory, this won't really work.

The ultimate fix is for the Go people to fix their stuff. Not holding my breath.