23737 रिपोर्ट है कि pkg-config -libs द्वारा उत्पन्न झंडे को संकलक श्वेतसूची के खिलाफ जांचा जा रहा है, और CGO_CFLAGS_ALLOW , जब उन्हें लिंकर श्वेतसूची और CGO_LDFLAGS_ALLOW बजाय चेक किया जाना चाहिए। इसे ठीक करने के लिए एक CL है: https://golang.org/cl/92755।

लिंकर श्वेतसूची को .a फाइलें स्वीकार करनी चाहिए क्योंकि यह पहले से ही .o , .so , आदि फाइलों को स्वीकार करती है। इसे ठीक करने के लिए एक CL है: https://golang.org/cl/92855। यह #23739 है।

#23672 पर टिप्पणियाँ इन संकलक विकल्पों की सूची बनाएं:

-fno-rtti
-fpermissive

और ये लिंकर विकल्प:

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

23742 संकलक विकल्प जोड़ने का सुझाव देता है -fmodules । क्लैंग कंपाइलर कई -fmodules विकल्पों का समर्थन करता है, लेकिन यह स्पष्ट नहीं है कि वे सभी सुरक्षित हैं। विशेष रूप से -fmodules-cache-path और -fmodules-user-build-path एक पथ निर्दिष्ट करने की अनुमति देने लगते हैं जो क्लैंग मॉड्यूल को पढ़ने के लिए उपयोग करेगा, जो शायद विभिन्न तरीकों से संकलन मोड को बदल सकता है।

23743 लिंकर विकल्प जोड़ने का सुझाव देता है -Wl,--no-as-needed । इसके लिए एक सीएल है: https://golang.org/cl/92795।

23744 इन कंपाइलर विकल्पों को जोड़ने का सुझाव देता है:

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

कई कंपाइलर और लिंकर विकल्प हैं जिनका उपयोग सिंगल डैश या डबल डैश के साथ किया जा सकता है। हमें श्वेतसूची में भी इसी तरह शिथिल होना चाहिए।

ऑर्थोगोनैलिटी के लिए: मैं भूल जाता हूं कि -framework के खोज पथ में निर्देशिका जोड़ने का विकल्प पहले से ही कवर किया गया है या नहीं। मैं यह भी भूल जाता हूं कि वह कौन सा विकल्प है। (सामान्य उपयोग का मामला जिसके बारे में मैं सोच सकता हूं वह है /Library/Frameworks , जो वह जगह है जहां ऐप्पल ऐप-विशिष्ट ढांचे रखता है, और डिफ़ॉल्ट रूप से खोजा नहीं जाता है।)

पहले स्थान पर cgo के साथ उपयोग करने के लिए -as-needed सुरक्षित है? यह ब्लॉग पोस्ट (जो पहला परिणाम है जो मुझे "जीसीसी के रूप में आवश्यक" के लिए मिल सकता है) का कहना है कि यह एक स्थितित्मक तर्क है, लेकिन मुझे यकीन नहीं है कि सीजीओ कुछ भी गारंटी देता है कि आपके झंडे परिणामी कमांड लाइनों पर कहां जाते हैं।

@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

कोड को देखते हुए (1.9.4 जाने के लिए) ऐसा प्रतीत होता है कि कोई भी पर्यावरण चर नहीं है जिसका उपयोग pkg-config तर्कों को श्वेतसूची में करने के लिए किया जा सकता है।

@ rgburke pkg-config आउटपुट अन्य आउटपुट के समान FLAGS_ALLOW चर के माध्यम से जाता है।

हालांकि, ऐसा प्रतीत होता है कि pkg-config -libs CGO_CFLAGS_ALLOW जांच करता है जब इसे CGO_LDFLAGS_ALLOW जांचना चाहिए।

हम एक क्लोज-सोर्स प्रोजेक्ट में बड़ी संख्या में सी पुस्तकालयों को स्थिर रूप से जोड़ते हैं। अब तक हम निम्नलिखित कार्य कर रहे हैं:

#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)।

.a और .so के विपरीत जिसे सिद्धांत रूप में "-L${SRCDIR} से नियंत्रित किया जा सकता है
-नाम", जोड़ना
लिंकर कमांड में अतिरिक्त ऑब्जेक्ट फ़ाइलों को इस तरह से ठीक नहीं किया जा सकता है।

CGO_LDFLAGS_ALLOW सेट करना एक वैकल्पिक हल है, लेकिन यह बहुत बोझिल है।
एक और
विकल्प मेरे file.o का नाम बदलकर file.syso करना है, हालांकि, मेरे विशिष्ट के लिए
मामला, मैं उपयोग नहीं कर सकता
यह विकल्प क्योंकि मैं केवल उस file.o को शामिल करता हूं जब एक विशिष्ट बिल्ड टैग होता है
शामिल (द
बिल्ड टैग उस फ़ाइल पर लागू होता है जिसमें #cgo LDFLAGS प्रस्तावना शामिल है) और
अब कोई रास्ता नहीं है
syso फ़ाइल नाम में मनमाना बिल्ड टैग सेट करने के लिए।

यदि हम पिछले परिनियोजित गो संस्करणों की उपेक्षा करते हैं, तो हम a . को शामिल करने में सक्षम हो सकते हैं
नया
"#cgo LDLIBS" जिसे विशेष रूप से लिंकर में अधिक फ़ाइलें जोड़ने के लिए डिज़ाइन किया गया है
कमांड लाइन।
तब हमारे पास LDLIBS के लिए एक सख्त नियम हो सकता है (केवल फ़ाइल नाम, और कोई डैश नहीं
उपसर्ग में अनुमति है।)

हमने इसे --std=c99 साथ मारा है

-एसटीडी=सी++11

मुझे लगता है -std=सफेद सूचीबद्ध होना चाहिए?

संभवतः श्वेतसूची पर: -fopenmp

गो 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

मैं -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} ।

