cmd/link: Windows errors with internal linking with C objects

[tahirhassan10p]

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

go version go1.9.2 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH=amd64
GOBIN=
GOEXE=.exe
GOHOSTARCH=amd64
GOHOSTOS=windows
GOOS=windows
GOPATH=C:\gopath
GORACE=
GOROOT=C:\go
GOTOOLDIR=C:\go\pkg\tool\windows_amd64
GCCGO=gccgo
CC=C:/scripts/fips.bat
GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\ContainerAdministrator\AppData\Local\Temp\go-build167486487=/tmp/go-build -gno-record-gcc-switches
CXX=g++
CGO_ENABLED=1
CGO_CFLAGS=-g -O2
CGO_CPPFLAGS=
CGO_CXXFLAGS=-g -O2
CGO_FFLAGS=-g -O2
CGO_LDFLAGS=-g -O2
PKG_CONFIG=pkg-config

What did you do?

I want to run golang code which is importing C archive code with -ldflags "-linkmode=internal" flag.

addition.c
int addition(int a,int b) { int result; result = a + b; return result; }

multiplication.c
int multiplication(int a, int b) { int result; result = a * b; return result; }

header.h
#include <stdio.h> int addition(int a,int b); int multiplication(int a,int b);

program.go
`package main
/*
#include <stdio.h>
#include <stdlib.h>
#include "header.h"
#cgo CFLAGS: -I./
#cgo LDFLAGS: ./libarith.a

void myprint() {
int result;
result = addition(1,2);
printf("addition result is : %d\n",result);
result = multiplication(3,2);
printf("multiplication result is : %d\n",result);
}
*/
import "C"

import "fmt"

func main() {
fmt.Println("Hello world from archive")
C.myprint()
}`

Codebase is also available on (https://github.com/tahirhassan10p/GoLangInternalFlag.git).

Steps to reproduce

• Step 1: gcc -c addition.c
• Step 2: gcc -c multiplication.c
• Step 3: ar cr libarith.a addition.o multiplication.o
• Step 4: go run -ldflags "-linkmode=internal" tahir.go

What did you expect to see?

Hello world from archive
addition result is : 3
multiplication result is : 6

What did you see instead?

C:\go\pkg\tool\windows_amd64\link.exe: cannot open file "-m64 --print-libgcc-file-name"
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/libgcc.a: open "-m64 --print-libgcc-file-name"
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/libgcc.a: The filename, directory name, or volume label syntax is incorrect.

[odeke-em]

/cc @ianlancetaylor @alexbrainman

[hirochachacha]

Does external linking mode work for you?
Why do you need to use internal linking mode in the first place?

[ianlancetaylor]

That error doesn't make any sense. Can anybody recreate it? I haven't been able to, but I'm not using WIndows.

We don't promise that internal linking mode works for anything other than Go code. It's nice when it works with arbitrary C code, but there are no guarantees. Still, I don't see why or how it would fail in this way.

[hirochachacha]

On tip and go1.8, I can see

$ go run -ldflags "-linkmode=internal" program.go
# command-line-arguments
main(.text): relocation target addition not defined
main(.text): relocation target multiplication not defined
main(.text): undefined: "addition"
main(.text): undefined: "multiplication"

$ go run program.go
Hello world from archive
addition result is : 3
multiplication result is :  6

[hirochachacha]

Okay, go version go1.9.2 windows/amd64 also have the same result for me.

[tahirhassan10p]

@hirochachacha

1. Does external linking mode work for you?
   yes its working with external flag
2. Why do you need to use internal linking mode in the first place?
   actually we are working on existing application and added a dependency which is C archive file, now we are facing an error with internal flag.

Note: we are using msys2

I have also modify the git repository (https://github.com/tahirhassan10p/GoLangInternalFlag.git) and added a dockerfile.win file to make it easy to replicate the error.

[ianlancetaylor]

Why do you want to use internal linking mode?

[alexbrainman]

I can confirm this works with external linker, but does not work with internal linker. I think the problem is the ldflag #cgo LDFLAGS: ./libarith.a line that is used here. If I add -v linker flag, I can see "libarith.a" passed to external linker as a parameter. The LDFLAGS is stored in "ldflag" variable in cmd/link/internal/ld, but it is only used to pass data to external linker. I think we want it passed to internal linker too.

I will try and fix this when I have some time. I have very little free time now days, so hopefully someone will beat me to it.

Alex

[hirochachacha]

If #cgo LDFLAGS: ./libarith.a is valid, #cgo LDFLAGS: -L./ -larith also be valid.
That means we need to implement library search algorithm ourselves (on top of gcc -print-search-dirs?). It could be, but is it good enough? Someone might want to use -static, other one want to use -Wl, ... etc. I cannot understand the goal.

[ianlancetaylor]

Good point about LDFLAGS. Right now LDFLAGS is clearly for the external linker. Since the external linker and the internal linker do not take the same flags, LDFLAGS can not be for both. We shouldn't try to make it work; although we could in principle support -L, we can not support all the options that can appear there.

@tahirhassan10p Unless there is a good reason that we need to support internal linking here, I'm inclined to close this issue.

[alexbrainman]

@hirochachacha and @ianlancetaylor you are correct about LDFLAGS containing all external linker flags, not just the library list. I was too quick to post my incorrect answer, and did not think properly.

I agree, it would be too hard to parse LDFLAGS value to find libraries in there. Perhaps we could introduce new cgo variable specifically for that. Something like:

#cgo LDLIB: ./libarith.a

But maybe I am overthinking this too much. Perhaps we could just document that this is not supported with internal linker.

Leaving it for @ianlancetaylor to decide what to do here.

Alex

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)