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: go 1.9.4 cgo issue: invalid flag in #cgo LDFLAGS #23739

Closed
susugagalala opened this issue Feb 8, 2018 · 16 comments

Comments

@susugagalala
Copy link

commented Feb 8, 2018

Please answer these questions before submitting your issue. Thanks!

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

go 1.9.4

Does this issue reproduce with the latest release?

yes

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

macOS High Sierra 10.13.3 / amd64

What did you do?

go build programusingcgo.go

What did you expect to see?

successful building process (built fine with go 1.9.3 and earlier versions)

What did you see instead?

$go build programusingcgo.go
github.com/samplepkg: invalid flag in #cgo LDFLAGS: github.com/samplepkg/mylib_darwin_amd64.a
$

@dgryski

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

Is this a public repository? Can you give more details of the cgo usage? What does the cgo directive actually say?

@raydac

This comment has been minimized.

Copy link

commented Feb 8, 2018

I have the same issue with Go 1.9.4 in my test
go build github.com/andlabs/ui: invalid flag in #cgo LDFLAGS: /home2/igorm/.mvnGoLang/.go_path/src/github.com/andlabs/ui/libui_linux_amd64.a

@rasky rasky added the WaitingForInfo label Feb 8, 2018

@rasky

This comment has been minimized.

Copy link
Member

commented Feb 8, 2018

@raydac andlabs/ui must be updated to cope with the new Go release. I've opened a bug (andlabs/ui#268).

@susugagalala we need to see the #cgo LDFLAGS line that is rejected by the compiler.

@ruiadrmartins

This comment has been minimized.

Copy link

commented Feb 8, 2018

same happened to me while trying to build miekg/pkcs11
go build github.com/miekg/pkcs11: invalid flag in #cgo LDFLAGS: -Wl,--no-as-needed

It was working fine yesterday. Reverting to go 1.9.3 solved it

@dmitris

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

@dmitris

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

workaround for github.com/miekg/pkcs11 on Linux - CGO_LDFLAGS_ALLOW='-Wl,--no-as-needed' go install (same for go test)

@pebbe

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

I have the same issue with CFLAGS in Go version 1.9.4. It was working fine in version 1.9.3.

~ go get github.com/pebbe/tokenize
go build github.com/pebbe/tokenize: invalid flag in #cgo CFLAGS: -finput-charset=UTF-8

 ~ go version
go version go1.9.4 linux/amd64

~ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/peter/go"
GORACE=""
GOROOT="/my/opt/go"
GOTOOLDIR="/my/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build312239203=/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"
@ruiadrmartins

This comment has been minimized.

Copy link

commented Feb 8, 2018

The problem has to do with this: #23672
It affects Go versions 1.8.7, 1.9.4 and 1.10rc2
Reverting to the previous version is what I'm doing now. Waiting for a better solution.

@andlabs

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

Is allowing linking to files in ${SRCDIR} out of the question? Package ui needs to link to a .res file on Windows as well (because resources + static libraries are weird; I should probably just remove the resources entirely, but that'll be a big change).

Is the pkcs11 flag (-Wl,--no-as-needed) also out of the question?

Honestly, I'd argue that packages that break with the security fix should first see if their flag can safely be whitelisted before taking action, because gcc and clang have so many disparate linker flags that package authors must assume that all of them affect compilation in a significant way. (This is a problem I have with many C build tools that try to hide those details from the programmer; I want to know exactly what my build is doing and what edge cases I would otherwise miss because of them.)

@susugagalala

This comment has been minimized.

Copy link
Author

commented Feb 8, 2018

@dgryski @rasky That was just an example. It's not an actual repository. I have too many cgo calls in my projects, all resulting in the same error messages, so I did not provide the actual code... just a sample example...
Apparently, from go 1.9.4, one cannot pass arbitrary "flags" to the linker via LDFLAGS, etc. I'm surprised, however, arbitrary "flags" can still be passed to the compiler via CFLAGS, etc.
After reading through https://golang.org/cmd/cgo/, I realised from 1.9.4, only a limited set of flags are allowed and proper regular expressions must be used. I've modified all my projects and they all now build successfully.

@pebbe

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

Why is this issue closed? It's not solved.

@dmitris

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

There is a patch for Go proposed - #23743

@andlabs

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

@susugagalala again, I suggest asking if the flags that caused your projects issues could be whitelisted. Can you tell us what they are?

(I'm genuinely concerned that people are treating these breakages as issues with Go itself, or even with the packages themselves, rather than seeing the security issue that caused it. I'm even more concerned that the solution is to just discard compiler flags with reckless abandon; compiler flags are always there for a reason, and we should exhaust all avenues before making a change to them.)

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2018

I've created an issue to collect all options that should be added to the whitelists: #23749. Please add comments there as needed; I believe that all the options mentioned in this issue are already there.

@StevenZack

This comment has been minimized.

Copy link

commented Feb 14, 2018

same problem happened when I try to build go-sciter, it works fine on Go1.9.3.

@andlabs

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2018

@StevenZack please go to #23749 to report that issue then; that's where all these are being collected.

cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739
cactus added a commit to cactus/go-camo that referenced this issue Feb 18, 2018
stop using GB, convert to dep/gox/GOPATH model
GB seems semi-abandoned, and currently doesn't cross compile with
either go-1.9.4 or go-1.10 ([bug][1]). Possibly due to the new cgo flag
whitelisting (see: [go issue: 23739][2])?

Instead:
*   require devs to put into GOPATH, as this seems unfortunately to be
    the convention the go community arrived at :(
*   use dep for vendoring
*   use gox for easy cross compilation

[1]: constabulary/gb#733
[2]: golang/go#23739

@mikioh mikioh changed the title go 1.9.4 cgo issue: invalid flag in #cgo LDFLAGS cmd/cgo: go 1.9.4 cgo issue: invalid flag in #cgo LDFLAGS Feb 21, 2018

metacoma pushed a commit to metacoma/silverkey that referenced this issue Mar 31, 2018
None
Downgrade golang to 1.9.3
UI lib doesn't support golang >= 1.9.3
More info golang/go#23739

@golang golang locked and limited conversation to collaborators Feb 21, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.