تشير 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 . يدعم برنامج التحويل البرمجي clang عددًا من خيارات -fmodules ، لكن ليس من الواضح أنها كلها آمنة. على وجه الخصوص ، يبدو أن -fmodules-cache-path و -fmodules-user-build-path يسمحان بتحديد المسار الذي ستستخدمه clang لقراءة الوحدات ، والتي ربما يمكن أن تغير وضع الترجمة بطرق مختلفة.

يقترح 23743 إضافة خيار الرابط -Wl,--no-as-needed . يوجد CL لهذا: https://golang.org/cl/92795.

يقترح 23744 إضافة خيارات المترجم هذه:

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

هناك العديد من خيارات المترجم والرابط التي يمكن استخدامها مع شرطة واحدة أو شرطة مزدوجة. يجب أن نكون متساهلين بالمثل في القوائم البيضاء.

للتعامد: نسيت ما إذا كان خيار إضافة دليل إلى مسار بحث -framework مغطى بالفعل أم لا. أنسى أيضًا ما هو الخيار. (حالة الاستخدام النموذجية التي يمكنني التفكير فيها هي /Library/Frameworks ، حيث تضع Apple أطر عمل خاصة بالتطبيق ، ولا يتم البحث عنها افتراضيًا.)

هل أيضًا -as-needed آمن للاستخدام مع cgo في المقام الأول؟ يقول منشور المدونة هذا (وهو أول نتيجة يمكنني العثور عليها لـ "gcc حسب الحاجة") أنه حجة موضعية ، لكنني لست متأكدًا مما إذا كان cgo يضمن أي شيء حول المكان الذي تنتقل إليه أعلامك في سطور الأوامر الناتجة.

andlabs من الجيد الكتابة

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

على أي حال ، يجب أن يكون موضوع هذه المشكلة هو ما إذا كانت الخيارات آمنة للاستخدام من go get .

عند استخدام:

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

فشل التجميع مع الرسالة التالية:

invalid pkg-config package name: --static

بالنظر إلى الكود (بالنسبة إلى go 1.9.4) ، يبدو أنه لا توجد أي متغيرات بيئية يمكن استخدامها لإدراج وسائط pkg-config في القائمة البيضاء.

يمر إخراج rgburke pkg-config من خلال متغيرات FLAGS_ALLOW مثل المخرجات الأخرى.

ومع ذلك ، يبدو أن pkg-config -libs يتحقق من CGO_CFLAGS_ALLOW عندما يتعين عليه التحقق من CGO_LDFLAGS_ALLOW .

نقوم بربط عدد كبير من مكتبات لغة سي بشكل ثابت في مشروع مغلق المصدر. حتى الآن كنا نقوم بما يلي:

#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 لم يكن مدرجًا في القائمة البيضاء ، ولكن تم إدراج تنسيقات ملفات الكائنات الأخرى)

تم الآن إدراج.

ianlancetaylorrgburke ركضت فعلا في ذاتها مشكلة مع --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 .

لقد واجهت هذه المشكلة مع "$ {SRCDIR} /file.o" في cgo LDFLAGS.

أود أن أزعم أننا يجب أن نسمح بأسماء ملفات عادية تكون عبارة عن إدخال رابط
الملفات في LDFLAGS
(على الأقل * .a و * .o و * .so).

على عكس .a و. لذلك يمكن من الناحية النظرية التعامل مع "-L $ {SRCDIR}
-lname "، مضيفا
لا يمكن إصلاح ملفات الكائنات الإضافية إلى الأمر linker بهذه الطريقة.

الحل هو تعيين CGO_LDFLAGS_ALLOW ، لكن هذا مرهق للغاية.
اخر
البديل هو إعادة تسمية file.o الخاص بي إلى file.syso ، مع ذلك ، من أجل ملفات
حالة ، لا يمكنني استخدامها
هذا الخيار لأنني أقوم بتضمين هذا الملف فقط عندما تكون علامة بناء معينة
بما في ذلك (
يتم تطبيق علامة build على الملف الذي يحتوي على التمهيد #cgo LDFLAGS) و
لا توجد طريقة
لتعيين علامة بناء تعسفية في أسماء ملفات syso.

إذا تجاهلنا إصدارات Go السابقة المنشورة ، فقد نتمكن من تضمين ملف
الجديد
"#cgo LDLIBS" المصمم خصيصًا لإضافة المزيد من الملفات إلى الرابط
سطر الأوامر.
ثم يمكننا الحصول على قاعدة أكثر صرامة لـ LDLIBS (أسماء الملفات فقط ، ولا توجد شرطة
مسموح به في البادئة.)

لقد ضربنا هذا بـ --std=c99

-std = c ++ 11

أعتقد -std =يجب أن تكون مدرجة في القائمة البيضاء؟

ربما في القائمة البيضاء: -fopenmp

خطأ عند إنشاء حزمة bimg باستخدام 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

أنا غير قادر على وضع -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 ، مع go1.9.4 الذي تم سكه حديثًا مع قيود علامة cgo الخاصة به ، كنت أخبر الرابط على وجه التحديد ما هو الأرشيف الذي يجب الارتباط به: (هنا 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.NearestGitTagX = v0.9GitTagX. = go_version_go1.9.4_darwin / amd64 "-o giانتقل إلى إنشاء 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.aجعل [2]: * [بناء] خطأ 1جعل [1]: [تثبيت] خطأ 2جعل: ** [تثبيت] خطأ 2jaten @ jatens-MacBook-Pro ~ / go / src / github.com / gijit / gi (master) $~
لقد جربت الحل البديل -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: تتبع فخ
الكمبيوتر الشخصي = 0x7fff66ff4075 m = 0 رمز التوقيع = 1
وصلت الإشارة أثناء تنفيذ cgo
~~~
/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/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a "؛~

تحديث: لحسن الحظ ، أشار إيان إلى أن إصدار regex الأقصر سيفعل:
~تصدير CGO_LDFLAGS_ALLOW = ". *. a" ؛~

ما هو الإطار Wl؟ إذا كان هذا هو إطار عمل Apple ، فإنه يحتوي على حجة ، لذلك ربما تريد -Wl، -framework، foo. ولكن إذا كان إطار عمل Apple ، فإن -framework (no -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 ، شكرا لك!

هذا سيفي بالغرض بالنسبة لي ، لكن إخبار جميع الأشخاص الآخرين الذين يستخدمون مشروعي بالقيام بـ CGO_LDFLAGS_ALLOW='.*\.a$' أجل go 1.9.4 يبدو أمرًا مراوغًا بعض الشيء.

نأمل أن يكون هناك حل أفضل (خارج الصندوق) في المستقبل.

piotrnar نعم ، الهدف من هذه المشكلة هو جمع كل التغييرات التي نحتاج إلى

هل يمكنك إضافة -fstack-protector فضلك؟

شكرا :)

القائمة البيضاء -static-libstdc++ فضلك.

فشل إنشاء الحزمة github.com/flynn/hid مع 1.9.4 بسبب تمرير -fconstant-cfstrings عبر LDFLAGS على darwin.

الرجاء إضافة أعلام الرابط هذه إلى القائمة البيضاء
-Wl ، -Bstatic
-Wl ، -ديناميكية
-Wl ، - مجموعة البداية
-Wl ، - المجموعة النهائية

بصراحة: في هذه المرحلة ، تبدو القائمة السوداء للخيارات السيئة أكثر فائدة من مثل هذه القائمة البيضاء الشاملة.

من الآن فصاعدًا ، قد تعني القائمة السوداء أنه إذا تم تقديم خيار مترجم جديد يحتمل أن يكون غير آمن ، فستصبح جميع إصدارات Go عرضة لهذا الخيار. إلى الحد الذي يمكننا فيه الحماية من هذا النوع من الهجوم على الإطلاق ، أعتقد أنه يجب أن يكون قائمة بيضاء.

تم تقديم بعض خيارات المترجم الجديدة التي يحتمل أن تكون غير آمنة

ما زلت أعتقد أن القائمة السوداء هي الأفضل. لأنه يقطع كلا الاتجاهين. إذا كان أي خيار مترجم جديد لا يمكن استخدامه حتى يتم إدراجه في القائمة البيضاء ، فقد يبدو أنه يتطلب إصدار Go جديدًا في كل مرة يضيف أي مترجم C جديد علامة ...

glycerine لهذا السبب نوفر متغيرات البيئة بمثابة فتحة هروب. يمكنك دائمًا استخدام متغيرات البيئة حتى يتم تحديث القائمة البيضاء.

تكمن المشكلة في أن متغيرات env لا تعمل مع المشاريع التي يتم تثبيتها فقط من خلال "go get".

نهج آخر: السماح للمستوى الأعلى ، المسمى go project ، بتعيين متغيرات البيئة.

بعد ذلك ، يمكن لمشروع "go build" الأساسي الذي يتم تثبيته أن يضع العلامات التي يحتاجها في القائمة البيضاء ، على سبيل المثال باستخدام ALLOW regex ، مع استمرار منع المشاريع التابعة من القيام بأشياء ربائية.

@ 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

لا يمكن بناء وصفة / كيو تي

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

ستكون إضافة .*\.a إلى العلامات المسموح بها أمرًا رائعًا.
راجع https://github.com/golang/go/issues/23807

يبدو أن --mms-bitfields مطلوب أيضًا.

أليس من المعقول أن نفترض أن كل خيار مترجم (ورابط ، إلخ) موجود لسبب ما ، وأن القائمة البيضاء يجب أن تغطيها جميعًا باستثناء تلك التي تعتبر خطيرة على وجه التحديد؟ من الواضح أن هناك المئات منهم ولن يكون الحفاظ على القائمة البيضاء ممتعًا ، ولكن إذا كان هذا هو المسار الذي تم تحديده ...

أليس من المعقول أن نفترض أن كل خيار مترجم (ورابط ، إلخ) موجود لسبب ما ، وأن القائمة البيضاء يجب أن تغطيها جميعًا باستثناء تلك التي تعتبر خطيرة على وجه التحديد؟ من الواضح أن هناك المئات منهم ولن يكون الحفاظ على القائمة البيضاء ممتعًا ، ولكن إذا كان هذا هو المسار الذي تم تحديده ...

ربما تمت مناقشة هذا الأمر داخليًا ، لكنني وجدت الأمر مفاجئًا بالنسبة لإصدار التصحيح: كنت أتوقع أن تكون العلامات المخالفة قد تم وضعها في القائمة السوداء أولاً لتوصيل ثقب البرنامج المساعد للمجمع ، وتم تمكين نظام القائمة البيضاء لـ 1.10 ، والذي كان من الممكن بناء قائمته حتى خلال RC. إن المتغيرات البيئية الإضافية ليست عملية تمامًا للتكامل في بعض أنظمة البناء ، وقد لاحظت أن هذا يؤدي إلى عودة الأشخاص إلى 1.9.3 وبالتالي يصبحون غير محميين تمامًا ، وهو ما أعتقد أنه يؤدي إلى نتائج عكسية تمامًا.

عند أي نقطة تصبح القائمة البيضاء المليئة بأحرف البدل والتعبيرات الرسمية قائمة سوداء مقنعة؟

يستخدم gomobile الأعلام -fobjc-arc -fmodules -fblocks:

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

https://github.com/augustoroman/v8 يستخدم -pthread:

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

-فلتو

هل يمكنك وضع قائمة مرتبة أبجديًا من القوائم "الموافق عليها" في الجزء العلوي من هذه المشكلة لإلقاء نظرة عامة عليها حتى انتهاء التحديث التالي؟ كل من يقدم CL قد يقدر ذلك أيضًا.

في الوقت الحالي (خاصة وأن هذه المشكلة موجودة) أشعر بقلق أكبر بشأن ما ينزلق من خلال الثغرات: ما هي أعلام البناء التي أزالها الأشخاص من مشاريعهم دون استشارتنا أولاً ، مما يمنحهم الاعتقاد الخاطئ بأن cgo (وامتداد Go) مكسور وعربات التي تجرها الدواب ولديها تراجعات ولا يعرف مطوروها ما يفعلونه. : S (أو ما هو أسوأ، كنت لا تعرف ما تقومون به، ومن الواضح أن نبني حزمة بلدي خطأ، لأنك واحد في عداد المفقودين س ع ص التبعية!)

تسرد بعض روابط "المشار إليها في هذه المشكلة" المزيد من العلامات المدرجة في القائمة السوداء والتي لم تتناول هذه المشكلة بشكل صحيح حتى الآن. أؤكد أيضًا على وجود قائمة رئيسية في الأعلى ، خاصةً لتفادي التكرارات. لا يزال الأشخاص يواجهون مشكلة الأرشيف الثابت ...

هذا يجعلني أتساءل عما إذا كان بإمكان دول مجلس التعاون الخليجي والرقع بأنفسهم ، أو حتى يجب عليهم ، توفير خيار --no-unsafe-options الذي أ) سيقوم بالعمل القذر لنا ب) أن يكون مرنًا للتغييرات المستقبلية و ج) لا يمكن إيقافه بواسطة شخص آخر الخيار (بمجرد وجوده ، هناك ، فترة). أم أن go get هو الموقف الأول والوحيد الذي يتطلب هذا النوع من التصفية؟

إذا أصررنا على القائمة البيضاء ، فأنا لا أعرف لماذا يجب أن يكون هناك أي تأخير في انتظار الإدخال.

المترجمون يوثقون أعلامهم. كما قال أحدهم أعلاه ، كل علم موجود لسبب ما.

سيكون أخذ العينات عن طريق انتظار مدخلات المستخدم حول الاستخدام أقل تمثيلاً ، وغير موثوق به ، وسيؤدي إلى نتائج مؤلمة لنا جميعًا الذين سيجدون في المستقبل الحاجة إلى علامة لم يتم إدراكها أو أخذ عينات منها الآن.

علاوة على ذلك ، يبدو من السهل اشتقاق القائمة البيضاء من خلال هذا الإجراء ، في رمز زائف:

سرد كافة برامج التحويل البرمجي لـ C / C ++ وإصدارات كل مترجم مدعوم ؛
لكل إصدار مترجم ، ضع قائمة بجميع العلامات المتاحة من مستنداتهم ؛
لكل علم ، قرر وضعه في القائمة البيضاء أو القائمة السوداء (غير المرئية).

أضف رمز القائمة البيضاء لجميع العلامات الموجودة في القائمة البيضاء المتراكمة.

ما زلت أعتقد أن هذا جنون (يقترب من اختزال الإعلان السخيف) مقارنة بإدراج علامة واحدة (أو اثنتين) في القائمة السوداء. ولكن بكل جدية ، إذا أردنا الإصرار على القائمة البيضاء ، فإن الخوارزمية أعلاه صحيحة ، وتزيل التخمين ، ويمكن تنفيذها دون تأخير. ربما يكون إدخال المستخدم الإضافي الوحيد المطلوب هو تحديد نطاق المجمعين / الإصدارات المطلوب دعمها.