इस टिप्पणी को जोड़ने से इस समस्या में libthing.a संदर्भ के साथ एक उदाहरण शामिल है जिसे हल करने के लिए SRCDIR विस्तार की आवश्यकता है।

OSX पर, अपने cgo ध्वज प्रतिबंधों के साथ नए खनन किए गए go1.9.4 के साथ, मैं विशेष रूप से लिंकर को बता रहा था कि .a संग्रह किससे लिंक करना है: (यहां https://github.com/gijit/gi/blob/master/vendor/ github.com/glycerine/golua/lua/lua.go#L10 )

~~~

सीजीओ एलडीएफएलएजीएस: ${SRCDIR}/../../../LuaJIT/LuaJIT/src/libluajit.a -lm -ldl

~~~

निर्माण के प्रयास पर उत्पादन करता है:

~निर्माण करनागो बिल्ड -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_version_go1.9.4_darwin/amd64" -o giगो बिल्ड github.com/gijit/gi/vendor/github.com/ग्लिसरीन/गोलुआ/लुआ: #cgo LDFLAGS में अमान्य ध्वज: /Users/jaten/go/src/github.com/gijit/gi/vendor/github. कॉम/ग्लिसरीन/गोलुआ/लुआ/../../../लुआजित/लुआजित/src/libluajit.aबनाना [2]: * [बिल्ड] त्रुटि 1मेक [1]: [इंस्टॉल] त्रुटि 2बनाना: ** [इंस्टॉल करें] त्रुटि 2jaten@jatens-MacBook-Pro ~/go/src/github.com/gijit/gi (मास्टर) $~
मैंने -L -l वर्कअराउंड की कोशिश की,
~~~

सीजीओ एलडीएफएलएजीएस: -एल${एसआरसीडीआईआर}/../../../लुआजिट/लुआजिट/src -ल्लुआजीत -एलएम -एलडीएल

~~~
लेकिन फिर लिंकर सोचता है कि यह एक ही नाम से एक अलग स्थान पर एक अलग पुस्तकालय का उपयोग कर सकता है, और मुझे लिंकटाइम त्रुटि के बजाय रनटाइम मिलता है।

~~~
चलने के समय पर...
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

सिगट्रैप: ट्रेस ट्रैप
पीसी = 0x7fff66ff4075 मीटर = 0 सिगकोड = 1
सीजीओ निष्पादन के दौरान आया संकेत
~~~
/usr/local/lib/libluajit-5.1.2.dylib आवश्यक पुस्तकालय नहीं है, हालांकि यह गतिशील रूप से जुड़ा हुआ था; बल्कि यह ${SRCDIR}/../../../LuaJIT/LuaJIT/src/libluajit.a में निर्दिष्ट होना चाहिए।

तो अभी भी एक कामकाज की तलाश में है।

अद्यतन: ऐसा लगता है कि इसे मेरे मेकफ़ाइल में जोड़ना चाल है।
~निर्यात CGO_LDFLAGS_ALLOW="${GOPATH}/src/github.com/gijit/gi/vendor/github.com/ग्लिसरीन/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a";~

अद्यतन: शुक्र है, इयान ने बताया कि छोटा रेगेक्स संस्करण करेगा:
~निर्यात CGO_LDFLAGS_ALLOW=".*.a";~

-Wl, -ढांचे के लिए क्या है? यदि वह Apple ढांचा है, तो इसका एक तर्क है, इसलिए आप शायद चाहते हैं -Wl,-framework,foo. लेकिन अगर यह ऐप्पल फ्रेमवर्क है तो -फ्रेमवर्क (नो-डब्लूएल,) भी काम करता है।

1.10rc2 के साथ, golang.org/x/net/internal/socket सोलारिस के लिए और निर्माण नहीं करता है।

$ 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

(यहां कोई सीजीओ नहीं हो रहा है क्योंकि यह एक क्रॉस बिल्ड है, लेकिन मुझे लगता है कि इससे कोई फर्क नहीं पड़ता।)

मैं इसे एक पूर्ण पथ निर्दिष्ट करके एक स्थिर lib फ़ाइल से लिंक नहीं कर सकता:

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

मुझे इसके लिए कोई समाधान नहीं दिख रहा है :(

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

@ianlancetaylor , धन्यवाद!

यह मेरे लिए करेगा, लेकिन मेरे प्रोजेक्ट का उपयोग करने वाले अन्य सभी लोगों को CGO_LDFLAGS_ALLOW='.*\.a$' लिए 1.9.4 जाने के लिए कहना थोड़ा अजीब लगता है।

उम्मीद है कि भविष्य में एक बेहतर (बॉक्स से हटकर) समाधान होगा।

@piotrnar हां, इस मुद्दे का उद्देश्य उन सभी परिवर्तनों को एकत्र करना है जो हमें श्वेतसूची में करने की आवश्यकता है। निश्चित रूप से हम .a फाइलों को श्वेतसूची में डाल देंगे।

क्या आप कृपया -fstack-protector भी जोड़ सकते हैं?

धन्यवाद :)

श्वेतसूची -static-libstdc++ कृपया।

पैकेज github.com/flynn/hid डार्विन पर LDFLAGS के माध्यम से -fconstant-cfstrings पास होने के कारण 1.9.4 के साथ निर्माण करने में विफल रहता है।

कृपया इन लिंकर फ़्लैग्स को श्वेत सूची में जोड़ें
-Wl, -बस्टेटिक
-डब्ल्यूएल, -बडायनामिक
-डब्ल्यूएल,--स्टार्ट-ग्रुप
-Wl,--अंत-समूह

ईमानदारी से: इस बिंदु पर मेरे लिए इतनी व्यापक श्वेतसूची की तुलना में खराब विकल्पों की एक ब्लैकलिस्ट अधिक उपयोगी लगती है।

आगे जाकर, एक ब्लैकलिस्ट का मतलब होगा कि यदि कुछ नए संभावित-असुरक्षित कंपाइलर विकल्प पेश किए गए, तो सभी गो रिलीज़ उस विकल्प के लिए असुरक्षित हो जाएंगे। जिस हद तक हम इस तरह के हमले से बिल्कुल भी बचाव कर सकते हैं, मुझे लगता है कि इसे एक श्वेतसूची में होना चाहिए।

कुछ नए संभावित-असुरक्षित संकलक विकल्प पेश किए गए

मुझे अभी भी लगता है कि ब्लैकलिस्ट बेहतर है। क्योंकि यह दोनों तरह से काटता है। यदि किसी भी नए कंपाइलर विकल्प का उपयोग तब तक नहीं किया जा सकता है जब तक कि इसे श्वेतसूची में नहीं रखा जाता है, ऐसा लगता है कि हर बार कोई नया सी कंपाइलर ध्वज जोड़ने पर एक नई गो रिलीज की आवश्यकता होगी ...

@ग्लिसरीन इसलिए हम एस्केप हैच के रूप में पर्यावरण चर प्रदान करते हैं। श्वेतसूची अद्यतन होने तक आप हमेशा पर्यावरण चर का उपयोग कर सकते हैं।

समस्या यह है कि env चर उन परियोजनाओं के लिए काम नहीं करते हैं जो विशुद्ध रूप से 'गो गेट' के माध्यम से स्थापित की जाती हैं।

एक अन्य दृष्टिकोण: पर्यावरण चर सेट करने के लिए गो प्रोजेक्ट नामक शीर्ष स्तर की अनुमति दें।

फिर प्राथमिक 'गो बिल्ड' प्रोजेक्ट स्थापित किया जा रहा है, इसकी ज़रूरत के झंडे को श्वेतसूची में डाल सकता है, उदाहरण के लिए ALLOW रेगेक्स का उपयोग करना, जबकि अभी भी निर्भर परियोजनाओं को मनमानी चीजें करने से रोकना है।

@ग्लिसरीन मुझे यकीन नहीं है कि मैं समझता हूं कि यह कैसे काम करेगा। लेकिन मेरा सुझाव है कि आप इस मुद्दे पर चर्चा करने के बजाय उस सुझाव के लिए एक अलग मुद्दा खोलें, जिसका उद्देश्य उन विकल्पों को एकत्र करना है जिन्हें श्वेतसूची में डालने की आवश्यकता है।

अभी के लिए हमने श्वेतसूची लागू करने का निर्णय लिया है। यह भविष्य में बदल सकता है लेकिन यह मुद्दा इस पर चर्चा करने का स्थान नहीं है (एक नया फाइल करने के लिए स्वतंत्र महसूस करें)। हम उन विकल्पों को एकत्र करने का प्रयास कर रहे हैं जिन्हें यहां श्वेतसूची में डाला जाना चाहिए और इससे अधिक कुछ नहीं।

धन्यवाद।

#cgo CFLAGS में अमान्य ध्वज: -पाइप

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

नुस्खा/क्यूटी नहीं बना सकता

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 के लिए एक श्वेतसूची प्रणाली सक्षम की गई थी, जिसकी सूची बनाई जा सकती थी। आरसी के दौरान ऊपर कुछ बिल्ड सिस्टम में एकीकृत करने के लिए अतिरिक्त एनवी वर्र्स काफी व्यावहारिक नहीं हैं, और मैंने देखा कि यह लोगों को 1.9.3 पर वापस ले जाता है और इस प्रकार पूरी तरह से असुरक्षित होता है, जो मुझे लगता है कि पूरी तरह से प्रतिकूल है।

किस बिंदु पर वाइल्डकार्ड और रेगेक्स से भरी श्वेतसूची भेस में काली सूची बन जाती है?

गोमोबाइल झंडे का उपयोग करता है -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

-फ्लोटो

क्या आप इस मुद्दे के शीर्ष पर "अनुमोदित" लोगों की वर्णानुक्रम में क्रमबद्ध सूची को अवलोकन के लिए रख सकते हैं जब तक कि अगला अपडेट समाप्त न हो जाए? जो कोई भी सीएल जमा करता है वह भी इसकी सराहना कर सकता है।

अभी (विशेषकर चूंकि यह समस्या मौजूद है) मैं इस बारे में अधिक चिंतित हूं कि दरारों के माध्यम से क्या फिसल रहा है: लोगों ने पहले हमसे परामर्श किए बिना अपनी परियोजनाओं से कौन से झंडे हटा दिए हैं, जिससे उन्हें गुमराह विश्वास है कि सीजीओ (और विस्तार से गो) टूटा हुआ है और छोटी गाड़ी और प्रतिगमन है और इसके डेवलपर्स नहीं जानते कि वे क्या कर रहे हैं। :S (या इससे भी बदतर, आप नहीं जानते कि आप क्या कर रहे हैं और स्पष्ट रूप से मेरे पैकेज को गलत बना रहे हैं, क्योंकि आप एक लापता निर्भरता xyz हैं!)

कुछ "इस मुद्दे को संदर्भित" लिंक अधिक ब्लैकलिस्टेड झंडे सूचीबद्ध करते हैं जो इस मुद्दे में अभी तक उचित नहीं हैं। मैं शीर्ष पर एक मास्टर सूची रखने की भी पुष्टि करता हूं, विशेष रूप से डुप्लिकेट को दूर करने के लिए। लोग अभी भी स्थिर संग्रह समस्या में भाग रहे हैं...

इससे मुझे आश्चर्य होता है कि क्या जीसीसी और क्लैंग स्वयं --no-unsafe-options विकल्प प्रदान कर सकते हैं, या यहां तक ​​​​कि चाहिए कि ए) हमारे लिए गंदा काम करेगा बी) भविष्य के परिवर्तनों के लिए लचीला हो और सी) दूसरे द्वारा बंद नहीं किया जा सकता है विकल्प (एक बार यह वहाँ है, यह वहाँ है, अवधि)। या go get पहली और एकमात्र स्थिति है जहां इस तरह के फ़िल्टरिंग की आवश्यकता है?

