23737 은 pkg-config -libs 의해 생성된 플래그가 컴파일러 화이트리스트 및 CGO_CFLAGS_ALLOW 에 대해 검사되고 있지만 대신 링커 화이트리스트 및 CGO_LDFLAGS_ALLOW 에 대해 검사되어야 한다고 보고합니다. 이 문제를 해결하는 CL이 있습니다: https://golang.org/cl/92755.

링커 화이트리스트는 이미 .o , .so 등의 파일을 수락하므로 .a 파일을 수락해야 합니다. 이 문제를 해결하는 CL이 있습니다: https://golang.org/cl/92855. #23739 입니다.

#23672에 대한 주석은 다음 컴파일러 옵션을 나열합니다.

-fno-rtti
-fpermissive

다음 링커 옵션:

-Wl,-framework
-Wl,--no-as-needed

23742는 컴파일러 옵션 -fmodules 추가를 제안합니다. clang 컴파일러는 여러 -fmodules 옵션을 지원하지만 모두 안전한지는 확실하지 않습니다. 특히 -fmodules-cache-path 및 -fmodules-user-build-path 는 clang이 모듈을 읽는 데 사용할 경로 지정을 허용하는 것으로 보이며, 이는 다양한 방식으로 컴파일 모드를 변경할 수 있습니다.

23743은 링커 옵션 -Wl,--no-as-needed 추가를 제안합니다. 이에 대한 CL이 있습니다: https://golang.org/cl/92795.

23744는 다음 컴파일러 옵션을 추가할 것을 제안합니다.

-finput-charset=UTF-8
--std=c99
-pedantic-errors

단일 대시 또는 이중 대시와 함께 사용할 수 있는 많은 컴파일러 및 링커 옵션이 있습니다. 화이트리스트에서도 마찬가지로 느슨해야 합니다.

직교성의 경우: -framework 의 검색 경로에 디렉토리를 추가하는 옵션이 이미 적용되었는지 여부를 잊어버렸습니다. 나는 또한 그것이 어떤 옵션인지 잊어 버렸습니다. (제가 생각할 수 있는 일반적인 사용 사례는 /Library/Frameworks 입니다. 여기서 Apple은 앱별 프레임워크를 배치하고 기본적으로 검색되지 않습니다.)

또한 -as-needed 는 처음에 cgo와 함께 사용하는 것이 안전합니까? 이 블로그 게시물 ("gcc as-needed"에 대해 찾을 수 있는 첫 번째 결과임)은 이것이 위치 인수라고 말하지만 cgo가 결과 명령줄에서 플래그가 어디로 가는지 보장하는지 확신할 수 없습니다.

@andlabs 쓰기 좋아요

#cgo LDFLAGS: -Wl,--as-needed -loptlib -WL,--no-as-needed

어쨌든 이 문제의 주제는 go get 에서 옵션을 사용하는 것이 안전한지 여부입니다.

사용할 때:

#cgo !windows pkg-config: --static ${SRCDIR}/vendor/libgit2/build/libgit2.pc

다음 메시지와 함께 컴파일이 실패합니다.

invalid pkg-config package name: --static

코드를 살펴보면(go 1.9.4용) pkg-config 인수를 화이트리스트에 추가하는 데 사용할 수 있는 환경 변수가 없는 것으로 보입니다.

@rgburke pkg-config 출력은 다른 출력과 동일한 FLAGS_ALLOW 변수를 거칩니다.

그러나 나타나 pkg-config -libs 검사 CGO_CFLAGS_ALLOW 가 확인한다고 할 때 CGO_LDFLAGS_ALLOW .

우리는 폐쇄 소스 프로젝트에서 많은 수의 C 라이브러리를 정적으로 연결합니다. 지금까지 우리는 다음을 수행했습니다.

#cgo LDFLAGS:/path/to/one/liblibrary1.a
#cgo LDFLAGS:/path/to/two/liblibrary2.a
etc.

이것은 물론 지금은 허용되지 않습니다. 해결 방법:

#cgo LDFLAGS:-L/path/to/one -llibrary1
#cgo LDFLAGS:-L/path/to/two -llibrary2

그러나 이러한 디렉토리 중 일부에는 링커를 혼동시키는 동적 라이브러리도 포함되어 있습니다. 또 다른 옵션은 https://go-review.googlesource.com/c/go/+/92855 의 허용된 "이름" 목록에 '/'를 추가하는 것입니다. 특히 91행의 변경 사항은 다음과 같습니다.

re(`[a-zA-Z0-9_\/].*\.(o|obj|dll|dylib|so|a)`), // direct linker inputs: x.o or libfoo.so (but not -foo.o or @foo.o)

후자의 옵션은 문제를 해결하지만 보안에 미치는 영향에 대해서는 말할 수 없습니다.

@mirtchovski에 대한 패치가 있습니다(문제는 .a 가 화이트리스트에 없었지만 다른 개체 파일 형식은 있었습니다)

.a는 이제 (해당 패치 이후) 화이트리스트에 있으므로 'libsomething.a'는 작동하지만 '/path/to/libsomething.a'는 작동하지 않습니다.

@ianlancetaylor @rgburke 실제로 --static 동일한 문제가 발생하여 #23737로 넘어갔습니다. --static 그것을 실행하려고 시도 _before_ 유효한 패키지 이름을 것으로 나타나지 않기 때문에 거부 pkg-config 여기 https://github.com/golang/go/blob/104445e3140f4468839db49a25cb0182f7923174/src/ cmd/go/internal/work/exec.go#L939 -L940.

내부적으로 빠른 수정은 PKG_CONFIG가 단순히 pkg-config --static "$@" 를 실행하는 스크립트를 가리키도록 하는 것이었습니다.

@jeddenlea - 정말 감사합니다! 해결 방법을 찾으려고했지만 생각하지 못했습니다.

-msse 와 -msse4.2 .

cgo LDFLAGS의 "${SRCDIR}/file.o"로 이 문제를 해결했습니다.