الخيارات الوحيدة المهمة هنا هي الخيارات المعقولة لوضعها في سطر #cgo CFLAGS أو #cgo LDFLAGS في ملف .go ، أو التي يمكن إخراجها من استدعاء إلى pkg-config --cflags أو pkg-config --libs . هذه مجموعة فرعية صغيرة من العدد الإجمالي لخيارات المترجم.

أنت أيضًا تقلل إلى حد كبير من عدد الخيارات الموجودة في دول مجلس التعاون الخليجي و clang. أشك في أنها كلها موثقة ، حتى في الكود المصدري - لن أتفاجأ إذا تم إنشاء بعضها في وقت التشغيل! قد تكون هناك أيضًا خيارات تعتمد على الهدف الثلاثي ... (وهذا هو السبب أيضًا في أنني أقول إن القائمة الأساسية للأعلام الآمنة ستحتاج إلى الاحتفاظ بها من قبل مطوري دول مجلس التعاون الخليجي و clang.)

لا يمكنني قول أي شيء عن التأخير في تصحيح الأعلام الفردية.

anacrolix في # 23672 ، اقترحت أننا بحاجة إلى إدراج -Wl,-framework في القائمة البيضاء. لكن عادة ما يأخذ -framework خيارًا. هل يمكنك إظهار حالة الاستخدام بالضبط؟ شكرا.

أنت أيضًا تقلل إلى حد كبير من عدد الخيارات الموجودة في دول مجلس التعاون الخليجي و clang

andlabs إيان هو مطور دول مجلس التعاون الخليجي. أنا متأكد من أنه يدرك جيدًا.

تغيير https://golang.org/cl/93836 يشير إلى هذه المشكلة: cmd/go: add options to security whitelist

لقد أرسلت CL وأعتقد أنه يغطي جميع الخيارات المذكورة أعلاه: https://golang.org/cl/93836.

يرجى إعلامي إذا رأيت أي مشاكل في ذلك أو إذا كنت تعرف أي خيارات يستخدمها الأشخاص ولا يغطيها. شكرا.

من وجهة نظر روابط LLVM Go ، يجب أن تكون خيارات الرابط التالية في القائمة البيضاء.

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

يتم إنشاء خيارات الرابط بواسطة الأمر llvm-config --ldflags وهي موجودة في المخرجات.

المرجع: https://reviews.llvm.org/D43070

magical كنت glycerine هناك = P.

ianlancetaylor يعتذر أيضًا إذا كنت

andlabs آه ، آسف

ianlancetaylor مع CL ما زلت لا أستطيع إنشاء golang.org/x/net/internal/socket لـ Solaris. ليس من الواضح بالنسبة لي من الخطأ ما هي العلامات التي أحتاج إلى طلبها.

$ ./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 هل ستكون قادرًا على اختبار https://golang.org/cl/94015 على نظام سولاريس فعلي؟

تغيير https://golang.org/cl/94015 يشير إلى هذه المشكلة: internal/socket: rework Solaris reliance on syscall package

rscianlancetayloranacrolix فكنت أحسب حيث -Wl,-framework قادم من: انها قادمة من ملف PKG-التكوين لالخصلة، وهي تبعية GTK +. على وجه التحديد ، يتضمن ارتباط CoreFoundation لأغراض التدويل.

مراجع محددة: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 حيث يحصل @INTLLIBS@ على -Wl,-framework -Wl,CoreFoundation من https: // gitlab .gnome.org / جنوم / glib / blob / master / m4macros / glib-gettext.m4 # L143

هناك مثيلات أخرى -Wl,-framework في العديد من ملفات pkg-config الأخرى ؛ بعضها جزء من المشاريع نفسها (على النحو الوارد أعلاه) ، وبعضها يتم ضخه بواسطة Homebrew. على نظامي الآن ، أرى أن كلا من libcdio و SDL يستخدمان -Wl,-framework,FrameworkName . (مما يعني ، نعم ، تم العثور على كل من -Wl,-framework -Wl,FrameworkName و -Wl,-framework,FrameworkName في ملفات pkg-config. اذهب إلى الشكل.)

تغيير https://golang.org/cl/94018 يشير إلى هذه المشكلة: cmd/compile: permit go:cgo_import_dynamic anywhere

calmh جرب مقاربة مختلفة في https://golang.org/cl/94018.

andlabs شكرًا ، تمت إضافته إلى CL 93836.

أنا ربط SDL ثابت ويحتوي pgkconfig على -Wl,--no-undefined بالإضافة إلى تعريف المعالج المسبق.

أريدك أن تضيف العلامات أسفل القائمة البيضاء ، حتى يتمكنوا من تجميع المشاريع التي تستخدم حزمة cgoemitter

go build github.com/supermock/cgoemitter-demo/x: علامة غير صالحة في #cgo LDFLAGS: -Wl، -unresolved-icons = ignore-all

شكرا جزيلا لك مقدما

قم بتحديث CL مرة أخرى.

لقد أضفت صفحة wiki لوصف هذه المشكلة على 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 ؟ لقد قمت للتو بسحب أحدث إصدار من homebrew وما زلت أرى ذلك:

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

@ ptoomey3 انظر # 23875

إعادة الفتح مقابل 1.9.5.

سأتجنب مشكلة XY وأشرح ما أفعله بشكل كامل. أقوم بإنشاء امتداد postgresql مع -buildmode=c-shared .

في وثائق إنشاء امتدادات C لـ postgresql ، هذه هي الطريقة لبناء الكائن المشترك:

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 linker لفرض ارتباط ثابت لأي شيء بعد هذا الخيار على خط الارتباط.

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 ++

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: -static-libgcc

-استاتيك- 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
[قوائم بيضاء]
بلبلابلا
...

حتى نتمكن من القيام ببعض التخصيص

kruglinski يمكنك التخصيص باستخدام متغير البيئة CGO_CFLAGS_ALLOW والأصدقاء.

تضمين التغريدة

آسف ، لقد فاتني هذا للتو ، :-) من الجيد أن أعرف ، يعتقد الكثيرون!

يبلغ 24124 عن خيار الرابط التالي:

-Wl,-z,relro

خيار الرابط -Wl,--subsystem,windows وخيار المترجم -mwindows كلاهما مفقودان.

أحاول جعل gomobile / gobind يولد ارتباطات قائمة بذاتها. يتضمن بعض هذا العمل تحويل متغيرات بيئة CGO_ * FLAGS إلى توجيهات #cgo ، والتي كشفت عن بعض العلامات الأخرى:

""
-ايسروت(دائرة الرقابة الداخلية)
-mios-simulator-version-min =(دائرة الرقابة الداخلية)
-Miphoneos-version-min =(دائرة الرقابة الداخلية)

-استهداف(لأجهزة الأندرويد)
- الجذور(لأجهزة الأندرويد)
-Gcc- أدوات(لأجهزة الأندرويد)
""

أعتقد أن جميع الأدوات ما عدا الأخيرة ، -gcc-toolchain ، آمنة لإضافتها إلى القائمة البيضاء.

هناك حاجة إلى العلامات التالية لإنشاء روابط Go لمحرك لعبة Godot بدون CGO_LDFLAGS_ALLOW على macOS:

-Wl,-undefined,dynamic_lookup

المزيد CFLAGS من zchee / libhyperkit :

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

يحتاج v8worker إلى -stdlib=libstdc++ على نظام التشغيل Mac OS X.

CL 103156 OK لـ Go 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. سواء كنا نتعقبهم في هذه المشكلة أو في أي مكان آخر ، لا يهمني.

sgtm

AlexRouSg كانت 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 ؟ هل هناك سبب لتحديد ماكرو ولكن فقط في المعالج المسبق؟ لا أعرف ما هو نوع الفودو كيو تي هنا ... أم أن هذه قائمة موصى بها من الخيارات التي توفرها كيو تي نفسها؟
• (إلىianlancetaylor) يمكنني نوعًا من فهم عدم backporting للخيارات الجديدة إلى 1.9 (أنا متناقض بشأن المشكلة لأنني لا أمتلك مقاييس استخدام إصدار Go) ، ولكن لماذا لا 1.10 حتى يتم إصدار 1.12؟
• بغض النظر عن الإجابة على ما سبق ، أتساءل عما إذا كان خيار دعم خيارات ARM ABI المدرجة هناك يستحق القيام به ...

andlabs فقط لأننا يجب أن نتوقف في وقت ما ، فلماذا لا نتوقف الآن؟ لكني موافق على الاستمرار في تصحيحات backport إذا بدت مفيدة بدرجة كافية.

andlabs نعم ، هذه كلها علامات موصى بها. لم أقوم بإضافة أي واحد منهم يدويًا بنفسي.
-Wp,-D_FORTIFY_SOURCE=2 من أسماك أبو شراع المستهدفة iirc ، ولا أعرف لماذا فعلوا ذلك.

therecipe في هذه الحالة ، أين تقدم Qt و Sailfish هذه الاقتراحات (أي ، هل هناك صفحة ويب أو أداة CLI تمنحك إياها)؟ أنا فضولي الآن.

في هذه الأثناء ، بينما يتناول فريق Go هذه القائمة ، ما زلت أتساءل عن عدد تحذيرات LDFLAGS التي تختفي إذا قمت بإزالة البادئات -Wl, ؛ جرب ذلك وانظر؟ نفس البادئة -Wp, في البادئة CFLAGS . لا أعرف ما إذا كان هذا سيكون له آثار سلبية على البناء ، ولكن لا ينبغي أن يكون في عالم مثالي لأن هذا هو ما هو LDFLAGS ... (سيتعين عليك أيضًا تغيير الفواصل إلى مسافات. هذه -Wx, خيارات

andlabs نعم ، إحدى أدوات إنشاء Qt qmake تستهلك *.pro ، *.spec (mkspec) ، *.conf والكثير من التنسيقات الأخرى لإنشاء ملفات Makefiles العادية. أنا فقط أطعمه بعض الملفات الوهمية *.pro واستخرج الأعلام من Makefiles. بهذه الطريقة ، لست مضطرًا حقًا إلى حل التبعيات بنفسي ، يمكن أن تعمل عملية الإنشاء بشكل أسهل مع libs التابعة لجهات خارجية ، ولا يتعين علي إدارة العلامات c أو ld والأهداف غير المختبرة يدويًا أو الإصدارات الأحدث / الأقدم من Qt work خارج الصندوق في معظم الأوقات. يجب أن أقوم أحيانًا بوضع بعض الأعلام التي تسبب المتاعب في القائمة السوداء ، لكن هذا نادر جدًا.

حاولت العثور على سمكة ابوشراع mkspec التي تسحب -Wp,-D_FORTIFY_SOURCE=2 ، لكن من المحتمل أنها مدفونة في مكان ما في mersdk أو نحو ذلك. ولكن هنا القائمة الرسمية للأهداف التي تحتفظ TQtC بدعمها لـ: https://github.com/qt/qtbase/tree/5.11/mkspecs وهناك الكثير من الأهداف غير الرسمية التي تحتفظ بها جهات مستقلة. لهذا السبب لا أريد حقًا العبث بالأعلام يدويًا.

يمكنني إدراجها في القائمة البيضاء في أداة الإنشاء التي يستخدمها الربط (والتي تغلف go ) في غضون ذلك ، لكن مستخدم Go العادي الذي يريد فقط استخدام go build ... سيثير مشكلة عاجلاً أم آجلاً .. . (على الأقل لأهداف سطح المكتب)

-فاست-الرياضيات

يأتي برنامج تشغيل عميل SAP HANA الرسمي (المكتبة المشتركة القائمة على cgo) بـ #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN والذي ينتج عنه go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath . راجع أيضًا وثائق SAPs على https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca5629083869069e5.html؟q=golang٪20driver للحصول على التفاصيل.

cbgo انظر # 23672

يجب أن تستخدم التعليمات البرمجية التي تمرر زوج العلم والوسيطة إلى الرابط الآن علامة Wl واحدة بدلاً من اثنين: استخدم #cgo LDFLAGS: -Wl، -rpath، $ ORIGIN، not #cgo LDFLAGS: -Wl، -rpath -Wl، $ الأصل.

AlexRouSg شكرا جزيلا. كان يجب أن أقرأ ذلك بعناية أكبر :-)

PassKit هل حللت هذه المشكلة？

@ zcm211 إذا كنت تتحدث عن https://github.com/miekg/pkcs11 قاموا بإزالة علامة linker -I... في فبراير. إذا كنت تستخدم حزمة تستخدمها ، فعليك تعيين المتغير البيئي CGO_LDFLAGS_ALLOW="-I.*"

darwin 64 بت ، go1.10.2 ، اعتقدت أن ملفات .o تمت إضافتها إلى القائمة البيضاء لـ LDFLAGs ، لكنني أحصل على:
~jaten @ jatens-MacBook-Pro ~ / go / src / github.com / go-interpreter / chezgo (master) $ make runالقرص المضغوط chez_scheme_9.5.1 / ج ؛








بسبب مقدمة cgo في 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

~~~

glycerine وفقًا لـ https://go-review.googlesource.com/c/go/+/94676 فهي كذلك. ربما جرب مسارًا كاملاً بدلاً من مسار نسبي؟

التقاط جيد AlexRouSg ، قبول regex هو عربات التي تجرها الدواب كما
~re ( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) )، // مدخلات الرابط المباشر: xo أو libfoo.so (لكن ليس -foo.o أو @ foo.o)~
يجب أن يسمح src / cmd / go / internal / work / security.go # 121 لملفات .o بالبدء بـ . لدعم المسارات النسبية.

بعد كل شيء ، لا يمكنني توقع GOPATH للمستخدمين ، أو كيف سيصبح موقع هذا الملف متداخلاً ، لذا فإن تعيين مسار مطلق ليس عمليًا.

هل الملف .o موجود في الدليل المصدر؟ إذا كان الأمر كذلك ، فإن الإشارة إلى دليل المصدر هو ما تم تقديم ${SRCDIR} له. (نسيت على وجه التحديد سبب تقديم ذلك ، لكن لم يكن ذلك بسبب هذه المشكلة.)

andlabs حتى إذا كانت هناك حلول klunky ، يجب أن تكون المسارات النسبية قابلة للربط ، ومن الواضح أن هذا خطأ.

إنه ، باستثناء IIRC ، ليس هناك ما يضمن أن الرابط سيكون نسبيًا إلى الدليل المصدر (يمكن أن يكون جيدًا جدًا في $WORK ، ثم ينقطع المسار النسبي مرة أخرى) ... مرة أخرى ، لقد نسيت التاريخ؛ سيحتاج شخص آخر إلى التوضيح.

يستخدم gtk4 -mfpmath = sse

ianlancetaylor بدلاً من وجود قوائم بيضاء منفصلة لـ cflags و ldflags ، هل يجب أن تكون هناك قائمة واحدة فقط؟ يبدو أن gcc / llvm لا يهتم بخلط ldflags في cflags والعكس صحيح. ويبدو أحيانًا أن مطوري C يفعلون ذلك مما يتسبب في حدوث مشكلات مثل # 25493 أو https://github.com/golang/go/issues/23749#issuecomment -379969818

آه ، أرى أن لدينا تذكرة بالفعل ، لذا دعني أذكر "-D_THREAD_SAFE" من protobuf كما هو موثق في # 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

مرحبا شباب،
لماذا تم إغلاق هذه المشكلة بينما ما زلنا لا نستطيع إنشاء bimg بأحدث إصدار من Go اعتبارًا من 9/4/2018؟
يرجى الاطلاع على المشكلة: https://github.com/h2non/bimg/issues/230
لا يمكننا إنشاء أي شيء يستورد bimg منذ Go 1.10 وما زالت المشكلة قائمة في Go 1.11
رسالة الخطأ التي نتلقاها هي كما يلي:

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

اي نصيحة؟

تعديل:
لقد أنشأت عددًا جديدًا: https://github.com/golang/go/issues/27496

أعتقد أن هذه القائمة البيضاء مسؤولة عما يلي: https://github.com/alexflint/gallium/issues/63

alexflint تم إغلاق هذه المشكلة ، يرجى إنشاء واحدة جديدة