यदि हम श्वेतसूची पर जोर देते हैं, तो मुझे नहीं पता कि इनपुट की प्रतीक्षा में देरी करने की आवश्यकता क्यों है।

संकलक अपने झंडे का दस्तावेजीकरण करते हैं। जैसा कि किसी ने ऊपर कहा है, प्रत्येक झंडे एक कारण से होते हैं।

उपयोग पर उपयोगकर्ता इनपुट की प्रतीक्षा करके नमूनाकरण कम-प्रतिनिधि, अविश्वसनीय होगा, और हम सभी के लिए दर्दनाक परिणाम देगा, जो भविष्य में उस ध्वज की आवश्यकता पाते हैं जिसे अभी महसूस नहीं किया गया था या नमूना नहीं किया गया था।

इसके अलावा छद्म कोड में इस प्रक्रिया द्वारा श्वेत सूची प्राप्त करना सीधा लगता है:

सभी सी/सी++ कंपाइलर्स और समर्थित प्रत्येक कंपाइलर के संस्करणों की सूची बनाएं;
प्रत्येक कंपाइलर-संस्करण के लिए, उनके दस्तावेज़ों से उपलब्ध सभी फ़्लैग्स को सूचीबद्ध करें;
प्रत्येक ध्वज के लिए, इसे श्वेतसूची या (अदृश्य) काली सूची में डालने का निर्णय लें।