링커 입력인 일반 파일 이름을 허용해야 한다고 주장하고 싶습니다.
LDFLAGS의 파일
(최소한 *.a, *.o 및 *.so).

이론상 "-L${SRCDIR}로 처리할 수 있는 .a 및 .so와 달리
-lname", 추가
링커 명령에 대한 추가 개체 파일은 그런 식으로 수정할 수 없습니다.

해결 방법은 CGO_LDFLAGS_ALLOW를 설정하는 것이지만 이는 매우 번거롭습니다.
또 다른
대안은 내 file.o의 이름을 file.syso로 바꾸는 것입니다.
경우에는 사용할 수 없습니다
특정 빌드 태그가 다음과 같은 경우에만 해당 file.o를 포함하기 때문에 이 옵션
포함(
빌드 태그는 #cgo LDFLAGS 프리앰블을 포함하는 파일에 적용됨) 및
방법이 없다
syso 파일 이름에 임의의 빌드 태그를 설정합니다.

이전에 배포된 Go 버전을 무시하면 다음을 포함할 수 있습니다.
새로운
링커에 더 많은 파일을 추가하기 위해 특별히 설계된 "#cgo LDLIBS"
명령줄.
그런 다음 LDLIBS에 대해 더 엄격한 규칙을 가질 수 있습니다(파일 이름만, 대시 없음
접두사에 허용됩니다.)

--std=c99 성공했습니다.

-std=c++11

내 생각에 -std=화이트리스트에 올려야 하나?

화이트리스트에 있을 가능성: -fopenmp

Go v1.10rc2를 사용하여 bimg 패키지를 빌드할 때 오류가 발생했습니다.

23:24 ~/go-test
master ms 130 % go get -v github.com/h2non/bimg
github.com/h2non/bimg (download)
github.com/h2non/bimg
go build github.com/h2non/bimg: invalid flag in pkg-config --cflags: -fopenmp

-isystem 옆에 있는 인수(경로임)가 거부되므로

또한 이 해결 방법을 사용해야 했습니다. https://github.com/golang/go/issues/23749#issuecomment -364239496

우리는 이전에:

#cgo linux LDFLAGS: ${SRCDIR}/../../../../path/to/thing/libthing_static.a

다음으로 이동했습니다.

#cgo linux LDFLAGS: -L${SRCDIR}/../../../../path/to/thing -lthing_static

.../path/to/thing 은 ${SRCDIR} 있습니다.

이 문제를 해결하려면 SRCDIR 확장이 필요한 libthing.a 참조가 있는 예제가 포함되도록 이 주석을 추가합니다.

OSX에서 cgo 플래그 제한이 있는 새로 발행된 go1.9.4에서 링커에 링크할 아카이브가 무엇인지 구체적으로 지시했습니다. (여기에서는 https://github.com/gijit/gi/blob/master/vendor/ github.com/glycerine/golua/lua/lua.go#L10 )

~~~

cgo LDFLAGS: ${SRCDIR}/../../../LuaJIT/LuaJIT/src/libluajit.a -lm -ldl

~~~

빌드 시도 시 생성:

~빌드하다- govitviters 빌드 -ldflags "-X main.LastGitCommitHash=30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp=2018-02-09T22:49:48+0700 -X main.Git =go_version_go1.9.4_darwin/amd64" -o 기빌드 github.com/gijit/gi/vendor/github.com/glycerine/golua/lua: #cgo LDFLAGS의 잘못된 플래그: /Users/jaten/go/src/github.com/gijit/gi/vendor/github. com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.amake[2]: * [빌드] 오류 1make[1]: [설치] 오류 2make: ** [설치] 오류 2jaten@jatens-MacBook-Pro ~/go/src/github.com/gijit/gi (마스터) $~
-L -l 해결 방법을 시도했습니다.
~~~

cgo LDFLAGS: -L${SRCDIR}/../../../LuaJIT/LuaJIT/src -lluajit -lm -ldl

~~~
하지만 링커는 다른 위치에서 같은 이름으로 다른 라이브러리를 사용할 수 있다고 생각하고 링크 타임 오류가 아닌 런타임이 발생합니다.

~~~
런타임에...
dyld: 지연 기호 바인딩 실패: 기호를 찾을 수 없음: _luajit_ctypeid
참조: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
예상 위치: /usr/local/lib/libluajit-5.1.2.dylib

dyld: 기호를 찾을 수 없음: _luajit_ctypeid
참조: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
예상 위치: /usr/local/lib/libluajit-5.1.2.dylib

SITRAP: 추적 트랩
PC=0x7fff66ff4075 m=0 시그코드=1
cgo 실행 중에 도착한 신호
~~~
/usr/local/lib/libluajit-5.1.2.dylib는 동적으로 링크되었지만 필요한 라이브러리가 아닙니다. 대신 ${SRCDIR}/../../../LuaJIT/LuaJIT/src/libluajit.a에 지정된 것이어야 합니다.

그래서 여전히 해결 방법을 찾고 있습니다.

업데이트: 이것을 내 makefile에 추가하는 것이 트릭을 수행하는 것처럼 보입니다.
~내보내기 CGO_LDFLAGS_ALLOW="${GOPATH}/src/github.com/gijit/gi/vendor/github.com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a";~

업데이트: 고맙게도 Ian은 더 짧은 정규식 버전이 다음을 수행할 것이라고 지적했습니다.
~내보내기 CGO_LDFLAGS_ALLOW=".*.a";~

-Wl,-framework는 무엇을 위한 것입니까? 그것이 Apple 프레임워크라면 인수가 있으므로 -Wl,-framework,foo를 원할 것입니다. 그러나 Apple 프레임워크인 경우 -framework(-Wl 없음)도 마찬가지로 작동합니다.

1.10rc2에서는 golang.org/x/net/internal/socket이 더 이상 Solaris용으로 빌드되지 않습니다.

$ GOOS=solaris go build golang.org/x/net/ipv4
# golang.org/x/net/internal/socket
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:24:3: //go:cgo_import_dynamic libc___xnet_getsockopt __xnet_getsockopt "libsocket.so" only allowed in cgo-generated code
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:25:3: //go:cgo_import_dynamic libc_setsockopt setsockopt "libsocket.so" only allowed in cgo-generated code
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:26:3: //go:cgo_import_dynamic libc___xnet_recvmsg __xnet_recvmsg "libsocket.so" only allowed in cgo-generated code
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:27:3: //go:cgo_import_dynamic libc___xnet_sendmsg __xnet_sendmsg "libsocket.so" only allowed in cgo-generated code

(이것은 크로스 빌드이기 때문에 여기서 일어나는 cgo는 없지만 그것은 중요하지 않다고 생각합니다.)

전체 경로를 지정하여 정적 lib 파일에 연결할 수 없습니다.

#cgo LDFLAGS: /usr/local/lib/libsecp256k1.a

나는 그것에 대한 해결 방법이 없습니다 :(

@piotrnar CGO_LDFLAGS_ALLOW='.*\.a$'

@ianlancetaylor , 감사합니다!

그것은 나에게 도움이 될 것이지만 내 프로젝트를 사용하는 다른 모든 사람들에게 go 1.9.4에 대해 CGO_LDFLAGS_ALLOW='.*\.a$' 를 하라고 말하는 것은 다소 엉뚱한 것 같습니다.

앞으로 더 나은(즉시 사용 가능한) 솔루션이 있기를 바랍니다.

@piotrnar 예, 이 문제의 요점은 화이트리스트에 적용해야 하는 모든 변경 사항을 수집하는 것입니다. 확실히 우리는 .파일을 화이트리스트에 올릴 것입니다.

-fstack-protector 도 추가해 주시겠습니까?

감사 해요 :)

화이트리스트 -static-libstdc++ 부탁합니다.

패키지 github.com/flynn/hid 는 darwin에서 LDFLAGS를 통해 -fconstant-cfstrings 를 전달하기 때문에 1.9.4로 빌드에 실패합니다.

이 링커 플래그를 화이트리스트에 추가하십시오
-Wl,-Bstatic
-Wl,-B동적
-Wl,--start-그룹
-Wl,--end-그룹

솔직히: 이 시점에서 나쁜 옵션의 블랙리스트가 그런 광범위한 화이트리스트보다 더 유용해 보입니다.

앞으로 블랙리스트는 잠재적으로 안전하지 않은 새로운 컴파일러 옵션이 도입되면 모든 Go 릴리스가 해당 옵션에 취약해질 수 있음을 의미합니다. 우리가 이런 종류의 공격으로부터 보호할 수 있는 범위 내에서 화이트리스트에 있어야 한다고 생각합니다.

잠재적으로 안전하지 않은 새로운 컴파일러 옵션이 도입되었습니다.

나는 여전히 블랙리스트가 바람직하다고 생각합니다. 양쪽으로 자르기 때문입니다. 새 컴파일러 옵션이 화이트리스트에 추가될 때까지 사용할 수 없는 경우 새 C 컴파일러가 플래그를 추가할 때마다 새 Go 릴리스가 필요한 것 같습니다...

@glycerine 이것이 우리가 환경 변수를 탈출구로 제공하는 이유입니다. 화이트리스트가 업데이트될 때까지 항상 환경 변수를 사용할 수 있습니다.

문제는 순전히 'go get'을 통해 설치된 프로젝트에서는 env 변수가 작동하지 않는다는 것입니다.

또 다른 접근 방식: go project라는 최상위 수준에서 환경 변수를 설정하도록 허용합니다.

그런 다음 설치되는 기본 '구축' 프로젝트는 필요한 플래그를 화이트리스트에 추가할 수 있습니다(예: ALLOW 정규식 사용). 동시에 종속 프로젝트가 임의적인 작업을 수행하는 것을 방지할 수 있습니다.

@glycerine 나는 그것이 어떻게 작동하는지 이해하지 못합니다. 그러나 화이트리스트에 추가해야 하는 옵션을 수집하기 위한 이 문제에 대해 논의하기보다 해당 제안에 대해 별도의 문제를 여는 것이 좋습니다.

현재로서는 화이트리스트를 구현하기로 결정했습니다. 이는 향후 변경될 수 있지만 이 문제는 논의할 장소가 아닙니다(새 문제를 자유롭게 제출하십시오). 우리는 여기에 화이트리스트에 추가해야 하는 옵션을 수집하려고 합니다.

감사합니다.

#cgo CFLAGS: -pipe의 잘못된 플래그

go build github.com/zchee/docker-machine-driver-xhyve/vendor/github.com/zchee/libhyperkit: invalid flag in #cgo CFLAGS: -fno-common

안녕하세요, 이 플래그를 허용 목록에 추가하십시오. -Wl,--enable-new-dtags

레시피/qt를 빌드할 수 없습니다.

go build github.com/therecipe/qt/core: invalid flag in #cgo CFLAGS: -pipe

허용된 플래그에 .*\.a 를 추가하는 것이 좋습니다.
https://github.com/golang/go/issues/23807 참조

--mms-bitfields도 필요한 것 같습니다.

모든 컴파일러(및 링커 등) 옵션이 이유가 있고 화이트리스트가 특별히 위험한 것으로 간주되는 옵션을 제외한 모든 옵션을 포함해야 한다고 가정하는 것이 합리적이지 않습니까? 분명히 수백 개가 있고 화이트리스트의 유지 관리는 재미 없을 것입니다. 그러나 그것이 결정된 경로라면 ...

모든 컴파일러(및 링커 등) 옵션이 이유가 있고 화이트리스트가 특별히 위험한 것으로 간주되는 옵션을 제외한 모든 옵션을 포함해야 한다고 가정하는 것이 합리적이지 않습니까? 분명히 수백 개가 있고 화이트리스트의 유지 관리는 재미 없을 것입니다. 그러나 그것이 결정된 경로라면 ...

이것은 아마도 내부적으로 논의되었지만 패치 릴리스에서 놀라운 사실을 발견했습니다. 컴파일러 플러그인 구멍을 막기 위해 먼저 문제가 되는 플래그가 블랙리스트에 올라갔고 1.10에 대해 활성화된 화이트리스트 시스템이 있을 것으로 예상했습니다. RC 동안. 추가 환경 변수는 일부 빌드 시스템에 통합하는 데 그다지 실용적이지 않으며, 이로 인해 사람들이 1.9.3으로 되돌아가 완전히 보호되지 않는 것을 관찰했습니다. 이는 전적으로 역효과라고 생각합니다.

와일드카드와 정규식으로 가득 찬 화이트리스트가 위장된 블랙리스트가 되는 시점은?

gomobile은 -fobjc-arc -fmodules -fblocks 플래그를 사용합니다.

https://github.com/golang/mobile/blob/5704e182c7003d4b7e94c23373f3fad4e5ceb25a/bind/genobjcw.go#L319

https://github.com/augustoroman/v8 은 -pthread를 사용합니다.

https://github.com/augustoroman/v8/blob/master/v8.go#L15

-flto

다음 업데이트가 나올 때까지 개요를 볼 수 있도록 "승인된" 목록을 알파벳순으로 정렬된 목록을 이 문제의 맨 위에 올려 주시겠습니까? CL을 제출하는 사람도 이에 감사할 것입니다.

지금 당장(특히 이 문제가 존재하기 때문에) 저는 균열 사이로 빠져나가는 것이 무엇인지 더 걱정하고 있습니다. 사람들이 먼저 우리와 상의하지 않고 프로젝트에서 제거한 빌드 플래그로 인해 cgo(및 확장하여 Go)가 깨졌다는 잘못된 믿음을 갖게 된 것입니다. 버그가 있고 회귀가 있으며 개발자는 자신이하는 일을 모릅니다. :S (또는 더 나쁜 것은, 당신 이 무엇을 하고 있는지 모르고 분명히 내 패키지를 잘못 구축하고 있다는 것입니다. 왜냐하면 당신 은 의존성 xyz가 하나 없기 때문입니다!)

"이 문제 참조" 링크 중 일부는 아직 이 문제에 적절하지 않은 추가 블랙리스트 플래그를 나열합니다. 나는 또한 특히 중복을 피하기 위해 맨 위에 마스터 목록이 있음을 보증합니다. 사람들은 여전히 ​​정적 아카이브 문제를 겪고 있습니다...

이것은 gcc 및 clang 자체가 a) 우리를 위해 더러운 작업을 수행하고 c) 다른 사람이 끌 수 없는 옵션을 --no-unsafe-options 제공할 수 있거나 제공 해야 하는지 궁금합니다 --no-unsafe-options 옵션(일단 있으면 있는 것, 마침표). 아니면 go get 이런 종류의 필터링이 필요한 최초이자 유일한 상황입니까?

