cmd/cgo: compiling position independant code with CGO_ENABLED=0 seems broken

[luna-duclos]

### What version of Go are you using (go version)?

Linux: go version go1.7.3 linux/amd64
Windows: go version go1.7.3 windows/amd64

### What operating system and processor architecture are you using (go env)?

Linux:

GOARCH="amd64"                                                                                                                          
GOBIN=""                                                                                                                                
GOEXE=""                                                                                                                                
GOHOSTARCH="amd64"                                                                                                                      
GOHOSTOS="linux"                                                                                                                        
GOOS="linux"                                                                                                                            
GOPATH="/home/luna/src/gopath"                                                                                                          
GORACE=""                                                                                                                               
GOROOT="/usr/lib/go-1.7"                                                                                                                
GOTOOLDIR="/usr/lib/go-1.7/pkg/tool/linux_amd64"                                                                                        
CC="gcc"                                                                                                                                
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build190862436=/tmp/go-build -gno-record-gcc-switches"    
CXX="g++"                                                                                                                               
CGO_ENABLED="1"                                                                                                                         

Windows:

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:/src/gopath
set GORACE=
set GOROOT=C:\apps\Go
set GOTOOLDIR=C:\apps\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\lunad\AppData\Local\Temp\go-build133903786=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1

### What did you do?
I've tried building the following Go program:

package main

func main() {}

using the following command:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -buildmode=pie

### What did you expect to see?

I expected Go to build a position independant binary with no dependencies on libc, for use on alpine

### What did you see instead?

On linux:

luna@ssh-dev:~/src/gopath/src/test-pie$ CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -buildmode=pie
# test-pie
/usr/lib/go-1.7/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/tmp/go-link-364377506/go.o:(.data+0x0): undefined reference to `x_cgo_callers'
/tmp/go-link-364377506/go.o:(.data+0x8): undefined reference to `x_cgo_init'
/tmp/go-link-364377506/go.o:(.data+0x10): undefined reference to `x_cgo_mmap'
/tmp/go-link-364377506/go.o:(.data+0x18): undefined reference to `x_cgo_notify_runtime_init_done'
/tmp/go-link-364377506/go.o:(.data+0x20): undefined reference to `x_cgo_thread_start'
/tmp/go-link-364377506/go.o:(.data+0x28): undefined reference to `x_cgo_setenv'
/tmp/go-link-364377506/go.o:(.data+0x30): undefined reference to `x_cgo_unsetenv'
collect2: error: ld returned 1 exit status

On windows:

λ CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -buildmode=pie
# test-pie
C:\apps\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
gcc: error: unrecognized command line option '-rdynamic'

[crawshaw]

While the error message here suggests there might be some configuration bug in how we are interpreting CGO_ENABLED, I believe the underlying problem is fixed at tip. Could you try with Go build from source?

I believe that the fact that for GOOS=linux GOARCH=amd64 the 1.8 Go linker will now internally link a PIE executable means this should work.

[luna-duclos]

This works on linux! However, on windows I get the following:

λ CGO_ENABLED=0 GOOS=linux GOARCH=amd64 D:/src/gotip/bin/go.exe build -buildmode=pie
# runtime/internal/atomic
usage: asm [options] file.s
Flags:
  -D value
        predefined symbol with optional simple value -D=identifier=value; can be set multiple times
  -I value
        include directory; can be set multiple times
  -S    print assembly and machine code
  -debug
        dump instructions as they are parsed
  -dynlink
        support references to Go symbols defined in other shared libraries
  -e    no limit on number of errors reported
  -o string
        output file; default foo.6 for /a/b/c/foo.s on amd64
  -shared
        generate code that can be linked into a shared library
  -trimpath string
        remove prefix from recorded source file paths

It looks like the asm tool is being invoked incorrectly perhaps ?

[ianlancetaylor]

Can you add -x at the end of your command line and show the output?

[luna-duclos]

Yes, this is the output:

λ CGO_ENABLED=0 GOOS=linux GOARCH=amd64 D:/src/gotip/bin/go.exe build -buildmode=pie -x
WORK=C:\Users\lunad\AppData\Local\Temp\go-build859552542
mkdir -p $WORK\runtime\internal\sys\_obj\
mkdir -p $WORK\runtime\internal\
cd C:\apps\Go\src\runtime\internal\sys
"C:\\apps\\Go\\pkg\\tool\\windows_amd64\\compile.exe" -o "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542\\runtime\\internal\\sys.a" -trimpath "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542" -shared -p runtime/internal/sys -+ -complete -installsuffix shared -buildid e02ac541ede9178615f25062613ec0478a3cebfc -D _/C_/apps/Go/src/runtime/internal/sys -I "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542" -pack "C:\\apps\\Go\\src\\runtime\\internal\\sys\\arch.go" "C:\\apps\\Go\\src\\runtime\\internal\\sys\\arch_amd64.go" "C:\\apps\\Go\\src\\runtime\\internal\\sys\\intrinsics.go" "C:\\apps\\Go\\src\\runtime\\internal\\sys\\stubs.go" "C:\\apps\\Go\\src\\runtime\\internal\\sys\\sys.go" "C:\\apps\\Go\\src\\runtime\\internal\\sys\\zgoarch_amd64.go" "C:\\apps\\Go\\src\\runtime\\internal\\sys\\zgoos_linux.go" "C:\\apps\\Go\\src\\runtime\\internal\\sys\\zversion.go"
mkdir -p $WORK\runtime\internal\atomic\_obj\
cd C:\apps\Go\src\runtime\internal\atomic
"C:\\apps\\Go\\pkg\\tool\\windows_amd64\\compile.exe" -o "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542\\runtime\\internal\\atomic.a" -trimpath "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542" -shared -p runtime/internal/atomic -+ -installsuffix shared -buildid 5608f151f29b48e16ec0c6747c0da1bc72df904d -D _/C_/apps/Go/src/runtime/internal/atomic -I "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542" -pack -asmhdr "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542\\runtime\\internal\\atomic\\_obj\\go_asm.h" "C:\\apps\\Go\\src\\runtime\\internal\\atomic\\atomic_amd64x.go" "C:\\apps\\Go\\src\\runtime\\internal\\atomic\\stubs.go"
"C:\\apps\\Go\\pkg\\tool\\windows_amd64\\asm.exe" -o "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542\\runtime\\internal\\atomic\\_obj\\asm.o" -trimpath "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542" -I "C:\\Users\\lunad\\AppData\\Local\\Temp\\go-build859552542\\runtime\\internal\\atomic\\_obj\\" -I "C:\\apps\\Go\\pkg\\include" -D GOOS_linux -D GOARCH_amd64 -shared "C:\\apps\\Go\\src\\runtime\\internal\\atomic\\asm.s" "C:\\apps\\Go\\src\\runtime\\internal\\atomic\\asm_amd64.s"
# runtime/internal/atomic
usage: asm [options] file.s
Flags:
  -D value
        predefined symbol with optional simple value -D=identifier=value; can be set multiple times
  -I value
        include directory; can be set multiple times
  -S    print assembly and machine code
  -debug
        dump instructions as they are parsed
  -dynlink
        support references to Go symbols defined in other shared libraries
  -e    no limit on number of errors reported
  -o string
        output file; default foo.6 for /a/b/c/foo.s on amd64
  -shared
        generate code that can be linked into a shared library
  -trimpath string
        remove prefix from recorded source file paths

[ianlancetaylor]

The usage error is occurring because the go tool is passing both asm.s and asm_amd64.s to a single invocation of the asm tool. The asm tool only takes a single input file. But I really can't imagine what would cause the go tool to do that.

I do notice that you are running D:/src/gotip/bin/go.exe but the assembler it is invoking is C:\apps\Go\pkg\tool\windows_amd64\asm.exe. Do you have GOROOT set in the environment? If you do, unset it. And make sure you are running the right version of the go tool.

[luna-duclos]

Good catch ... Unsetting GOROOT fixes this issue, though I'm unsure as to why oO

[ianlancetaylor]

Is there still an issue here, or should we close this?

[mwhudson]

sent from my phone, please excuse brevity

On 5 Nov 2016 06:23, "Ian Lance Taylor" notifications@github.com wrote:

The usage error is occurring because the go tool is passing both asm.s
and asm_amd64.s to a single invocation of the asm tool. The asm tool only
takes a single input file. But I really can't imagine what would cause the
go tool to do that.

I think the assembler can process multiple files in one invocation at tip,
so this looks like go tool/asm version skew (for other reasons as well)

[crawshaw]

There is no bug at tip. And while CGO_ENABLED=0 is not the same as internal linking, the two concepts are close enough that I think it's reasonable that buildmode=pie in 1.7 requires cgo. So I'm closing this. @PSG-Luna please reply to this if you still think there's a bug here.