संचित श्वेतसूची में सभी झंडों के लिए श्वेतसूची कोड जोड़ें।

मुझे अभी भी लगता है कि यह एक (या दो) कमजोर झंडों को ब्लैकलिस्ट करने की तुलना में पागल है (रिडक्टियो एड एब्सर्डम पर काम करना)। लेकिन पूरी गंभीरता से, अगर हम श्वेतसूची पर जोर देने जा रहे हैं, तो उपरोक्त एल्गोरिदम सही है, अनुमान को समाप्त करता है, और बिना किसी देरी के निष्पादित किया जा सकता है। शायद केवल अतिरिक्त उपयोगकर्ता इनपुट की आवश्यकता होगी जो समर्थित होने के लिए कंपाइलर्स/संस्करणों की श्रेणी स्थापित करे।

यहां केवल वही विकल्प महत्वपूर्ण हैं जो एक .go फ़ाइल में #cgo CFLAGS या #cgo LDFLAGS लाइन पर डालने के लिए उचित हैं, या कॉल से pkg-config --cflags तक आउटपुट के लिए उचित हैं pkg-config --libs । यह संकलक विकल्पों की कुल संख्या का एक छोटा उपसमूह है।

आप यह भी बहुत कम आंकते हैं कि जीसीसी और क्लैंग के पास कितने विकल्प हैं। मुझे संदेह है कि वे सभी दस्तावेज हैं, यहां तक ​​​​कि स्रोत कोड में भी - अगर कुछ रनटाइम पर उत्पन्न होते हैं तो मुझे आश्चर्य नहीं होगा! इसके अलावा ऐसे विकल्प भी हो सकते हैं जो लक्ष्य ट्रिपल-आश्रित हों ... (यही कारण है कि मैं कहता हूं कि सुरक्षित झंडों की एक विहित सूची को जीसीसी और क्लैंग देवों द्वारा बनाए रखने की आवश्यकता होगी।)

हालांकि, अलग-अलग झंडों को पैच करने में हुई देरी के बारे में मैं कुछ नहीं कह सकता।

@anacrolix Over #23672 में आपने सुझाव दिया कि हमें -Wl,-framework को श्वेतसूची में डालने की आवश्यकता है। लेकिन -framework आम तौर पर एक विकल्प लेता है। क्या आप सटीक उपयोग केस दिखा सकते हैं? धन्यवाद।

आप यह भी बहुत कम आंकते हैं कि जीसीसी और क्लैंग के पास कितने विकल्प हैं

@andlabs इयान एक जीसीसी डेवलपर है। मुझे यकीन है कि वह अच्छी तरह से वाकिफ है।

बदलें https://golang.org/cl/93836 इस मुद्दे का उल्लेख करता है: cmd/go: add options to security whitelist

मैंने एक सीएल भेजा है जो मुझे लगता है कि उपरोक्त सभी विकल्पों को शामिल करता है: https://golang.org/cl/93836।

कृपया मुझे बताएं कि क्या आप इसके साथ कोई समस्या देखते हैं या यदि आप किसी ऐसे विकल्प के बारे में जानते हैं जिसका लोग उपयोग कर रहे हैं जो इसे कवर नहीं करता है। धन्यवाद।

एलएलवीएम गो बाइंडिंग के दृष्टिकोण से, निम्नलिखित लिंकर विकल्प श्वेत सूची में होने चाहिए।

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

लिंकर विकल्प कमांड llvm-config --ldflags द्वारा उत्पन्न होते हैं और वे आउटपुट में होते हैं।

रेफरी: https://reviews.llvm.org/D43070

@magical मैं @glycerine का जवाब था पी वहाँ =

@ianlancetaylor भी माफी मांगता हूं अगर मैं आपको इसके साथ जल्दी महसूस कर रहा हूं

@andlabs आह, क्षमा करें

@ianlancetaylor उस सीएल के साथ मैं अभी भी सोलारिस के लिए 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

@ शांत हाँ। मुझे लगता है कि हमें इसे golang.org/x/net में परिवर्तनों के साथ ठीक करना होगा। यह पहले से ही कई आंतरिक विवरणों पर निर्भर है, और मुझे लगता है कि हमें ऐसा करने के तरीके को बदलने की जरूरत है।

@calmh क्या आप वास्तविक सोलारिस सिस्टम पर https://golang.org/cl/94015 का परीक्षण कर पाएंगे?

बदलें https://golang.org/cl/94015 इस मुद्दे का उल्लेख करता है: internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix मुझे पता चला कि -Wl,-framework कहाँ से आ रहा है: यह GLib के लिए pkg-config फ़ाइल से आ रहा है, जो GTK+ की निर्भरता है। विशेष रूप से, इसमें अंतर्राष्ट्रीयकरण उद्देश्यों के लिए CoreFoundation लिंक शामिल है।

विशिष्ट संदर्भ: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 जहां @INTLLIBS@ -Wl,-framework -Wl,CoreFoundation को https://gitlab से -Wl,-framework -Wl,CoreFoundation मिलता है .gnome.org/GNOME/glib/blob/master/m4macros/glib-gettext.m4#L143

कई अन्य पीकेजी-कॉन्फ़िगरेशन फ़ाइलों में अन्य -Wl,-framework उदाहरण हैं; कुछ स्वयं परियोजनाओं का हिस्सा हैं (ऊपर के रूप में), और कुछ होमब्रू द्वारा इंजेक्शन दिए गए हैं। अभी मेरे सिस्टम पर, मुझे 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 धन्यवाद, सीएल 93836 में जोड़ा गया।

मैं स्थिर लिंकिंग एसडीएल हूं और pgkconfig में -Wl,--no-undefined साथ-साथ प्रीप्रोसेसर परिभाषित है।

मुझे आपको सफेद सूची के नीचे झंडे जोड़ने की जरूरत है, ताकि वे उन परियोजनाओं को संकलित कर सकें जो cgoemitter पैकेज का उपयोग करते हैं

गो बिल्ड github.com/supermock/cgoemitter-demo/x: #cgo LDFLAGS में अमान्य ध्वज: -Wl,-unresolved-symbols=ignore-all

अग्रिम बहुत बहुत धन्यवाद

सीएल फिर से अपडेट करें।

मैंने https://golang.org/wiki/InvalidFlag पर इस समस्या का वर्णन करने के लिए एक विकी पृष्ठ जोड़ा है, और मैं 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 देखें #23875

1.9.5 के लिए फिर से खोलना।

मैं XY समस्या से बचूंगा और पूरी तरह से समझाऊंगा कि मैं क्या कर रहा हूं। मैं -buildmode=c-shared साथ एक पोस्टग्रेस्क्ल एक्सटेंशन बना रहा हूं।

पोस्टग्रेस्क्ल के लिए सी एक्सटेंशन बनाने के लिए प्रलेखन में यह साझा ऑब्जेक्ट बनाने का तरीका है:

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

लिंक लाइन पर उस विकल्प के बाद किसी भी चीज़ के लिए स्थिर लिंकिंग को बाध्य करने के लिए यह एक जीसीसी लिंकर ध्वज है।

@spackard रिकॉर्ड के लिए, उस विकल्प का मतलब यह नहीं है। आप -Bstatic बारे में सोच रहे हैं। -static विकल्प लिंकर को किसी भी -l विकल्पों को संतुष्ट करने के लिए किसी भी साझा पुस्तकालयों की खोज नहीं करने का निर्देश देता है। -static एक स्थितिगत विकल्प नहीं है; इससे कोई फर्क नहीं पड़ता कि यह कमांड लाइन पर कहां दिखाई देता है।

@ianlancetaylor आप स्थिति के बारे में सही हैं। इस तरह हम स्थिर लिंकिंग को मजबूर कर रहे हैं। रिकॉर्ड के लिए, इसे CGO_LDFLAGS_ALLOW जोड़ना काम करता है।

मुझे भी वही समस्या हो रही है

invalid flag in #cgo CFLAGS: -m32

हमने इसे -O3, -static-libgcc और -static-libstdc++ . के साथ मारा

-ओ3:

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

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

सीजीओ CFLAGS: -O3

#cgo LDFLAGS में अमान्य ध्वज: -O3

-स्थैतिक-libgcc:

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

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

#cgo LDFLAGS में अमान्य ध्वज: -स्थैतिक-libgcc

-स्थैतिक-libstdc++:

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

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

#cgo LDFLAGS में अमान्य ध्वज: -स्थैतिक-libstdc++

हार्डकोडेड स्थिर श्वेतसूची का उपयोग करना एक बुरा विचार है, हो सकता है कि हमें कुछ डिफ़ॉल्ट सेटिंग्स के साथ एक कॉन्फ़िग फ़ाइल का उपयोग करना चाहिए जैसे

$GOROOT/bin/cgo.cfg
[श्वेतसूची]
ब्लब्लब्ला
...

तो हम कुछ अनुकूलित कर सकते हैं

@kruglinski आप CGO_CFLAGS_ALLOW पर्यावरण चर और दोस्तों का उपयोग करके अनुकूलित कर सकते हैं।

@ianlancetaylor

क्षमा करें, मैंने अभी इसके बारे में याद किया, :-) जानकर अच्छा लगा, बहुत से लोग सोचते हैं!

24124 निम्नलिखित लिंकर विकल्प की रिपोर्ट करता है:

-Wl,-z,relro

लिंकर विकल्प -Wl,--subsystem,windows और कंपाइलर विकल्प -mwindows दोनों गायब हैं।

मैं गोमोबाइल/गोबिंद को स्टैंडअलोन बाइंडिंग बनाने की कोशिश कर रहा हूं। उस काम में से कुछ में CGO_*FLAGS पर्यावरण चर को #cgo निर्देशों में परिवर्तित करना शामिल है, जिसने कुछ और झंडों को उजागर किया:

````
-इसिसरूट(आईओएस)
-मियोस-सिम्युलेटर-संस्करण-मिनट =(आईओएस)
-miphoneos-संस्करण-मिनट=(आईओएस)

-लक्ष्य(एंड्रॉयड के लिए)
--सिसरूट(एंड्रॉयड के लिए)
-जीसीसी-टूलचेन(एंड्रॉयड के लिए)
````

मेरा मानना ​​है कि अंतिम, -gcc-toolchain को छोड़कर सभी श्वेतसूची में जोड़ने के लिए सुरक्षित हैं।

मैकोज़ पर CGO_LDFLAGS_ALLOW बिना गोडोट गेम इंजन के लिए गो बाइंडिंग बनाने के लिए निम्नलिखित झंडे की आवश्यकता है:

-Wl,-undefined,dynamic_lookup

अधिक CFLAGS zchee/libhyperkit से :

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

v8worker को Mac OS X पर -stdlib=libstdc++ आवश्यकता है।

सीएल 103156 गो के लिए ठीक 1.9.5

बदलें 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 नहीं है, आप इसे ldflags में क्यों डाल रहे हैं?

अधिक श्वेतसूची अनुरोध एकत्र करने के लिए फिर से खोलना।

#24703 . से

CFLAGS: -fno-plt

इस बिंदु पर मुझे लगता है कि यह तय करना ठीक है कि हम केवल 1.9 और 1.10 रिलीज शाखाओं को अपडेट करेंगे यदि कुछ लोकप्रिय पैकेज बनाने में विफल रहता है और किसी भी तरह से अभी तक इसकी सूचना नहीं दी गई है। मुझे नहीं लगता कि हमें हर रैंडम विकल्प को बैकपोर्ट करते रहने की जरूरत है। हम उन्हें केवल 1.11 के लिए टिप में जोड़ सकते हैं। चाहे हम उन्हें इस मामले में ट्रैक करें या कहीं और, मुझे परवाह नहीं है।