우리가 화이트리스트를 고집한다면 왜 입력을 기다리는 데 지연이 필요한지 모르겠습니다.

컴파일러는 플래그를 문서화합니다. 위에서 누군가 말했듯이 각 플래그에는 이유가 있습니다.

사용에 대한 사용자 입력을 기다리는 샘플링은 대표성이 낮고 신뢰할 수 없으며 현재 실현되지 않았거나 샘플링되지 않은 플래그가 필요하다고 생각하는 우리 모두에게 고통스러운 결과를 낳습니다.

또한 의사 코드에서 이 절차를 통해 화이트리스트를 도출하는 것이 간단해 보입니다.

모든 C/C++ 컴파일러와 지원되는 각 컴파일러 버전을 나열합니다.
각 컴파일러 버전에 대해 해당 문서에서 사용할 수 있는 모든 플래그를 나열합니다.
각 플래그에 대해 화이트리스트 또는 (보이지 않는) 블랙리스트에 넣기로 결정하십시오.

누적 화이트리스트의 모든 플래그에 대한 화이트리스트 코드를 추가합니다.

나는 이것이 하나(또는 두 개의) 취약한 플래그를 블랙리스트에 올리는 것과 비교할 때 이것이 미친 짓이라고 생각합니다(reductio ad absurdum에 가까운). 그러나 진지하게 말하자면 화이트리스트를 고집한다면 위의 알고리즘이 정확하고 추측을 없애고 지체 없이 실행할 수 있습니다. 아마도 필요한 유일한 추가 사용자 입력은 지원될 컴파일러/버전의 범위를 설정하는 것입니다.

