23737は、 pkg-config -libsによって生成されたフラグがコンパイラのホワイトリストとCGO_CFLAGS_ALLOWに対してチェックされていることを報告しますが、代わりにリンカーのホワイトリストとCGO_LDFLAGS_ALLOWに対してチェックする必要があります。 これを修正するCLがあります： //golang.org/cl/92755。

リンカホワイトリストは、 .a .o 、 .soなどのファイルをすでに受け入れているため、 .aファイルを受け入れる必要があります。 これを修正するCLがあります： //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があります： //golang.org/cl/92795。

23744は、次のコンパイラオプションを追加することを提案しています。

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

一重ダッシュまたは二重ダッシュのいずれかで使用できるコンパイラおよびリンカのオプションは多数あります。 ホワイトリストでも同様に緩いはずです。

直交性の場合： -frameworkの検索パスにディレクトリを追加するオプションがすでにカバーされているかどうかを忘れています。 それがどんな選択肢なのかも忘れてしまいました。 （私が考えることができる典型的なユースケースは/Library/Frameworks 。これは、Appleがアプリ固有のフレームワークを配置する場所であり、デフォルトでは検索されません。）

また、 -as-neededはそもそもcgoで安全に使用できますか？ このブログ投稿（「gccas-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変数を通過します。

ただし、 CGO_LDFLAGS_ALLOWをチェックする必要があるときに、 pkg-config -libsがCGO_CFLAGS_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は、 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ヒットします。

この問題は、cgoLDFLAGSの「$ {SRCDIR} /file.o」で発生しました。

リンカー入力であるプレーンファイル名を許可する必要があることを主張したいと思います
LDFLAGS内のファイル
（少なくとも* .a、*。o、および* .so）。

理論的には「-L $ {SRCDIR}」で処理できる.aや.soとは異なります
-lname」、追加
リンカコマンドへの余分なオブジェクトファイルは、そのように修正することはできません。

回避策はCGO_LDFLAGS_ALLOWを設定することですが、これは非常に面倒です。
別
別の方法は、file.oの名前をfile.sysoに変更することですが、特定の目的のために
場合、使用できません
このオプションは、特定のビルドタグが
含まれています（
ビルドタグは、＃cgo LDFLAGSプリアンブルを含むファイルに適用されます）および
道はない
sysoファイル名に任意のビルドタグを設定します。

以前にデプロイされたGoバージョンを無視すると、
新着
リンカにファイルを追加するために特別に設計された「#cgoLDLIBS」
コマンドライン。
次に、LDLIBSに対してより厳密なルールを設定できます（ファイル名のみ、ダッシュなし）
プレフィックスで許可されます。）

--std=c99これをヒットしました

-std = c ++ 11

-std =だと思いますホワイトリストに登録する必要がありますか？

おそらくホワイトリストに載っています： -fopenmp

Gov1.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 ：

以前は：

#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で、リンク先の.aアーカイブをリンカーに具体的に指示していました：（ここでは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

~~~

構築しようとすると生成されます：

〜ビルドするgo build -ldflags "-X main.LastGitCommitHash = 30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp = 2018-02-09T22：49：48 + 0700 -X main.GitBranch = master -X main.NearestGitTag = v0.9.6 -X main.Go = go_version_go1.9.4_darwin / amd64 "-o gigo build 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

SIGTRAP：トレーストラップ
PC = 0x7fff66ff4075 m = 0 sigcode = 1
cgoの実行中にシグナルが到着しました
~~~
/usr/local/lib/libluajit-5.1.2.dylibは必要なライブラリではありませんが、動的にリンクされています。 むしろ、$ {SRCDIR} /../../../ LuaJIT / LuaJIT / src /libluajit.aで指定されたものでなければなりません。

したがって、まだ回避策を探しています。

更新：これを私のmakefilesに追加するとうまくいくようです。
〜エクスポートCGO_LDFLAGS_ALLOW = "$ {GOPATH} /src/github.com/gijit/gi/vendor/github.com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a ";〜

更新：ありがたいことに、Ianは、より短い正規表現バージョンで十分であると指摘しました。
〜export CGO_LDFLAGS_ALLOW = "。*。a";〜

-Wl、-フレームワークとは何ですか？ それが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はい、この問題のポイントは、ホワイトリストに加える必要のあるすべての変更を収集することです。 確かに、.aファイルをホワイトリストに登録します。

-fstack-protectorも追加していただけますか？

ありがとう ：）

ホワイトリスト-static-libstdc++をお願いします。

パッケージgithub.com/flynn/hidは、ダーウィンのLDFLAGSを介して-fconstant-cfstringsを渡すため、1.9.4でビルドできません。

これらのリンカーフラグをホワイトリストに追加してください
-Wl、-Bstatic
-Wl、-Bdynamic
-Wl、-start-group
-Wl、-end-group

正直なところ：現時点では、悪いオプションのブラックリストは、そのような広範なホワイトリストよりも役立つように思われます。

今後、ブラックリストは、安全でない可能性のある新しいコンパイラオプションが導入された場合、すべてのGoリリースがそのオプションに対して脆弱になることを意味します。 この種の攻撃から完全に保護できる範囲で、ホワイトリストにする必要があると思います。

いくつかの新しい潜在的に安全でないコンパイラオプションが導入されました

私はまだブラックリストが望ましいと思います。 それは両方の道を切るからです。 ホワイトリストに登録されるまで新しいコンパイラオプションを利用できない場合は、新しいCコンパイラがフラグを追加するたびに新しいGoリリースが必要になるようです...

@glycerineそのため、環境変数をエスケープハッチとして提供しています。 ホワイトリストが更新されるまで、いつでも環境変数を使用できます。

問題は、純粋に「goget」を介してインストールされたプロジェクトでは環境変数が機能しないことです。

別のアプローチ：goプロジェクトという名前のトップレベルが環境変数を設定できるようにします。

次に、インストールされているプラ​​イマリの「go build」プロジェクトは、依存するプロジェクトが任意のことを実行するのを防ぎながら、たとえば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中にアップ。 余分なenv変数を一部のビルドシステムに統合するのは実用的ではありません。これにより、人々が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）私たちのために汚い仕事をするb）将来の変更に対して回復力があり、c）別の人がオフにできないオプション--no-unsafe-optionsを提供できるか、あるいは提供すべきかどうか疑問に思いますオプション（一度そこにあると、そこにある、期間）。 それとも、 go getは、この種のフィルタリングが必要な最初で唯一の状況ですか？

ホワイトリストを主張する場合、入力を待つのに遅延が必要な理由がわかりません。

コンパイラはフラグを文書化します。 誰かが上で言ったように、それぞれの旗は理由のためにそこにあります。

使用法に関するユーザーの入力を待つことによるサンプリングは、代表的ではなく、信頼性が低く、将来、現在実現またはサンプリングされていないフラグの必要性を見つけた私たち全員にとって苦痛な結果を生み出します。

さらに、この手順で疑似コードでホワイトリストを導出するのは簡単なようです。

すべてのC / C ++コンパイラとサポートされている各コンパイラのバージョンを一覧表示します。
コンパイラバージョンごとに、ドキュメントから入手できるすべてのフラグを一覧表示します。
フラグごとに、それをホワイトリストまたは（非表示の）ブラックリストに入れることを決定します。

蓄積されたホワイトリストのすべてのフラグにホワイトリストコードを追加します。

1つ（または2つ）の脆弱なフラグをブラックリストに載せるのと比較して、これはまだクレイジーだと思います（reductio ad absurdumに集中しています）。 しかし、真面目な話として、ホワイトリストを主張する場合、上記のアルゴリズムは正しく、当て推量を排除し、遅滞なく実行できます。 おそらく、必要な追加のユーザー入力は、サポートするコンパイラ/バージョンの範囲を確立することだけです。

ここで重要な唯一のオプションは、.goファイルの#cgo CFLAGSまたは#cgo LDFLAGS行に配置するのに合理的なオプション、またはpkg-config --cflags呼び出しから出力するのに合理的なオプションです。 pkg-config --libs 。 これは、コンパイラオプションの総数の小さなサブセットです。

また、gccとclangのオプションの数を大幅に過小評価しています。 ソースコードであっても、それらがすべて文書化されているとは思えません。実行時に生成されたものがあったとしても、驚くことではありません。 また、ターゲットがトリプルに依存するオプションがあるかもしれません...（これは、安全なフラグの正規リストをgccおよびclang開発者が維持する必要があると私が言う理由でもあります。）

ただし、個々のフラグのパッチ適用の遅延については何も言えません。

@anacrolix Over＃23672で、 -Wl,-frameworkをホワイトリストに登録する必要があると提案されました。 ただし、通常、 -frameworkにはオプションがあります。 正確な使用例を示していただけますか？ ありがとう。

また、gccとclangのオプションの数を大幅に過小評価しています