एसजीटीएम

@AlexRouSg मेरी समस्या इस लाइब्रेरी से संबंधित थी, जिसने "-I" को एक ldflag के रूप में श्वेतसूची में डालने की अनुशंसा की, जिसे मैं वर्तमान में वर्कअराउंड के रूप में उपयोग कर रहा हूं। 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 . के विभिन्न लक्ष्यों के लिए आवश्यक हैं
यदि आप उन सभी को एक साथ श्वेतसूची में नहीं डालेंगे तो कोई बात नहीं, लेकिन कृपया मुझे बताएं कि मुझे किसका ध्यान रखना होगा।

मुझे लगता है कि यह उनका अपना क्यूटी पैकेज है, जो मुझे पता है कि अच्छी तरह से स्थापित होने के लिए काफी पुराना है; मुझे पूरा यकीन नहीं है कि यह है (किसी और को कहने की आवश्यकता होगी)।

कहा जा रहा है:

• क्या LDFLAGS से कुछ -Wl, उपसर्ग के बिना पहले से ही श्वेतसूची में नहीं हैं?
• क्या गो में -e का प्रभाव पड़ता है?
• क्या -F पहले से ही श्वेतसूची में नहीं था? यह वह विकल्प निकला जिसका मैं ऊपर उल्लेख कर रहा था।
• (@Therecipe करने के लिए) क्यों आप एक की रखवाली कर रहे हैं -D एक साथ -Wp ? क्या मैक्रो परिभाषित करने का कोई कारण है लेकिन केवल प्रीप्रोसेसर में? मुझे नहीं पता कि यहाँ किस तरह का वूडू Qt है... या यह Qt द्वारा ही उपलब्ध कराए गए विकल्पों की एक अनुशंसित सूची है?
• (@ianlancetaylor के लिए) मैं समझ सकता हूं कि नए विकल्पों को 1.9 पर बैकपोर्टिंग नहीं करना (मैं इस मुद्दे पर द्विपक्षीय हूं क्योंकि मेरे पास गो संस्करण उपयोग मेट्रिक्स नहीं है), लेकिन 1.10 से 1.12 तक क्यों नहीं जारी किया गया है?
• उपर्युक्त के उत्तर के बावजूद, मुझे आश्चर्य है कि सूचीबद्ध एआरएम एबीआई विकल्पों का बैकपोर्टिंग करने योग्य है या नहीं ...

@andlabs केवल इसलिए कि हमें कभी रुकना है, तो क्यों न अभी

@andlabs हां, वे सभी अनुशंसित झंडे हैं। मैंने स्वयं उनमें से एक को भी मैन्युअल रूप से नहीं जोड़ा।
-Wp,-D_FORTIFY_SOURCE=2 सेलफिश लक्ष्य आईआईआरसी से था, मुझे नहीं पता कि उन्होंने ऐसा क्यों किया।

@ उस मामले में, क्यूटी और सेलफिश उन सुझावों को कहां करते हैं (यानी, क्या कोई वेब पेज या सीएलआई उपकरण है जो उन्हें आपको देता है)? मैं अब उत्सुक हूँ।

इस बीच, जबकि उस सूची को गो टीम द्वारा संबोधित किया जाता है, मुझे अब भी आश्चर्य होता है कि यदि आप -Wl, उपसर्ग हटाते हैं तो आपकी कितनी LDFLAGS चेतावनियाँ समाप्त हो जाती हैं; कोशिश करो और देखो? के लिए एक ही -Wp, एक में उपसर्ग CFLAGS । मुझे नहीं पता कि इसका निर्माण पर प्रतिकूल प्रभाव पड़ेगा, लेकिन यह एक आदर्श दुनिया में नहीं होना चाहिए क्योंकि LDFLAGS के लिए यही है... (आपको अल्पविराम को रिक्त स्थान में भी बदलना होगा। ये -Wx, विकल्प मूल रूप से जीसीसी और क्लैंग को तर्कों को सीधे लिंकर (या असेंबलर या प्रीप्रोसेसर) को स्वयं को संभालने के बजाय भेजने के लिए कहते हैं; अगर मैं सही ढंग से अनुमान लगा रहा हूं तो विचार ओएस-विशिष्ट विकल्पों के लिए है जो अभी तक जीसीसी द्वारा प्रदान नहीं किए गए हैं और सीधे बजते हैं, लेकिन मैं निश्चित रूप से नहीं जानता ...)