여기서 중요한 유일한 옵션은 .go 파일의 #cgo CFLAGS 또는 #cgo LDFLAGS 행에 넣는 것이 합당하거나 pkg-config --cflags 또는 pkg-config --libs . 이는 총 컴파일러 옵션 수의 작은 부분 집합입니다.

당신은 또한 gcc와 clang에 얼마나 많은 옵션이 있는지 과소평가합니다. 소스 코드에서도 모두 문서화되어 있는지 의심스럽습니다. 일부가 런타임에 생성되더라도 놀라지 않을 것입니다! 또한 대상 삼중 종속적인 옵션이 있을 수 있습니다. (이것이 안전 플래그의 정식 목록이 gcc 및 clang 개발자에 의해 유지 관리되어야 한다고 말하는 이유이기도 합니다.)

그러나 개별 플래그 패치가 지연되는 것에 대해서는 아무 말도 할 수 없습니다.

@anacrolix #23672에서 -Wl,-framework 화이트리스트에 추가해야 한다고 제안하셨습니다. 그러나 -framework 일반적으로 옵션을 사용합니다. 정확한 사용 사례를 보여줄 수 있습니까? 감사 해요.

또한 gcc와 clang에는 얼마나 많은 옵션이 있는지 과소평가합니다.

@andlabs Ian은 gcc 개발자입니다. 나는 그가 잘 알고 있다고 확신합니다.

https://golang.org/cl/93836 에서 이 문제를 언급 변경: cmd/go: add options to security whitelist

위의 모든 옵션을 포함하는 CL을 보냈습니다: https://golang.org/cl/93836.