@andlabsIanはgcc開発者です。 彼はよく知っていると確信しています。

変更https://golang.org/cl/93836はこの問題に言及しています： cmd/go: add options to security whitelist

上記のすべてのオプションをカバーしていると思うCLを送信しました： https ：

問題が発生した場合、またはユーザーが使用しているオプションでカバーされていないものを知っている場合は、お知らせください。 ありがとう。

LLVM Goバインディングの観点から、次のリンカーオプションがホワイトリストに含まれている必要があります。

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

リンカオプションはコマンドllvm-config --ldflagsによって生成され、出力に含まれます。

参照： https ：

@ 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がどこから来ているのかわかりました

特定の参照： https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 @INTLLIBS@取得-Wl,-framework -Wl,CoreFoundationからhttps：//でgitlab .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

@calmhhttps：//golang.org/cl/94018で別のアプローチを試しています。

@andlabsありがとう、

私はSDLを静的にリンクしており、pgkconfigには-Wl,--no-undefinedとプリプロセッサ定義が含まれています。

ホワイトリストの下にフラグを追加して、cgoemitterパッケージを使用するプロジェクトをコンパイルできるようにする必要があります。

go build github.com/supermock/cgoemitter-demo/x：#cgo LDFLAGSの無効なフラグ：-Wl、-unresolved-symbols = ignore-all

事前にどうもありがとうございました

CLを再度更新します。

この問題を説明するwikiページをhttps://golang.org/wiki/InvalidFlagに追加し、エラーメッセージがユーザーに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問題を修正する必要がありますか？ 自作から最新バージョンをプルダウンしましたが、まだ表示されています。

➜  ~ 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

ちょうど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 windows LDFLAGS：-O3 -L./ -lmass -static-libgcc -static-libstdc ++

cgo linux LDFLAGS：-O3 -L./ -lmass -ldl -lm -lrt -static-libgcc -static-libstdc ++

cgo CFLAGS：-O3

#cgo LDFLAGSの無効なフラグ：-O3

-static-libgcc：

cgo windows LDFLAGS：-L./ -lmass -static-libgcc -static-libstdc ++

cgo linux LDFLAGS：-L./ -lmass -ldl -lm -lrt -static-libgcc -static-libstdc ++

#cgo LDFLAGSの無効なフラグ：-static-libgcc

-static-libstdc ++：

cgo windows LDFLAGS：-L./ -lmass -static-libstdc ++

cgo linux LDFLAGS：-L./ -lmass -ldl -lm -lrt -static-libstdc ++

#cgo LDFLAGSの無効なフラグ：-static-libstdc ++

ハードコードされた静的ホワイトリストを使用することは悪い考えです。おそらく、次のようないくつかのデフォルト設定で構成ファイルを使用する必要があります。

$ GOROOT / bin / cgo.cfg
[ホワイトリスト]
かくかくしかじか
..。

カスタマイズできるように

@kruglinskiCGO_CFLAGS_ALLOW環境変数とその仲間を使用してカスタマイズできます。

@ianlancetaylor

申し訳ありませんが、私はこれについて見逃しました:-)知っておくと、多くの人が考えています！

24124は、次のリンカーオプションを報告します。

-Wl,-z,relro

リンカオプション-Wl,--subsystem,windowsとコンパイラオプション-mwindows両方がありません。

gomobile / gobindにスタンドアロンバインディングを生成させようとしています。 その作業の一部には、CGO_ * FLAGS環境変数を#cgoディレクティブに変換することが含まれます。これにより、さらにいくつかのフラグが明らかになりました。

「」
-isysroot（ios）
-mios-simulator-version-min =（ios）
-miphoneos-version-min =（ios）

-目標（アンドロイド用）
--sysroot（アンドロイド用）
-gcc-ツールチェーン（アンドロイド用）
「」

最後の-gcc-toolchainを除いて、ホワイトリストに安全に追加できると思います。

macOSでCGO_LDFLAGS_ALLOWを使用せずに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 Go1.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は（リストにある）cflagであり、ldflagではありません。なぜldflagに入れるのですか？

より多くのホワイトリストリクエストを収集するために再度開きます。

＃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を-Wp守っているのですか？ マクロを定義する理由はありますが、プリプロセッサのみにありますか？ ここでQtがどのようなブードゥーを行うのかわかりません...それとも、これはQt自体が提供する推奨オプションのリストですか？
• （@ianlancetaylorへ）新しいオプションを1.9にバックポートしないことはある程度理解できますが（Goバージョンの使用状況メトリックがないため、この問題については曖昧です）、1.12がリリースされるまで1.10を使用しないのはなぜですか？
• 上記の答えに関係なく、そこにリストされているARMABIオプションをバックポートする価値があるかどうか疑問に思います...