@andlabs हाँ, क्यूटी के निर्माण उपकरण qmake से एक *.pro , *.spec (mkspec), *.conf और नियमित मेकफ़ाइल उत्पन्न करने के लिए कई अन्य प्रारूपों का उपभोग करता है। मैं इसे कुछ डमी *.pro फाइलें खिलाता हूं और मेकफाइल्स से झंडे निकालता हूं। इस तरह, मुझे वास्तव में निर्भरताओं को स्वयं हल करने की ज़रूरत नहीं है, निर्माण प्रक्रिया तृतीय-पक्ष libs के साथ आसान काम कर सकती है, मुझे मैन्युअल रूप से सी या एलडी झंडे और अवांछित लक्ष्य या क्यूटी काम के नए/पुराने संस्करणों को मैन्युअल रूप से प्रबंधित करने की आवश्यकता नहीं है ज्यादातर समय बॉक्स से बाहर। मुझे कभी-कभी कुछ झंडों को काली सूची में डालना पड़ता है जो परेशानी का कारण बनते हैं, लेकिन ऐसा बहुत कम होता है।

मैंने सेलफिश mkspec खोजने की कोशिश की जो -Wp,-D_FORTIFY_SOURCE=2 में खींचती है, लेकिन शायद इसे mersdk में कहीं दफनाया गया है। लेकिन यहां उन लक्ष्यों की आधिकारिक सूची दी गई है जिनके लिए TQtC समर्थन रखता है: https://github.com/qt/qtbase/tree/5.11/mkspecs और स्वतंत्र दलों द्वारा बनाए गए बहुत सारे अनौपचारिक हैं। इसलिए मैं वास्तव में झंडे के साथ मैन्युअल रूप से गड़बड़ नहीं करना चाहता।

मैं उन्हें इस बीच बाइंडिंग (जो go लपेटता है) द्वारा उपयोग किए जाने वाले बिल्ड टूल में श्वेतसूची में डाल सकता हूं, लेकिन नियमित गो उपयोगकर्ता जो सिर्फ go build ... का उपयोग करना चाहता है, जल्दी या बाद में एक मुद्दा उठाएगा .. (कम से कम डेस्कटॉप लक्ष्यों के लिए)

-फफास्ट-गणित

आधिकारिक एसएपी हाना क्लाइंट ड्राइवर (सीजीओ आधारित साझा पुस्तकालय) #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 पर भी देखें।

@cbgo #

कोड जो लिंकर को ध्वज और तर्क जोड़ी पास करता है, उसे अब दो के बजाय एक -Wl ध्वज का उपयोग करना चाहिए: #cgo LDFLAGS का उपयोग करें: -Wl,-rpath,$ORIGIN, #cgo LDFLAGS नहीं: -Wl,-rpath -Wl,$ मूल।

@AlexRouSg बहुत बहुत धन्यवाद। मुझे इसे और ध्यान से पढ़ना चाहिए था :-)

@PassKit क्या आपने इस समस्या का समाधान किया?

@ zcm211 यदि आप https://github.com/miekg/pkcs11 के बारे में बात कर रहे हैं तो उन्होंने फरवरी में -I... लिंकर ध्वज हटा दिया। यदि आप एक पैकेज का उपयोग कर रहे हैं जो इसका उपयोग करता है तो आपको पर्यावरण चर CGO_LDFLAGS_ALLOW="-I.*"

डार्विन 64-बिट, go1.10.2, मुझे लगा कि .o फाइलें LDFLAGs के लिए श्वेतसूची में हैं, लेकिन मुझे मिल रहा है:
~jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (मास्टर) $ मेक रनसीडी chez_scheme_9.5.1/सी;








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

~~~

@ग्लिसरीन 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 भले ही लिंक करने योग्य होने चाहिए, और यह स्पष्ट रूप से एक बग है।

यह है, आईआईआरसी को छोड़कर इस बात की कोई गारंटी नहीं है कि लिंक स्रोत निर्देशिका के सापेक्ष होगा (यह बहुत अच्छी तरह से $WORK , और फिर आपका सापेक्ष पथ फिर से टूट जाता है) ... फिर से, मैं भूल गया हूँ इतिहास; किसी और को समझाने की आवश्यकता होगी।

gtk4 -mfpmath=sse . का उपयोग करता है

@ianlancetaylor cflags और ldflags के लिए अलग-अलग श्वेतसूची रखने के बजाय, क्या केवल एक सूची होनी चाहिए? जीसीसी/एलएलवीएम को परवाह नहीं है कि आप एलडीफ्लैग को सीफ्लैग में मिलाते हैं और इसके विपरीत। और ऐसा लगता है कि कभी-कभी C देव ऐसा करते हैं जिससे #25493 या https://github.com/golang/go/issues/23749#issuecomment -379969818 जैसी समस्याएं होती हैं।

आह, मैं देख रहा हूं कि हमारे पास पहले से ही एक टिकट है, इसलिए मुझे प्रोटोबफ से "-D_THREAD_SAFE" का उल्लेख करना चाहिए जैसा कि #25493 में प्रलेखित है

बदलें 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

हे लोगों,
जब हम 9/4/2018 तक गो के नवीनतम संस्करण के साथ bimg निर्माण नहीं कर सकते हैं तो यह समस्या क्यों बंद हो गई है?
कृपया समस्या देखें: https://github.com/h2non/bimg/issues/230
हम गो 1.10 से bimg आयात करने वाली कोई भी चीज़ नहीं बना सकते हैं और समस्या अभी भी गो 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 यह मुद्दा बंद हो गया है, कृपया एक नया बनाएं