그것에 문제가 있거나 사람들이 사용하는 옵션 중 다루지 않는 옵션이 있으면 알려주십시오. 감사 해요.

LLVM Go 바인딩의 관점에서 볼 때 다음 링커 옵션이 화이트리스트에 있어야 합니다.

• -Wl,-search_paths_first
• -Wl,-headerpad_max_install_names

링커 옵션은 llvm-config --ldflags 명령에 의해 생성되며 출력에 있습니다.

참조: https://reviews.llvm.org/D43070

@magical 나는 거기에 @glycerine 에 응답하고 있었다 =P

@ianlancetaylor 도 이

@andlabs 아 죄송합니다

@ianlancetaylor 해당 CL을 사용하여 Solaris용 golang.org/x/net/internal/socket을 여전히 빌드할 수 없습니다. 어떤 플래그를 요청해야 하는지는 오류에서 나에게 분명하지 않습니다.

$ ./bin/go version
go version devel +09dc376990 Tue Feb 13 20:58:04 2018 -0800 darwin/amd64
$ GOOS=solaris ./bin/go get -u golang.org/x/net/ipv4
# golang.org/x/net/internal/socket
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:24:3: //go:cgo_import_dynamic libc___xnet_getsockopt __xnet_getsockopt "libsocket.so" only allowed in cgo-generated code
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:25:3: //go:cgo_import_dynamic libc_setsockopt setsockopt "libsocket.so" only allowed in cgo-generated code
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:26:3: //go:cgo_import_dynamic libc___xnet_recvmsg __xnet_recvmsg "libsocket.so" only allowed in cgo-generated code
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:27:3: //go:cgo_import_dynamic libc___xnet_sendmsg __xnet_sendmsg "libsocket.so" only allowed in cgo-generated code

@calmh 네. golang.org/x/net을 변경하여 이 문제를 수정해야 한다고 생각합니다. 이미 많은 내부 세부 사항에 의존하고 있으며 그렇게 하는 방식을 바꿔야 한다고 생각합니다.

@calmh 실제 Solaris 시스템에서 https://golang.org/cl/94015 를 테스트할 수 있습니까?

https://golang.org/cl/94015 에서 이 문제를 언급 변경: internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix -Wl,-framework 가 어디에서 오는지 알아냈습니다. GTK+의 종속성인 GLib용 pkg-config 파일에서 왔습니다. 특히 국제화를 위한 CoreFoundation 링크가 포함되어 있습니다.

특정 참조: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 여기서 @INTLLIBS@ 는 https://gitlab 에서 -Wl,-framework -Wl,CoreFoundation 를 얻습니다. .gnome.org/GNOME/glib/blob/master/m4macros/glib-gettext.m4#L143

다양한 다른 pkg-config 파일에 다른 -Wl,-framework 인스턴스가 있습니다. 일부는 (위와 같이) 프로젝트 자체의 일부이고 일부는 Homebrew에 의해 주입됩니다. 지금 제 시스템에서는 libcdio와 SDL이 모두 -Wl,-framework,FrameworkName 사용하는 것을 볼 수 있습니다. (즉, -Wl,-framework -Wl,FrameworkName 및 -Wl,-framework,FrameworkName 모두 pkg-config 파일에서 발견됩니다. 그림으로 이동하십시오.)

https://golang.org/cl/94018 에서 이 문제를 언급 변경: cmd/compile: permit go:cgo_import_dynamic anywhere

@calmh https://golang.org/cl/94018 에서 다른 접근 방식을 시도하고

@andlabs 감사합니다. CL 93836에 추가되었습니다.

저는 SDL을 정적으로 연결하고 있으며 pgkconfig에는 -Wl,--no-undefined 와 전처리기 정의가 포함되어 있습니다.

화이트 리스트 아래에 플래그를 추가해야 cgoemitter 패키지를 사용하는 프로젝트를 컴파일할 수 있습니다.

빌드 github.com/supermock/cgoemitter-demo/x: #cgo의 잘못된 플래그 LDFLAGS: -Wl,-unresolved-symbols=ignore-all

미리 대단히 감사합니다

CL을 다시 업데이트하십시오.

https://golang.org/wiki/InvalidFlag 에서 이 문제를 설명하는 Wiki 페이지를 추가했으며 오류 메시지가 Wiki를 가리키도록 CL을 업데이트하고 있습니다.

https://golang.org/cl/94158 에서 이 문제를 언급 변경: doc: add note about invalid flag errors to 1.10 release notes

invalid flag in #cgo LDFLAGS: -O3

https://golang.org/cl/94655 에서 이 문제를 언급 변경: [release-branch.go1.10] doc: add note about invalid flag errors to 1.10 release notes

https://golang.org/cl/94675 에서 이 문제를 언급 변경: [release-branch.go1.10] cmd/compile: permit go:cgo_import_dynamic anywhere

https://golang.org/cl/94676 에서 이 문제를 언급 변경: [release-branch.go1.10] cmd/go: add options to security whitelist

또한 다음을 추가할 수 있는 경우 이 문제를 수신합니다.

go build github.com/andlabs/ui: invalid flag in #cgo LDFLAGS: -mmacosx-version-min=10.8

@bgk- 적용된 패치가 이를 해결합니다. 1.10으로 업그레이드하는 것이 지금 실현 가능하지 않다면 1.9.5가 발생하는지 확인하기 위해 기다리는 것이 좋습니다.

1.10에서 invalid pkg-config package name: --static 문제를 수정해야 합니까? 방금 homebrew에서 최신 버전을 다운로드했는데 여전히 표시됩니다.

➜  ~ go version
go version go1.10 darwin/amd64
... 
➜  ~ go build
...
go build github.com/flier/gohs/hyperscan: invalid pkg-config package name: --static

@ptoomey3 #

1.9.5에 재개장합니다.

나는 XY 문제를 피하고 오히려 내가 하고 있는 일을 완전히 설명할 것입니다. -buildmode=c-shared 와 함께 postgresql 확장을 만들고 있습니다.

postgresql을 위한 C 확장을 만드는 문서에서 공유 객체를 빌드하는 방법은 다음과 같습니다.

cc -fPIC -c foo.c
cc -shared -o foo.so foo.o

그래서 소스 코드에 #cgo LDFLAGS: -shared 를 추가했습니다. 최근(go1.10)까지 다음과 같이 빌드를 중지할 때까지 작동했습니다.

invalid flag in #cgo LDFLAGS: -shared

방금 go 1.10을 잡고 다음과 같이 실행했습니다.

invalid flag in #cgo LDFLAGS: -Wl,-static

이것은 링크 라인에서 해당 옵션 이후의 모든 항목에 대해 정적 링크를 강제 실행하는 gcc 링커 플래그입니다.

@spackard 기록을 위해, 그것은 그 옵션이 의미하는 바가 아닙니다. -Bstatic 생각 중입니다. -static 옵션은 링커가 -l 옵션을 충족하기 위해 공유 라이브러리를 검색하지 않도록 지시합니다. -static 는 위치 옵션이 아닙니다. 명령줄에 나타나는 위치는 중요하지 않습니다.

@ianlancetaylor 위치에 대해 정확합니다. 이것이 우리가 관계없이 정적 링크를 강제하는 방법입니다. 기록을 위해 CGO_LDFLAGS_ALLOW 추가하면 작동합니다.

나는 같은 문제가있다

invalid flag in #cgo CFLAGS: -m32

우리는 이것을 -O3, -static-libgcc 및 -static-libstdc++로 적중했습니다.

-O3:

cgo 창 LDFLAGS: -O3 -L./ -lmass -static-libgcc -static-libstdc++

cgo 리눅스 LDFLAGS: -O3 -L./ -lmass -ldl -lm -lrt -static-libgcc -static-libstdc++

cgo CFLAGS: -O3

#cgo의 잘못된 플래그 LDFLAGS: -O3

-정적-libgcc:

cgo 창 LDFLAGS: -L./ -lmass -static-libgcc -static-libstdc++

cgo 리눅스 LDFLAGS: -L./ -lmass -ldl -lm -lrt -static-libgcc -static-libstdc++

#cgo LDFLAGS의 잘못된 플래그: -static-libgcc

-정적-libstdc++:

cgo 창 LDFLAGS: -L./ -lmass -static-libstdc++

cgo 리눅스 LDFLAGS: -L./ -lmass -ldl -lm -lrt -static-libstdc++

#cgo LDFLAGS의 잘못된 플래그: -static-libstdc++

하드코딩된 정적 화이트리스트를 사용하는 것은 나쁜 생각입니다. 아마도 다음과 같은 기본 설정이 있는 구성 파일을 사용해야 할 것입니다.

$GOROOT/bin/cgo.cfg
[화이트리스트]
블라블라블라
...

그래서 우리는 약간의 사용자 정의를 할 수 있습니다

@kruglinski CGO_CFLAGS_ALLOW 환경 변수 및 친구를 사용하여 사용자 정의할 수 있습니다.

@ianlancetaylor

죄송합니다, 방금 이것에 대해 놓쳤습니다. :-) 알고 보니 반갑습니다. 많은 사람들이 생각합니다!

24124는 다음 링커 옵션을 보고합니다.

-Wl,-z,relro

링커 옵션 -Wl,--subsystem,windows 및 컴파일러 옵션 -mwindows 이 모두 없습니다.

gomobile/gobind가 독립 실행형 바인딩을 생성하도록 하려고 합니다. 그 작업 중 일부는 CGO_*FLAGS 환경 변수를 #cgo 지시문으로 변환하는 것과 관련되어 몇 가지 더 많은 플래그를 발견했습니다.

````
-isysroot(아이오스)
-mios-simulator-version-min=(아이오스)
-miphoneos-버전-최소=(아이오스)

-표적(안드로이드용)
--sysroot(안드로이드용)
-gcc-도구 체인(안드로이드용)
````

마지막 -gcc-toolchain을 제외한 모든 것이 화이트리스트에 추가하는 것이 안전하다고 생각합니다.

macOS에서 CGO_LDFLAGS_ALLOW 없이 Godot 게임 엔진 을 위한 Go 바인딩 을 빌드하려면 다음 플래그가 필요합니다:

-Wl,-undefined,dynamic_lookup

zchee/libhyperkit의 추가 CFLAGS :

• -fmessage-length=152
• -fdiagnostics-show-note-include-stack
• -fmacro-backtrace-limit=0

v8worker는 Mac OS X에서 -stdlib=libstdc++ 가 필요합니다.

CL 103156 Go 1.9.5용 OK

https://golang.org/cl/103135 에서 이 문제를 언급 변경: [release-branch.go1.9] cmd/go: add options to security whitelist

목록에서 볼 수 없었습니다. libtool도 화이트리스트에 올릴 수 있습니까?

invalid flag in #cgo LDFLAGS: -I/usr/local/share/libtool

@PassKit -I 는 ldflag가 아닌 cflag(목록에 있음)입니다. 왜 ldflags에 넣습니까?

더 많은 화이트리스트 요청을 수집하기 위해 재개합니다.

#24703에서

CFLAGS: -fno-plt

이 시점에서 일부 인기 있는 패키지가 빌드에 실패하고 아직 보고되지 않은 경우에만 1.9 및 1.10 릴리스 분기를 업데이트하도록 결정하는 것이 괜찮다고 생각합니다. 모든 무작위 옵션을 계속 백포팅할 필요는 없다고 생각합니다. 1.11에 대한 팁에 추가할 수 있습니다. 이 문제에서 추적하든 다른 곳에서 추적하든 상관하지 않습니다.

sgtm

@AlexRouSg 내 문제는 현재 해결 방법으로 사용 중인 ldflag로 "-I"를 허용 목록에 추가하는 것을 권장하는 이 라이브러리와 관련이 있습니다. https://github.com/miekg/pkcs11/issues/63

늦어서 죄송하지만 1.9.5 또는 1.10.2에서 화이트리스트에 추가되면 좋을 것입니다.

