23737 melaporkan bahwa flag yang dihasilkan oleh pkg-config -libs sedang diperiksa terhadap daftar putih kompilator, dan CGO_CFLAGS_ALLOW , padahal seharusnya dengan diperiksa terhadap daftar putih tautan dan CGO_LDFLAGS_ALLOW . Ada CL untuk memperbaikinya: https://golang.org/cl/92755.

Daftar putih tautan harus menerima file .a karena sudah menerima file .o , .so , dll. Ada CL untuk memperbaikinya: https://golang.org/cl/92855. Ini #23739.

Komentar pada #23672 mencantumkan opsi kompiler ini:

-fno-rtti
-fpermissive

dan opsi penaut ini:

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

23742 menyarankan untuk menambahkan opsi kompiler -fmodules . Kompiler dentang mendukung sejumlah opsi -fmodules , tetapi tidak jelas apakah semuanya aman. Khususnya -fmodules-cache-path dan -fmodules-user-build-path tampaknya mengizinkan penentuan jalur yang akan digunakan dentang untuk membaca modul, yang mungkin dapat mengubah mode kompilasi dengan berbagai cara.

23743 menyarankan untuk menambahkan opsi tautan -Wl,--no-as-needed . Ada CL untuk ini: https://golang.org/cl/92795.

23744 menyarankan untuk menambahkan opsi kompiler ini:

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

Ada banyak opsi kompiler dan tautan yang dapat digunakan dengan tanda hubung tunggal atau tanda hubung ganda. Kita juga harus lemah dalam daftar putih.

Untuk ortogonalitas: Saya lupa apakah opsi untuk menambahkan direktori ke jalur pencarian -framework sudah tercakup atau belum. Saya juga lupa opsi apa itu. (Kasus penggunaan tipikal yang dapat saya pikirkan adalah /Library/Frameworks , di situlah Apple menempatkan kerangka kerja khusus aplikasi, dan tidak dicari secara default.)

Juga apakah -as-needed aman digunakan dengan cgo? Posting blog ini (yang merupakan hasil pertama yang dapat saya temukan untuk "gcc sesuai kebutuhan") mengatakan bahwa ini adalah argumen posisi, tetapi saya tidak yakin apakah cgo menjamin apa pun tentang ke mana bendera Anda pergi pada baris perintah yang dihasilkan.

@andlabs Tidak apa-apa untuk menulis

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

Bagaimanapun, topik untuk masalah ini adalah apakah opsi aman digunakan dari go get .

Ketika menggunakan:

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

kompilasi gagal dengan pesan berikut:

invalid pkg-config package name: --static

Melihat kode (untuk go 1.9.4) tampaknya tidak ada variabel lingkungan yang dapat digunakan untuk memasukkan argumen pkg-config ke daftar putih.

@rgburke pkg-config output melewati variabel FLAGS_ALLOW sama dengan output lainnya.

Namun, tampaknya pkg-config -libs memeriksa CGO_CFLAGS_ALLOW ketika seharusnya memeriksa CGO_LDFLAGS_ALLOW .

Kami menautkan sejumlah besar pustaka C secara statis dalam proyek sumber tertutup. Sampai sekarang kami telah melakukan hal berikut:

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

Ini tentu saja tidak diperbolehkan sekarang. Solusi:

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

Namun beberapa direktori ini juga berisi pustaka dinamis, yang membingungkan tautan. Opsi lain adalah menambahkan '/' ke daftar "nama" yang diizinkan di https://go-review.googlesource.com/c/go/+/92855 Khususnya perubahan pada baris 91 adalah:

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)

opsi terakhir memperbaiki masalah kami, tetapi saya tidak dapat berbicara tentang dampaknya terhadap keamanan.

@mirtchovski ada tambalan untuk itu (masalahnya adalah .a tidak masuk daftar putih, tetapi format file objek lainnya)

.a sekarang masuk daftar putih (setelah tambalan itu) jadi 'libsomething.a' akan berfungsi, tetapi '/path/to/libsomething.a' tidak akan berfungsi.

@ianlancetaylor @rgburke Saya benar-benar mengalami masalah yang sama dengan --static yang membawa saya ke lubang #23737. --static ditolak karena tampaknya bukan nama paket yang valid _before_ mencoba mengeksekusi pkg-config , di sini https://github.com/golang/go/blob/104445e3140f4468839db49a25cb0182f7923174/src/ cmd/go/internal/work/exec.go#L939 -L940.

Perbaikan cepat kami secara internal adalah mengarahkan PKG_CONFIG ke skrip yang hanya dieksekusi pkg-config --static "$@" .

@jeddenlea - Terima kasih banyak! Saya mencoba mencari solusi tetapi tidak memikirkannya.

Kami mencapai ini dengan -msse dan -msse4.2 .

Saya mengalami masalah ini dengan "${SRCDIR}/file.o" di cgo LDFLAGS.

