cgo tests fails with sandboxing

[damienmg]

See http://ci.bazel.io/job/rules_go/BAZEL_VERSION=HEAD,PLATFORM_NAME=ubuntu_15.10-x86_64/39/console

This is after merging #10

/cc @yugui

[yugui]

@damienmg I've started to investigate this issue.

• Is there any way to run these CI builds without merging PR?
• Do you have any idea about that it is failing only in ubuntu 15.10? I can't reproduce it in ubuntu 14.04 with Bazel 0.2.1.

• There is another failure in OSX. http://ci.bazel.io/job/rules_go/BAZEL_VERSION=HEAD,PLATFORM_NAME=darwin-x86_64/39/console

  It looks to be this bug in ld(1). Unfortunately I cannot reproduce the issue in El Capitan with XCode 7.3.

  BTW, what is the version of OSX and XCode in the CI environment?

[damienmg]

• Not yet sorry, I am working on it but it requires to scale our CI a bit and it has been side tracked by other more urgent things right now.
• No idea I guess the gcc/ld version
• Oh yes sorry I mis read the result of breakage. it indeed has nothing to do with sandboxing:
  • Darwin is El Capitan: http://ci.bazel.io/computer/darwin-x86_64-2/systemInfo
  • I don't have the Xcode version, I could probably check but it's kind of hard. gcc -version returns:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1

Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix

[yugui]

Thank you, @damienmg

For the failure on OSX, three possible workarounds come to my mind. Which one do you prefer?

1. Upgrade XCode in the CI environment
2. Add /usr/bin to $PATH
3. Add a workaround in osx_cc_wrapper.sh

Let me explain more background behind the three workarounds.

1. In my El Capitan environment, gcc is newer than the CI environment. So we can expect the bug is fixed in the newer XCode.

   $ gcc --version
   Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
   Apple LLVM version 7.3.0 (clang-703.0.29)
   Target: x86_64-apple-darwin15.3.0
   Thread model: posix
   InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
   $ ld -v
   @(#)PROGRAM:ld  PROJECT:ld64-264.3.101
   configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
   LTO support using: LLVM version 7.3.0

2. As discussed in the bug report for ld(1), we need to stop passing -s flag to gcc as a workaround if we keep using the XCode vesion in the CI environment.

   Usually we could do it by removing -s flag from go tool link (cmd/link/internal/ld/lib.go#L1071).

   On the other hand, go tool link without -s expects that dsymutil is available on $PATH (cmd/link/internal/ld/lib.go#L1243). So /usr/bin must be listed in $PATH.

3. Another possible solution is to filter out the -s flag in osx_cc_wrapper.sh depending on the version of ld. This solution can avoid the potential similar issue in cc_binary.

[damienmg]

osx_cc_wrapper.sh should not change the argument. Add /usr/bin to $PATH for this precise action seems ok to me (updating xcode would not fix the underlying bug)

[yugui]

@damienmg Could you take a look at #13?

I reproduced the issue on Ubuntu 15.04 (GNU ld 2.25) and on Mac OS X (XCode 7.1 and 7.2). Then I confirmed that #13 fixed the issue.

[damienmg]

fyi the build is blue again \o/ Thanks!

[yugui]

Thank you for your help!