CXXFLAGS: -F/Users/user/Qt/5.10.1/clang_64/lib
CFLAGS: --sysroot=/Users/user/android-ndk-r14b/sysroot
CFLAGS: -mfloat-abi=softfp
CFLAGS: -fno-builtin-memmove
CFLAGS: -mthumb
CFLAGS: -fobjc-nonfragile-abi
CFLAGS: -fobjc-legacy-dispatch
CFLAGS: -fno-keep-inline-dllexport
CXXFLAGS: -mthreads
CFLAGS: -Wp,-D_FORTIFY_SOURCE=2
CFLAGS: --param=ssp-buffer-size=4
CFLAGS: -mfloat-abi=hard
CFLAGS: -fvisibility-inlines-hidden
CFLAGS: -mfpmath=sse
CFLAGS: -fasynchronous-unwind-tables
CFLAGS: -feliminate-unused-debug-types
CFLAGS: -marm
CFLAGS: -mabi=aapcs-linux
CFLAGS: -mthumb-interwork

그리고

LDFLAGS: -headerpad_max_install_names
LDFLAGS: -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
LDFLAGS: -Wl,-rpath,@executable_path/Frameworks
LDFLAGS: --sysroot=/Users/user/android-ndk-r14b/platforms/android-16/arch-arm/
LDFLAGS: -Wl,-rpath-link=/Users/user/Qt/5.10.1/android_armv7/lib
LDFLAGS: -Wl,--allow-shlib-undefined
LDFLAGS: -Wl,-e,_qt_main_wrapper
LDFLAGS: -Wl,-O1
LDFLAGS: -Wl,-rpath-link,/opt/Qt/5.10.0/gcc_64/lib
LDFLAGS: -Wl,-s
LDFLAGS: -Wl,-subsystem,console
LDFLAGS: -mthreads
LDFLAGS: -rdynamic
LDFLAGS: -mfloat-abi=hard

미리 감사드립니다.

@therecipe 1.11에 추가할 수 있습니다. 그러나 1.9.5 또는 1.10.2의 경우: 어떤 패키지가 필요합니까?

@ianlancetaylor 이것들은 모두 https://github.com/therecipe/qt 의 다른 대상에 필요합니다.
한 번에 모두 화이트리스트에 등록하지 않아도 괜찮습니다. 하지만 어느 것을 관리해야 하는지 알려주세요.

나는 그것이 잘 확립될 만큼 충분히 오래된 것으로 알고 있는 그들 자신의 Qt 패키지라고 추측할 것입니다. 나는 완전히 확인이 (다른 사람이 말을해야합니다) 인 경우 아니에요.

그 말 :

• LDFLAGS 중 일부가 이미 -Wl, 접두사 없이 허용 목록에 있지 않습니까?
• -e 는 Go에 영향을 줍니까?
• -F 이미 허용 목록에 포함되지 않았습니까? 그것은 내가 위에서 언급한 옵션으로 밝혀졌습니다.
• (@therecipe에) 왜 당신은 지키고 -D A를 -Wp ? 매크로를 전처리기에서만 정의해야 하는 이유가 있습니까? Qt가 여기에서 어떤 종류의 부두교를 하는지 모르겠습니다... 아니면 Qt 자체에서 제공하는 권장 옵션 목록입니까?
• (@ianlancetaylor에게) 나는 새로운 옵션을 1.9로 백포팅하지 않는 것을 이해할 수 있지만(저는 Go 버전 사용 메트릭이 없기 때문에 이 문제에 대해 양면적입니다), 1.12가 출시될 때까지 1.10은 왜 안 될까요?
• 위의 답변에 관계없이 나열된 ARM ABI 옵션을 백포팅할 가치가 있는지 궁금합니다...

@andlabs 언젠가는 멈춰야 하기 때문에 지금 멈추면 안 될까요? 하지만 패치가 충분히 유용해 보인다면 계속해서 패치를 백포트해도 괜찮습니다.

@andlabs 예, 모두 권장되는 플래그입니다. 나는 그들 중 하나를 수동으로 추가하지 않았습니다.
-Wp,-D_FORTIFY_SOURCE=2 는 돛새치 표적 iirc에서 온 것인데 왜 그렇게 했는지 모르겠습니다.

@therecipe 이 경우 Qt와 Sailfish는 어디에서 이러한 제안을 합니까(즉, 이를 제공하는 웹 페이지 또는 CLI 도구가 있습니까)? 지금 궁금합니다.

그 동안 Go 팀에서 해당 목록을 처리하는 동안 -Wl, 접두사를 제거하면 LDFLAGS 경고가 몇 개나 사라지는지 궁금합니다. 그것을 시도하고 볼? CFLAGS 하나의 -Wp, 접두사에 대해서도 동일합니다. 이것이 빌드에 부정적인 영향을 미칠지 모르겠지만 LDFLAGS의 용도이기 때문에 이상적인 세계에서는 안됩니다 . (쉼표를 공백으로 변경해야 합니다. 이 -Wx, 옵션은 기본적으로 gcc와 clang이 인수를 직접 처리하는 대신 링커(또는 어셈블러 또는 전처리기)에 직접 보내도록 지시합니다. 하고 직접 부딪히긴 하지만 잘 모르겠습니다...)

@andlabs 예, Qt의 빌드 도구 qmake 중 하나는 *.pro , *.spec (mkspec), *.conf 및 기타 많은 형식을 사용하여 일반 Makefile을 생성합니다. 그냥 더미 *.pro 파일을 제공하고 Makefile에서 플래그를 추출합니다. 그렇게하면 종속성을 직접 해결할 필요가 없으며 빌드 프로세스가 타사 라이브러리로 더 쉽게 작동 할 수 있으며 c 또는 ld 플래그와 테스트되지 않은 대상 또는 최신/이전 버전의 Qt 작업을 수동으로 관리 할 필요가 없습니다. 대부분의 경우 상자에서 벗어납니다. 나는 가끔 문제를 일으키는 일부 플래그를 블랙리스트에 올려야 하지만 그것은 매우 드뭅니다.

-Wp,-D_FORTIFY_SOURCE=2 를 가져오는 돛새치 mkspec 을 찾으려고 했지만 아마도 mersdk 정도 어딘가에 묻혀 있을 것입니다. 그러나 다음은 TQtC가 지원하는 공식 대상 목록입니다. https://github.com/qt/qtbase/tree/5.11/mkspecs 및 독립 당사자가 유지 관리하는 많은 비공식 대상이 있습니다. 그렇기 때문에 플래그를 수동으로 엉망으로 만들고 싶지 않습니다.

그 동안 바인딩( go 래핑)에서 사용하는 빌드 도구에서 이들을 허용할 수 있지만 go build ... 사용하려는 일반 Go 사용자는 조만간 문제를 제기할 것입니다. (적어도 데스크탑 타겟의 경우)

-빠른 수학

공식 SAP HANA 클라이언트 드라이버(cgo 기반 공유 라이브러리)는 #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN 와 함께 제공되며 결과적으로 go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath 됩니다. 자세한 내용은 https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca56290838lang%2069e5.html?q= 에서 SAP 설명서를

@cbgo #

플래그와 인수 쌍을 링커에 전달하는 코드는 이제 둘 대신 하나의 -Wl 플래그를 사용해야 합니다. #cgo LDFLAGS: -Wl,-rpath -Wl,$가 아닌 #cgo LDFLAGS: -Wl,-rpath,$ORIGIN을 사용 기원.

@AlexRouSg 정말 감사합니다. 더 자세히 읽어봤어야 했는데 :-)

@PassKit 이 문제를 해결하셨습니까?

@zcm211 https://github.com/miekg/pkcs11 에 대해 이야기하고 있다면 2월에 -I... 링커 플래그를 제거했습니다. 패키지를 사용하는 경우 환경 변수 CGO_LDFLAGS_ALLOW="-I.*" 를 설정해야 합니다.

darwin 64비트, go1.10.2, .o 파일이 LDFLAG에 대해 화이트리스트에 추가되었다고 생각했지만 다음과 같은 결과가 나타납니다.
~jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (마스터) $ 실행cd chez_scheme_9.5.1/c;








https://github.com/go-interpreter/chezgo/blob/master/embed.go#L10 의 cgo 서문으로 인해
~~~

cgo LDFLAGS: -licov -lm -lncurses -L/usr/local/lib ./chez_scheme_9.5.1/boot/a6osx/kernel.o

~~~

@glycerine https://go-review.googlesource.com/c/go/+/94676 에 따르면 그렇습니다 . 상대 경로 대신 전체 경로를 시도하시겠습니까?

좋은 캐치 @AlexRouSg , 수락 정규식은 당신이 지적한대로 버그가 있습니다.
~re( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) ), // 직접 링커 입력: xo 또는 libfoo.so (그러나 -foo.o 또는 @foo.o는 아님)~
src/cmd/go/internal/work/security.go#121은 상대 경로를 지원하기 위해 .o 파일이 . 로 시작하도록 허용해야 합니다.

결국 사용자의 GOPATH 또는 해당 파일의 위치가 얼마나 중첩될지 예측할 수 없으므로 절대 경로를 설정하는 것은 실용적이지 않습니다.

.o 파일이 소스 디렉토리에 있습니까? 그렇다면 소스 디렉토리를 참조하는 것은 ${SRCDIR} 가 제공된 것입니다. (이것이 도입된 이유를 구체적으로 잊어버렸지만 이 문제 때문이 아닙니다.)

@andlabs klunky 해결 방법이 있더라도 상대 경로를 연결할 수 있어야 하며 이는 분명히 버그입니다.

IIRC를 제외하고 링크가 소스 디렉토리에 상대적이라는 보장은 없습니다( $WORK 에 있을 수 있으며 상대 경로가 다시 중단될 수 있음)... 다시, 나는 잊어버렸습니다. 역사; 다른 사람이 설명해야 합니다.

gtk4는 -mfpmath=sse를 사용합니다.

@ianlancetaylor cflags와 ldflags에 대해 별도의 화이트리스트를 갖는 대신 하나의 목록만 있어야 합니까? gcc/llvm은 ldflags를 cflag로 또는 그 반대로 혼합하는 것을 신경 쓰지 않는 것 같습니다. 그리고 때때로 C 개발자가 #25493 또는 https://github.com/golang/go/issues/23749#issuecomment -379969818과 같은 문제를 일으키는 것 같습니다.

아, 이미 티켓이 있는 것 같으니 #25493에 문서화된 protobuf의 "-D_THREAD_SAFE"를 언급하겠습니다.

변경 https://golang.org/cl/115415 에서 이 문제를 언급합니다. cmd/go: accept more safe CFLAGS/LDFLAGS

https://golang.org/cl/115435 에서 이 문제를 언급 변경: [release-branch.go1.10] cmd/go: accept more safe CFLAGS/LDFLAGS

https://golang.org/cl/115436 에서 이 문제를 언급 변경: [release-branch.go1.9] cmd/go: accept more safe CFLAGS/LDFLAGS

얘들 아,
2018년 9월 4일 현재 최신 버전의 Go로 bimg 를 빌드할 수 없는데 이 문제가 종료된 이유는 무엇입니까?
문제 참조: https://github.com/h2non/bimg/issues/230
Go 1.10 이후로 bimg 를 가져오는 어떤 것도 빌드할 수 없으며 문제는 Go 1.11에서 여전히 지속됩니다.
우리가 받는 오류 메시지는 다음과 같습니다.

# go build
go build gopkg.in/h2non/bimg.v1: invalid flag in pkg-config --libs: -Wl,--export-dynamic

어떤 조언?

편집하다:
새로운 문제를 만들었습니다: https://github.com/golang/go/issues/27496

나는 이 화이트리스트가 다음에 책임이 있다고 생각합니다: https://github.com/alexflint/gallium/issues/63

@alexflint 이 문제는 종료되었습니다. 새 문제를 만드십시오.