Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
luna-duclos opened this issue Nov 4, 2016 · 9 comments

Comments

@luna-duclos
Copy link

luna-duclos commented Nov 4, 2016

### 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
Copy link
Member

crawshaw commented Nov 4, 2016

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
Copy link
Author

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
Copy link
Contributor

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

@luna-duclos
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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

@josharian 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
@ianlancetaylor
Copy link
Contributor

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

@mwhudson
Copy link
Contributor

mwhudson commented Nov 4, 2016

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
Copy link
Member

crawshaw commented Nov 4, 2016

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.

@crawshaw crawshaw closed this as completed Nov 4, 2016
@golang golang locked and limited conversation to collaborators Nov 4, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants