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

luna-duclos · 2016-11-04T14:16:47Z

### 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'

The text was updated successfully, but these errors were encountered:

crawshaw · 2016-11-04T14:21:18Z

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 · 2016-11-04T15:59:54Z

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 · 2016-11-04T16:55:53Z

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

luna-duclos · 2016-11-04T17:07:57Z

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 · 2016-11-04T17:22:57Z

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 · 2016-11-04T17:25:12Z

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

ianlancetaylor · 2016-11-04T19:38:19Z

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

mwhudson · 2016-11-04T20:17:33Z

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 · 2016-11-04T20:42:10Z

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.

josharian changed the title ~~Compiling position independant code with CGO_ENABLED=0 seems broken~~ cmd/cgo: compiling position independant code with CGO_ENABLED=0 seems broken Nov 4, 2016

crawshaw closed this as completed Nov 4, 2016

golang locked and limited conversation to collaborators Nov 4, 2017

gopherbot added the FrozenDueToAge label Nov 4, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

luna-duclos commented Nov 4, 2016 •

edited

Loading

crawshaw commented Nov 4, 2016

luna-duclos commented Nov 4, 2016

ianlancetaylor commented Nov 4, 2016

luna-duclos commented Nov 4, 2016

ianlancetaylor commented Nov 4, 2016

luna-duclos commented Nov 4, 2016

ianlancetaylor commented Nov 4, 2016

mwhudson commented Nov 4, 2016

crawshaw commented Nov 4, 2016

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

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

Comments

luna-duclos commented Nov 4, 2016 • edited Loading

crawshaw commented Nov 4, 2016

luna-duclos commented Nov 4, 2016

ianlancetaylor commented Nov 4, 2016

luna-duclos commented Nov 4, 2016

ianlancetaylor commented Nov 4, 2016

luna-duclos commented Nov 4, 2016

ianlancetaylor commented Nov 4, 2016

mwhudson commented Nov 4, 2016

crawshaw commented Nov 4, 2016

luna-duclos commented Nov 4, 2016 •

edited

Loading