Saya ingin berpendapat bahwa kita harus mengizinkan nama file biasa yang merupakan input tautan
file di LDFLAGS
(setidaknya *.a, *.o dan *.so).

Tidak seperti .a dan .so yang secara teori dapat ditangani dengan "-L${SRCDIR}
-lname", menambahkan
file objek tambahan ke perintah tautan tidak dapat diperbaiki seperti itu.

Solusinya adalah mengatur CGO_LDFLAGS_ALLOW, tapi itu sangat rumit.
Lain
alternatifnya adalah mengganti nama file.o saya menjadi file.syso, namun, untuk spesifik saya
kasus, saya tidak bisa menggunakan
opsi ini karena saya hanya menyertakan file.o itu ketika tag build tertentu
termasuk (yang
tag build berlaku untuk file yang berisi pembukaan #cgo LDFLAGS) dan
tidak ada jalan
untuk mengatur tag build sewenang-wenang dalam nama file syso.

Jika kami mengabaikan versi Go yang digunakan sebelumnya, kami mungkin dapat menyertakan a
baru
"#cgo LDLIBS" yang dirancang khusus untuk menambahkan lebih banyak file ke linker
garis komando.
Kemudian kita dapat memiliki aturan yang lebih ketat untuk LDLIBS (hanya nama file, dan tanpa tanda hubung
diperbolehkan dalam awalan.)

Kami telah mencapai ini dengan --std=c99

-std=c++11

Saya kira -std=harus daftar putih?

Mungkin ada di daftar putih: -fopenmp

Kesalahan saat membuat paket biimg menggunakan Go v1.10rc2,

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

Saya tidak dapat memasukkan -isystem ke daftar putih karena argumen di sebelahnya (yang merupakan jalur) akan ditolak

Kami juga perlu menggunakan solusi ini: https://github.com/golang/go/issues/23749#issuecomment -364239496

Kami sebelumnya memiliki:

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

dan telah berpindah ke:

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

.../path/to/thing berada di luar ${SRCDIR} .

Menambahkan komentar ini sehingga masalah ini menyertakan contoh dengan referensi libthing.a yang memerlukan ekspansi SRCDIR untuk diselesaikan.

di OSX, dengan go1.9.4 yang baru dicetak dengan batasan cgo flag-nya, saya memberi tahu tautan secara khusus tentang apa yang .a arsip untuk ditautkan: (di sini 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

~~~

menghasilkan pada upaya untuk membangun:

~membuat bangunanpergi build -ldflags "-X main.LastGitCommitHash=30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp=2018-02-09T22:49:48+0700 -X main.GitBranch=master -X main.NearestGitTag=v0.9.6Tag utama =go_version_go1.9.4_darwin/amd64" -o gibuka github.com/gijit/gi/vendor/github.com/glycerine/golua/lua: tanda tidak valid di #cgo LDFLAGS: /Users/jaten/go/src/github.com/gijit/gi/vendor/github. com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.amake[2]: * [membangun] Kesalahan 1make[1]: [instal] Kesalahan 2buat: ** [instal] Kesalahan 2jaten@jatens-MacBook-Pro ~/go/src/github.com/gijit/gi (master) $~
Saya mencoba solusi -L -l,
~~~

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

~~~
tetapi kemudian penaut berpikir itu dapat menggunakan pustaka yang berbeda dengan nama yang sama di lokasi yang berbeda, dan saya mendapatkan runtime daripada kesalahan tautan waktu.

~~~
saat runtime...
dyld: pengikatan simbol malas gagal: Simbol tidak ditemukan: _luajit_ctypeid
Direferensikan dari: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Diharapkan di: /usr/local/lib/libluajit-5.1.2.dylib

dyld: Simbol tidak ditemukan: _luajit_ctypeid
Direferensikan dari: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Diharapkan di: /usr/local/lib/libluajit-5.1.2.dylib

SIGTRAP: jebakan jejak
PC=0x7fff66ff4075 m=0 kode sig=1
sinyal tiba selama eksekusi cgo
~~~
/usr/local/lib/libluajit-5.1.2.dylib bukan perpustakaan yang diperlukan, meskipun itu ditautkan secara dinamis; melainkan harus yang ditentukan dalam ${SRCDIR}/../../../LuaJIT/LuaJIT/src/libluajit.a.

Jadi masih mencari solusi.

Pembaruan: sepertinya menambahkan ini ke makefile saya berhasil.
~ekspor CGO_LDFLAGS_ALLOW="${GOPATH}/src/github.com/gijit/gi/vendor/github.com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a";~

Pembaruan: Untungnya, Ian menunjukkan bahwa versi regex yang lebih pendek akan berfungsi:
~ekspor CGO_LDFLAGS_ALLOW=".*.a";~

Untuk apa -Wl,-framework? Jika itu kerangka kerja Apple, ia memiliki argumen, jadi Anda mungkin ingin -Wl,-framework,foo. Tetapi jika itu adalah kerangka kerja Apple maka -framework (tidak -Wl,) berfungsi dengan baik.

Dengan 1.10rc2, golang.org/x/net/internal/socket tidak membangun lagi untuk 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

(Tidak ada cgo yang terjadi di sini karena ini adalah build silang, tapi saya rasa itu tidak masalah.)

Saya tidak dapat menautkan ke file lib statis dengan menentukan path lengkap ke sana:

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

Saya tidak melihat solusi untuk itu :(

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

@ianlancetaylor , terima kasih!

yang akan dilakukan untuk saya, tetapi memberitahu semua orang lain yang menggunakan proyek saya untuk melakukan CGO_LDFLAGS_ALLOW='.*\.a$' untuk pergi 1.9.4 tampaknya agak cerdik.

semoga kedepannya ada solusi yang lebih baik (out of the box).

@piotrnar Ya, inti dari masalah ini adalah untuk mengumpulkan semua perubahan yang perlu kita buat ke daftar putih. Tentu saja kami akan memasukkan file .a ke daftar putih.

bisa tolong tambahkan juga -fstack-protector ?

Terima kasih :)

Tolong daftar putih -static-libstdc++ .

Paket github.com/flynn/hid gagal dibangun dengan 1.9.4 karena meneruskan -fconstant-cfstrings melalui LDFLAGS di darwin.

Harap tambahkan bendera tautan ini ke daftar putih
-Wl,-Bstatis
-Wl,-Bdinamis
-Wl,--mulai-grup
-Wl,--grup akhir

Jujur: Pada titik ini, daftar hitam opsi buruk tampaknya lebih berguna daripada daftar putih yang begitu luas bagi saya.

Ke depan, daftar hitam akan berarti bahwa jika beberapa opsi kompiler baru yang berpotensi tidak aman diperkenalkan, semua rilis Go akan menjadi rentan terhadap opsi itu. Sejauh kita dapat melindungi dari serangan semacam ini sama sekali, saya pikir itu harus menjadi daftar putih.

beberapa opsi kompiler baru yang berpotensi tidak aman diperkenalkan

Saya masih berpikir daftar hitam lebih disukai. Karena itu memotong dua arah. Jika ada opsi kompiler baru yang tidak dapat digunakan sampai masuk daftar putih, itu sepertinya memerlukan rilis Go baru setiap kali kompiler C baru menambahkan tanda...

@gliserin Itu sebabnya kami menyediakan variabel lingkungan sebagai pintu keluar. Anda selalu dapat menggunakan variabel lingkungan hingga daftar putih diperbarui.

Masalahnya adalah variabel env tidak berfungsi untuk proyek yang diinstal murni melalui 'go get'.

Pendekatan lain: izinkan level teratas, bernama go project untuk mengatur variabel lingkungan.

Kemudian proyek 'go build' utama yang sedang diinstal dapat memasukkan bendera yang dibutuhkannya ke daftar putih, misalnya menggunakan regex ALLOW, sambil tetap mencegah proyek dependen melakukan hal-hal sewenang-wenang.

@gliserin Saya tidak yakin saya mengerti cara kerjanya. Tapi saya sarankan Anda membuka masalah terpisah untuk saran itu, daripada membahasnya tentang masalah ini, yang dimaksudkan untuk mengumpulkan opsi yang perlu masuk daftar putih.

Untuk saat ini kami telah memutuskan untuk menerapkan daftar putih. Itu mungkin berubah di masa depan tetapi masalah ini bukan tempat untuk membahasnya (jangan ragu untuk mengajukan yang baru). Kami mencoba mengumpulkan opsi yang seharusnya masuk daftar putih di sini dan tidak lebih.

Terima kasih.

bendera tidak valid di #cgo CFLAGS: -pipe

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

Hai, tolong tambahkan tanda ini ke daftar putih, -Wl,--enable-new-dtags

Tidak dapat membuat resep/qt

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

Menambahkan .*\.a ke flag yang diizinkan akan sangat bagus.
Lihat https://github.com/golang/go/issues/23807

--mms-bitfields juga tampaknya diperlukan.

Bukankah masuk akal untuk berasumsi bahwa setiap opsi kompiler (dan tautan, dll) ada karena suatu alasan, dan daftar putih harus mencakup semuanya kecuali yang secara khusus dianggap berbahaya? Jelas ada ratusan dari mereka dan pemeliharaan daftar putih tidak akan menyenangkan, tetapi jika itu jalan yang telah diputuskan...

Bukankah masuk akal untuk berasumsi bahwa setiap opsi kompiler (dan tautan, dll) ada karena suatu alasan, dan daftar putih harus mencakup semuanya kecuali yang secara khusus dianggap berbahaya? Jelas ada ratusan dari mereka dan pemeliharaan daftar putih tidak akan menyenangkan, tetapi jika itu jalan yang telah diputuskan...

Ini mungkin telah dibahas secara internal tetapi saya menemukan hal yang mengejutkan untuk rilis tambalan: Saya akan mengharapkan bendera yang menyinggung telah masuk daftar hitam terlebih dahulu untuk menyambungkan lubang plugin kompiler, dan sistem daftar putih diaktifkan untuk 1.10, yang daftarnya bisa dibangun naik selama RC. Env vars ekstra tidak cukup praktis untuk diintegrasikan dalam beberapa sistem build, dan saya mengamati ini menyebabkan orang hanya kembali ke 1.9.3 dan dengan demikian menjadi benar-benar tidak terlindungi, yang saya yakini sepenuhnya kontraproduktif.

Pada titik mana daftar putih yang penuh dengan wildcard dan regex menjadi daftar hitam yang menyamar?

gomobile menggunakan flag -fobjc-arc -fmodules -fblocks:

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

https://github.com/augustoroman/v8 menggunakan -pthread:

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

-flto

Bisakah Anda meletakkan daftar "disetujui" yang diurutkan menurut abjad di bagian atas masalah ini untuk tinjauan umum hingga pembaruan berikutnya keluar? Siapa pun yang mengajukan CL mungkin menghargai itu juga.

Saat ini (terutama karena masalah ini ada) saya lebih khawatir tentang apa yang lolos: flag build apa yang telah dihapus orang dari proyek mereka tanpa berkonsultasi dengan kami terlebih dahulu, memberi mereka keyakinan sesat bahwa cgo (dan dengan ekstensi Go) rusak dan buggy dan memiliki regresi dan pengembangnya tidak tahu apa yang mereka lakukan. : S (Atau lebih buruk lagi, Anda tidak tahu apa yang Anda lakukan dan jelas membangun paket saya salah, karena Anda adalah orang yang hilang ketergantungan xyz!)

Beberapa tautan "direferensikan masalah ini" mencantumkan lebih banyak tanda daftar hitam yang belum ada dalam masalah ini. Saya juga menjamin untuk memiliki daftar induk di bagian atas, terutama untuk menghindari duplikat. Orang-orang masih mengalami masalah arsip statis...

Ini membuat saya bertanya-tanya apakah gcc dan dentang sendiri dapat, atau bahkan harus , memberikan opsi --no-unsafe-options yang a) akan melakukan pekerjaan kotor untuk kami b) tahan terhadap perubahan di masa mendatang dan c) tidak dapat dimatikan oleh yang lain pilihan (setelah itu ada, itu ada, titik). Atau apakah go get merupakan situasi pertama dan satu-satunya di mana pemfilteran semacam ini diperlukan?

Jika kita bersikeras pada daftar putih, maka saya tidak tahu mengapa harus ada penundaan menunggu masukan.

Kompiler mendokumentasikan bendera mereka. Seperti yang dikatakan seseorang di atas, setiap bendera ada karena suatu alasan.

Pengambilan sampel dengan menunggu input pengguna tentang penggunaan akan kurang representatif, tidak dapat diandalkan, dan menghasilkan hasil yang menyakitkan bagi kita semua yang di masa depan merasa perlu akan bendera yang tidak disadari atau diambil sampelnya sekarang.

Selain itu, tampaknya mudah untuk mendapatkan daftar putih dengan prosedur ini, dalam kode semu:

Daftar semua kompiler C/C++ dan versi setiap kompiler yang didukung;
Untuk setiap versi kompiler, buat daftar semua flag yang tersedia dari dokumennya;
Untuk setiap bendera, putuskan untuk memasukkannya ke dalam daftar putih atau daftar hitam (tidak terlihat).

Tambahkan kode daftar putih untuk semua bendera di daftar putih yang terkumpul.

Saya masih berpikir ini gila (mendekati reductio ad absurdum) dibandingkan dengan memasukkan satu (atau dua) bendera yang rentan ke daftar hitam. Tapi dengan segala keseriusan, jika kita akan bersikeras pada daftar putih, algoritme di atas benar, menghilangkan dugaan, dan dapat dieksekusi tanpa penundaan. Mungkin satu-satunya masukan pengguna tambahan yang diperlukan adalah menetapkan kisaran kompiler/versi yang akan didukung.

Satu-satunya opsi yang penting di sini adalah opsi yang masuk akal untuk menempatkan baris #cgo CFLAGS atau #cgo LDFLAGS dalam file .go, atau masuk akal untuk menghasilkan dari panggilan ke pkg-config --cflags atau pkg-config --libs . Itu adalah bagian kecil dari jumlah total opsi kompiler.

Anda juga sangat meremehkan berapa banyak opsi yang dimiliki gcc dan dentang. Saya ragu mereka semua didokumentasikan, bahkan dalam kode sumber — saya tidak akan terkejut jika beberapa dihasilkan saat runtime! Juga mungkin ada opsi yang bergantung pada target tiga kali lipat... (Ini juga mengapa saya mengatakan bahwa daftar kanonik dari flag aman perlu dipertahankan oleh gcc dan dentang devs.)

Saya tidak bisa mengatakan apa-apa tentang keterlambatan dalam menambal bendera individu.

@anacrolix Di #23672 Anda menyarankan agar kami memasukkan daftar putih -Wl,-framework . Tapi -framework biasanya mengambil opsi. Bisakah Anda menunjukkan kasus penggunaan yang tepat? Terima kasih.

Anda juga sangat meremehkan berapa banyak opsi yang dimiliki gcc dan dentang

@andlabs Ian adalah pengembang gcc. Aku yakin dia sangat sadar.

Ubah https://golang.org/cl/93836 menyebutkan masalah ini: cmd/go: add options to security whitelist

Saya mengirim CL yang menurut saya mencakup semua opsi di atas: https://golang.org/cl/93836.

Tolong beri tahu saya jika Anda melihat ada masalah dengannya atau jika Anda mengetahui opsi apa pun yang digunakan orang yang tidak tercakup. Terima kasih.

Dari sudut pandang binding LLVM Go, opsi penaut berikut harus ada dalam daftar putih.

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

Opsi tautan dihasilkan oleh perintah llvm-config --ldflags dan opsi tersebut ada di output.

ref: https://reviews.llvm.org/D43070

@magical saya menanggapi @gliserin di sana =P

@ianlancetaylor juga minta maaf jika saya membuat Anda merasa terburu-buru dengan ini

@andlabs Ah, maaf

@ianlancetaylor Dengan CL itu saya masih tidak bisa membangun golang.org/x/net/internal/socket untuk Solaris. Tidak jelas bagi saya dari kesalahan bendera apa yang perlu saya minta.

$ ./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

@tenang ya. Saya pikir kita harus memperbaikinya dengan perubahan pada golang.org/x/net. Itu sudah mengandalkan banyak detail internal, dan saya pikir kita perlu mengubah cara melakukannya.

@calmh Apakah Anda dapat menguji https://golang.org/cl/94015 pada sistem Solaris yang sebenarnya?

Ubah https://golang.org/cl/94015 menyebutkan masalah ini: internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix Saya menemukan dari mana -Wl,-framework berasal: itu berasal dari file pkg-config untuk GLib, yang merupakan ketergantungan GTK+. Secara khusus, ini mencakup tautan CoreFoundation untuk tujuan internasionalisasi.

Referensi khusus: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 di mana @INTLLIBS@ mendapat -Wl,-framework -Wl,CoreFoundation dari https://gitlab .gnome.org/GNOME/glib/blob/master/m4macros/glib-gettext.m4#L143

Ada contoh -Wl,-framework di berbagai file pkg-config lainnya; beberapa adalah bagian dari proyek itu sendiri (seperti di atas), dan beberapa disuntikkan oleh Homebrew. Di sistem saya sekarang, saya melihat libcdio dan SDL keduanya menggunakan -Wl,-framework,FrameworkName . (Yang berarti, ya, -Wl,-framework -Wl,FrameworkName dan -Wl,-framework,FrameworkName keduanya ditemukan di file pkg-config. Lihat gambar.)

Ubah https://golang.org/cl/94018 menyebutkan masalah ini: cmd/compile: permit go:cgo_import_dynamic anywhere

@calmh Mencoba pendekatan berbeda di https://golang.org/cl/94018.

@andlabs Terima kasih, ditambahkan ke CL 93836.

Saya static menautkan SDL dan pgkconfig berisi -Wl,--no-undefined serta definisi preprosesor.

Saya ingin Anda menambahkan bendera di bawah daftar putih, sehingga mereka dapat mengkompilasi proyek yang menggunakan paket cgoemitter

buka github.com/supermock/cgoemitter-demo/x: tanda tidak valid di #cgo LDFLAGS: -Wl,-unresolved-symbols=ignore-all

Terima kasih banyak sebelumnya

Perbarui CL lagi.

Saya telah menambahkan halaman wiki untuk menjelaskan masalah ini di https://golang.org/wiki/InvalidFlag , dan saya memperbarui CL sehingga pesan kesalahan mengarahkan orang ke wiki.

Ubah https://golang.org/cl/94158 menyebutkan masalah ini: doc: add note about invalid flag errors to 1.10 release notes

invalid flag in #cgo LDFLAGS: -O3

Ubah https://golang.org/cl/94655 menyebutkan masalah ini: [release-branch.go1.10] doc: add note about invalid flag errors to 1.10 release notes

Ubah https://golang.org/cl/94675 menyebutkan masalah ini: [release-branch.go1.10] cmd/compile: permit go:cgo_import_dynamic anywhere

Ubah https://golang.org/cl/94676 menyebutkan masalah ini: [release-branch.go1.10] cmd/go: add options to security whitelist

Juga menerima masalah ini, jika berikut ini dapat ditambahkan

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

@bgk- Patch yang telah diterapkan alamat itu. Jika memutakhirkan ke 1.10 tidak layak sekarang, saya harus menyarankan menunggu untuk melihat apakah 1.9.5 terjadi.

Haruskah 1.10 memperbaiki masalah invalid pkg-config package name: --static ? Saya baru saja menarik versi terbaru dari homebrew dan saya masih melihatnya:

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

@ptoomey3 Lihat #23875

Pembukaan kembali untuk 1.9.5.

Saya akan menghindari masalah XY dan menjelaskan sepenuhnya apa yang saya lakukan. Saya membuat ekstensi postgresql dengan -buildmode=c-shared .

Dalam dokumentasi untuk membuat ekstensi C untuk postgresql apakah ini sebagai cara untuk membangun objek bersama:

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

Jadi saya telah menambahkan #cgo LDFLAGS: -shared ke kode sumber saya. Ini berfungsi hingga saat ini (go1.10) ketika berhenti membangun dengan:

invalid flag in #cgo LDFLAGS: -shared

Baru saja meraih go 1.10, mengalami ini:

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

Ini adalah flag penaut gcc untuk memaksa penautan statis untuk apa pun setelah opsi itu pada baris tautan.

@spackard Sebagai catatan, bukan itu yang dimaksud dengan opsi itu. Anda memikirkan -Bstatic . Opsi -static mengarahkan penaut untuk tidak mencari pustaka bersama apa pun untuk memenuhi opsi -l . -static bukan pilihan posisi; tidak masalah di mana itu muncul di baris perintah.

@ianlancetaylor Anda benar tentang posisi. Begitulah cara kami memaksa tautan statis. Sebagai catatan, menambahkannya ke CGO_LDFLAGS_ALLOW berhasil.

Saya mengalami masalah yang sama

invalid flag in #cgo CFLAGS: -m32

Kami mencapai ini dengan -O3, -static-libgcc dan -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

bendera tidak valid di #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++

tanda tidak valid di #cgo LDFLAGS: -static-libgcc

-static-libstdc++:

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

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

tanda tidak valid di #cgo LDFLAGS: -static-libstdc++

menggunakan daftar putih statis hardcoded adalah ide yang buruk, mungkin kita harus menggunakan file konfigurasi dengan beberapa pengaturan default seperti

$GOROOT/bin/cgo.cfg
[daftar putih]
blablabla
...

jadi kita bisa melakukan beberapa penyesuaian

@kruglinski Anda dapat menyesuaikan dengan menggunakan variabel lingkungan CGO_CFLAGS_ALLOW dan teman-teman.

@ianlancetaylor

Maaf, saya baru saja melewatkan ini, :-) Senang tahu, banyak yang berpikir!

24124 melaporkan opsi penaut berikut:

-Wl,-z,relro

Opsi penaut -Wl,--subsystem,windows dan opsi kompiler -mwindows keduanya tidak ada.

Saya mencoba membuat gomobile/gobind menghasilkan binding mandiri. Beberapa pekerjaan itu melibatkan konversi variabel lingkungan CGO_*FLAGS ke #cgo directives, yang menemukan beberapa flag lagi:

````
-isysroot(ios)
-mios-simulator-versi-min=(ios)
-miphoneos-versi-min=(ios)

-target(untuk Android)
--sysroot(untuk Android)
-gcc-toolchain(untuk Android)
````

Saya percaya semua kecuali yang terakhir, -gcc-toolchain, aman untuk ditambahkan ke daftar putih.

Bendera berikut diperlukan untuk membuat binding Go untuk mesin game Godot tanpa CGO_LDFLAGS_ALLOW di macOS:

-Wl,-undefined,dynamic_lookup

Lebih banyak CFLAGS dari zchee/libhyperkit :

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

v8worker membutuhkan -stdlib=libstdc++ di Mac OS X .

CL 103156 OK untuk Go 1.9.5

Ubah https://golang.org/cl/103135 menyebutkan masalah ini: [release-branch.go1.9] cmd/go: add options to security whitelist

Saya tidak bisa melihatnya di daftar, bisakah libtool juga masuk daftar putih?

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

@PassKit -I adalah cflag (yang ada dalam daftar) bukan ldflag, mengapa Anda memasukkannya ke ldflags?

Dibuka kembali untuk mengumpulkan lebih banyak permintaan daftar putih.

Dari #24703

CFLAGS: -fno-plt

Pada titik ini saya pikir tidak apa-apa untuk memutuskan bahwa kami hanya akan memperbarui cabang rilis 1.9 dan 1.10 jika beberapa paket populer gagal dibangun dan entah bagaimana belum dilaporkan. Saya tidak berpikir kita perlu terus mendukung setiap opsi acak. Kita bisa menambahkannya ke tip untuk 1.11. Apakah kita melacak mereka dalam masalah ini atau di tempat lain, saya tidak peduli.

sgtm

@AlexRouSg masalah saya terkait dengan perpustakaan ini, yang merekomendasikan daftar putih "-I" sebagai ldflag, yang saat ini saya gunakan sebagai solusi. https://github.com/miekg/pkcs11/issues/63

Maaf terlambat, tetapi alangkah baiknya jika ini masuk daftar putih di 1.9.5 atau 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

dan

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

Terima kasih sebelumnya.

@therecipe Kita bisa menambahkannya ke 1.11. Tetapi untuk 1.9.5 atau 1.10.2: paket apa yang membutuhkan ini?

@ianlancetaylor Itu semua diperlukan untuk berbagai target https://github.com/therecipe/qt
Tidak apa-apa jika Anda tidak akan memasukkan semuanya ke daftar putih sekaligus, tetapi beri tahu saya yang mana yang harus saya tangani sendiri.

Saya akan menebak itu paket Qt mereka sendiri, yang saya tahu cukup tua untuk mapan; Saya tidak sepenuhnya yakin apakah itu (orang lain akan perlu untuk mengatakan).

Yang telah dibilang:

• Bukankah beberapa LDFLAGS sudah masuk daftar putih tanpa awalan -Wl, ?
• Apakah -e berpengaruh di Go?
• Bukankah -F sudah masuk daftar putih? Itu ternyata menjadi opsi yang saya maksud di atas .
• (Kepada @therecipe) Mengapa Anda menjaga -D dengan -Wp ? Apakah ada alasan untuk menetapkan makro tetapi hanya di praprosesor? Saya tidak tahu jenis voodoo Qt apa yang dilakukan di sini... Atau apakah ini daftar opsi yang direkomendasikan yang disediakan oleh Qt sendiri?
• (Kepada @ianlancetaylor) Saya dapat memahami dengan tidak mem-backport opsi baru ke 1,9 (Saya ambivalen dengan masalah ini karena saya tidak memiliki metrik penggunaan versi Go), tetapi mengapa 1,10 hingga 1,12 tidak dirilis?
• Terlepas dari jawaban di atas, saya ingin tahu apakah mem-backport opsi ARM ABI yang terdaftar di sana layak dilakukan ...

@andlabs Hanya karena kita harus berhenti kapan-kapan, jadi mengapa tidak berhenti sekarang? Tapi saya baik-baik saja dengan terus mem-backport patch jika tampaknya cukup berguna.

@andlabs Ya, itu semua adalah flag yang direkomendasikan. Saya sendiri tidak menambahkan satu pun secara manual.
-Wp,-D_FORTIFY_SOURCE=2 berasal dari iirc target ikan layar, saya tidak tahu mengapa mereka melakukan itu.

@therecipe dalam hal ini, di mana Qt dan Sailfish membuat saran itu (yaitu, apakah ada halaman web atau alat CLI yang memberikannya kepada Anda)? Aku penasaran sekarang.

Sementara itu, sementara daftar itu ditangani oleh tim Go, saya masih bertanya-tanya berapa banyak peringatan LDFLAGS Anda yang hilang jika Anda menghapus awalan -Wl, ; coba itu dan lihat? Sama untuk awalan -Wp, dalam satu CFLAGS . Saya tidak tahu apakah ini akan memiliki efek buruk pada build, tetapi seharusnya tidak di dunia yang ideal karena untuk itulah LDFLAGS... (Anda juga harus mengubah koma menjadi spasi. -Wx, Opsi

@andlabs Ya, salah satu alat build Qt qmake menggunakan *.pro , *.spec (mkspec), *.conf dan banyak format lain untuk menghasilkan Makefile biasa. Saya hanya memberinya beberapa file *.pro dummy dan mengekstrak flag dari Makefiles. Dengan begitu, saya tidak benar-benar harus menyelesaikan dependensi sendiri, proses build dapat bekerja lebih mudah dengan lib pihak ketiga, saya tidak perlu mengelola flag c atau ld secara manual dan target yang belum diuji atau versi Qt yang lebih baru/lama keluar dari kotak sebagian besar waktu. Saya kadang-kadang harus membuat daftar hitam beberapa bendera yang menyebabkan masalah, tetapi itu sangat jarang.

Saya mencoba menemukan mkspec sailfish yang menarik -Wp,-D_FORTIFY_SOURCE=2 , tetapi mungkin terkubur di suatu tempat di mersdk atau lebih. Tapi di sini adalah daftar resmi target yang didukung TQtC untuk: https://github.com/qt/qtbase/tree/5.11/mkspecs dan ada banyak target tidak resmi yang dikelola oleh pihak independen. Itu sebabnya saya benar-benar tidak ingin mengacaukan bendera secara manual.

Saya dapat memasukkan mereka ke daftar putih di alat build yang digunakan oleh pengikatan (yang membungkus go ) sementara itu, tetapi pengguna Go biasa yang hanya ingin menggunakan go build ... cepat atau lambat akan menimbulkan masalah .. .(setidaknya untuk target desktop)

-cepat-matematika

Driver klien SAP HANA resmi (pustaka bersama berbasis cgo) hadir dengan #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN yang menghasilkan go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath . Lihat juga dokumentasi SAP di https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca5629083869069e5.html?q=golang%20driver untuk detailnya.

@cbgo lihat #23672

Kode yang meneruskan pasangan flag dan argumen ke linker sekarang harus menggunakan satu flag -Wl, bukan dua: gunakan #cgo LDFLAGS: -Wl,-rpath,$ORIGIN, bukan #cgo LDFLAGS: -Wl,-rpath -Wl,$ ASAL.

@AlexRouSg terima kasih banyak. Seharusnya saya membacanya lebih hati-hati :-)

@PassKit Apakah Anda memecahkan masalah ini?

@ zcm211 Jika Anda berbicara tentang https://github.com/miekg/pkcs11 mereka menghapus bendera tautan -I... pada bulan Februari. Jika Anda menggunakan paket yang menggunakannya maka Anda harus mengatur variabel lingkungan CGO_LDFLAGS_ALLOW="-I.*"

darwin 64-bit, go1.10.2, saya pikir file .o masuk daftar putih untuk LDFLAG, tetapi saya mendapatkan:
~jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (master) $ make runcd chez_scheme_9.5.1/c;








karena pembukaan cgo di https://github.com/go-interpreter/chezgo/blob/master/embed.go#L10
~~~

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

~~~

@gliserin Menurut https://go-review.googlesource.com/c/go/+/94676 mereka. Mungkin mencoba jalur lengkap alih-alih jalur relatif?

Tangkapan bagus @AlexRouSg , regex yang diterima
~re( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) ), // input penghubung langsung: xo atau libfoo.so (tetapi tidak -foo.o atau @foo.o)~
src/cmd/go/internal/work/security.go#121 harus mengizinkan file .o dimulai dengan . untuk mendukung jalur relatif.

Lagi pula, saya tidak dapat memprediksi GOPATH pengguna, atau seberapa bersarang lokasi file itu nantinya, jadi menyetel jalur absolut tidak praktis.

Apakah file .o ada di direktori sumber? Jika demikian, merujuk ke direktori sumber adalah untuk apa ${SRCDIR} disediakan. (Saya lupa secara spesifik mengapa ini diperkenalkan, tetapi itu bukan karena masalah ini.)

@andlabs Bahkan jika ada solusi yang kikuk, jalur relatif harus dapat ditautkan, dan itu jelas merupakan bug.

Memang, kecuali IIRC, tidak ada jaminan bahwa tautan akan relatif KE direktori sumber (bisa jadi di $WORK , dan kemudian jalur relatif Anda rusak lagi)... Sekali lagi, saya lupa sejarah; orang lain perlu menjelaskan.

gtk4 menggunakan -mfpmath=sse

@ianlancetaylor Alih-alih memiliki daftar putih terpisah untuk cflag dan ldflags, haruskah hanya ada satu daftar? gcc/llvm tampaknya tidak peduli bahwa Anda mencampur ldflags ke cflags dan sebaliknya. Dan sepertinya terkadang pengembang C melakukan itu yang menyebabkan masalah seperti #25493 atau https://github.com/golang/go/issues/23749#issuecomment -379969818

Ah, sepertinya kita sudah memiliki tiket, jadi izinkan saya menyebutkan "-D_THREAD_SAFE" dari protobuf seperti yang didokumentasikan di #25493

Ubah https://golang.org/cl/115415 menyebutkan masalah ini: cmd/go: accept more safe CFLAGS/LDFLAGS

Ubah https://golang.org/cl/115435 menyebutkan masalah ini: [release-branch.go1.10] cmd/go: accept more safe CFLAGS/LDFLAGS

Ubah https://golang.org/cl/115436 menyebutkan masalah ini: [release-branch.go1.9] cmd/go: accept more safe CFLAGS/LDFLAGS

Hai teman-teman,
Mengapa masalah ini ditutup ketika kami masih tidak dapat membangun bimg dengan Go versi terbaru pada 9/4/2018?
Silakan lihat masalah: https://github.com/h2non/bimg/issues/230
Kami tidak dapat membangun apa pun yang mengimpor bimg sejak Go 1.10 dan masalahnya masih ada di Go 1.11
Pesan kesalahan yang kami dapatkan adalah ini:

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

Ada saran?

EDIT:
Saya membuat masalah baru: https://github.com/golang/go/issues/27496

Saya yakin daftar putih ini bertanggung jawab untuk hal berikut: https://github.com/alexflint/gallium/issues/63

@alexflint Masalah ini sudah ditutup, silakan buat yang baru