@andlabsいつか停止する必要があるという理由だけで、今すぐ停止しませんか？ しかし、パッチが十分に役立つと思われる場合は、パッチをバックポートし続けても問題ありません。

@andlabsはい、これらはすべて推奨フラグです。 私はそれらの1つを自分で手動で追加しませんでした。
-Wp,-D_FORTIFY_SOURCE=2は、バショウカジキのターゲットiircからのもの

その場合、 @ therecipeは、QtとSailfishがそれらの提案をどこで行いますか（つまり、それらを提供するWebページまたはCLIツールはありますか）？ 私は今興味があります。

それまでの間、そのリストはGoチームによって対処されていますが、 -Wl,プレフィックスを削除すると、LDFLAGSの警告がいくつ消えるか疑問に思います。 それを試してみてください？ 1つのCFLAGSの-Wp,プレフィックスについても同じです。 これがビルドに悪影響を与えるかどうかはわかりませんが、それがLDFLAGSの目的であるため、理想的な世界で-Wx,オプションは基本的に、引数を自分で処理するのではなく、リンカー（またはアセンブラーまたはプリプロセッサー）に直接送信するようにgccとclangに指示します。正しく推測している場合、アイデアはgccによってまだ提供されていないOS固有のオプションです。直接鳴りますが、よくわかりません...）

@andlabsええ、Qtのビルドツールの1つqmakeは、 *.pro 、 *.spec （mkspec）、 *.conf 、およびその他の多くの形式を使用して、通常のMakefileを生成します。 ダミーの*.proファイルをいくつかフィードし、Makefileからフラグを抽出します。 そうすれば、依存関係を自分で解決する必要はありません。サードパーティのライブラリを使用するとビルドプロセスが簡単になります。cまたはldフラグとテストされていないターゲットを手動で管理したり、Qtの新しいバージョンや古いバージョンを管理したりする必要はありません。ほとんどの場合、箱から出してすぐに使用できます。 たまに問題の原因となるフラグをブラックリストに登録する必要がありますが、それは非常にまれです。

-Wp,-D_FORTIFY_SOURCE=2引き込むセイルフィッシュmkspecを見つけようとしましたが、おそらくmersdkかそこらのどこかに埋もれています。 ただし、TQtCがサポートを維持しているターゲットの公式リストは次のとおりです。https ：

その間、バインディング（ goをラップする）で使用されるビルドツールでそれらをホワイトリストに登録できますが、 go build ...を使用したいだけの通常のGoユーザーは、遅かれ早かれ問題を引き起こします。 。（少なくともデスクトップターゲットの場合）

-ffast-math

公式のSAPHANAクライアントドライバー（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/fba20e31f75c4f7ca5629083869069e5.html？q = golang％20driverのSAPドキュメントも参照してください。

@ cbgo ＃

フラグと引数のペアをリンカに渡すコードでは、2つではなく1つの-Wlフラグを使用する必要があります。＃cgoLDFLAGSではなく#cgo LDFLAGS：-Wl、-rpath、$ ORIGINを使用してください：-Wl、-rpath -Wl、$元。

@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（master）$ make runcd chez_scheme_9.5.1 / c;








https://github.com/go-interpreter/chezgo/blob/master/embed.go#L10のcgoプリアンブルが原因
~~~

cgo LDFLAGS：-liconv -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厄介な回避策がある場合でも、相対パスはリンク可能である必要があり、それは明らかにバグです。

それは、IIRCを除いて、リンクがソースディレクトリに対して相対的であるという保証はありません（ $WORKにある可能性が非常に高く、その後、相対パスが再び壊れます）...繰り返しますが、忘れてしまいました歴史; 他の誰かが説明する必要があります。

gtk4は-mfpmath = sseを使用します

@ianlancetaylor cflagsとldflagsに別々のホワイトリストを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 ：
Go 1.10以降、 bimgをインポートするものをビルドすることはできませんが、Go1.11でも問題が解決しません。
表示されるエラーメッセージは次のとおりです。

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

何かアドバイスはありますか？

編集：
新しい問題を作成しました： https ：

このホワイトリストは次の責任があると思います： https ：

@alexflintこの問題は解決されました。新しい問題を作成してください