23737 berichtet, dass Flags, die von pkg-config -libs generiert wurden, gegen die Compiler-Whitelist und CGO_CFLAGS_ALLOW geprüft werden, obwohl sie stattdessen gegen die Linker-Whitelist und CGO_LDFLAGS_ALLOW geprüft werden sollten. Es gibt eine CL, um dies zu beheben: https://golang.org/cl/92755.

Die Linker-Whitelist sollte .a Dateien akzeptieren, da sie bereits .o , .so usw. akzeptiert. Es gibt eine CL, um dies zu beheben: https://golang.org/cl/92855. Das ist #23739.

Kommentare zu #23672 listen diese Compileroptionen auf:

-fno-rtti
-fpermissive

und diese Linker-Optionen:

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

23742 schlägt vor, die Compileroption -fmodules hinzuzufügen. Der Clang-Compiler unterstützt eine Reihe von -fmodules Optionen, aber es ist nicht klar, ob sie alle sicher sind. Insbesondere -fmodules-cache-path und -fmodules-user-build-path scheinen es zu ermöglichen, einen Pfad anzugeben, den clang zum Lesen von Modulen verwendet, was möglicherweise den Kompilierungsmodus auf verschiedene Weise ändern könnte.

23743 schlägt vor, die Linker-Option -Wl,--no-as-needed hinzuzufügen. Dafür gibt es eine CL: https://golang.org/cl/92795.

23744 schlägt vor, diese Compiler-Optionen hinzuzufügen:

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

Es gibt viele Compiler- und Linker-Optionen, die entweder mit einem einzelnen Bindestrich oder einem doppelten Bindestrich verwendet werden können. Bei den Whitelists sollten wir ähnlich locker sein.

Zur Orthogonalität: Ich vergesse, ob die Option zum Hinzufügen eines Verzeichnisses zum Suchpfad von -framework bereits abgedeckt ist oder nicht. Ich vergesse auch, welche Option das ist. (Der typische Anwendungsfall, den ich mir vorstellen kann, ist /Library/Frameworks , wo Apple App-spezifische Frameworks einsetzt und standardmäßig nicht durchsucht wird.)

Ist -as-needed sicher mit cgo zu verwenden? Dieser Blogbeitrag (der das erste Ergebnis ist, das ich für "gcc as-needed" finden kann) sagt, dass es sich um ein Positionsargument handelt, aber ich bin mir nicht sicher, ob cgo irgendetwas darüber garantiert, wohin Ihre Flags in den resultierenden Befehlszeilen gehen.

@andlabs Es ist in Ordnung zu schreiben

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

In jedem Fall sollte das Thema für dieses Problem sein, ob Optionen ab go get sicher zu verwenden sind.

Beim Benutzen:

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

Die Kompilierung schlägt mit folgender Meldung fehl:

invalid pkg-config package name: --static

Wenn man sich den Code (für go 1.9.4) ansieht, scheint es, dass es keine Umgebungsvariablen gibt, die verwendet werden können, um pkg-config-Argumente auf eine Whitelist zu setzen.

Die Ausgabe von FLAGS_ALLOW Variablen wie andere Ausgaben.

Es scheint jedoch, dass pkg-config -libs CGO_CFLAGS_ALLOW pkg-config -libs prüft, obwohl es CGO_LDFLAGS_ALLOW prüfen sollte.

Wir verknüpfen eine Vielzahl von C-Bibliotheken statisch in einem Closed-Source-Projekt. Bisher haben wir folgendes gemacht:

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

Das ist jetzt natürlich nicht erlaubt. Ein Workaround:

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

Einige dieser Verzeichnisse enthalten jedoch auch dynamische Bibliotheken, was den Linker verwirrt. Eine andere Möglichkeit besteht darin, '/' zur Liste der zulässigen "Namen" in https://go-review.googlesource.com/c/go/+/92855 hinzuzufügen. Insbesondere die Änderung in Zeile 91 ist:

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)

Die letztere Option behebt unser Problem, aber ich kann nichts über die Auswirkungen auf die Sicherheit sagen.

@mirtchovski dafür gibt es einen Patch (das Problem ist, dass .a nicht auf die Whitelist gesetzt wurde, aber andere Objektdateiformate waren)

.a steht nun auf der Whitelist (nach diesem Patch), so dass 'libsomething.a' funktioniert, aber '/path/to/libsomething.a' wird nicht funktionieren.

@ianlancetaylor @rgburke Ich bin tatsächlich auf das gleiche Problem mit --static gestoßen, das mich ins Loch zu #23737 geführt hat. --static wird abgelehnt, weil es kein gültiger Paketname zu sein scheint, _bevor_ versucht wurde, pkg-config auszuführen, hier https://github.com/golang/go/blob/104445e3140f4468839db49a25cb0182f7923174/src/ cmd/go/internal/work/exec.go#L939 -L940.

Unsere interne Schnelllösung bestand darin, PKG_CONFIG auf ein Skript zu verweisen, das einfach pkg-config --static "$@" ausführte.

@jeddenlea - Vielen Dank! Ich habe versucht, einen Workaround zu finden, habe aber nicht daran gedacht.

Wir haben das mit -msse und -msse4.2 .

Ich habe dieses Problem mit "${SRCDIR}/file.o" in cgo LDFLAGS getroffen.

Ich möchte argumentieren, dass wir einfache Dateinamen zulassen sollten, die Linker-Eingaben sind
Dateien in LDFLAGS
(mindestens *.a, *.o und *.so).

Im Gegensatz zu .a und .so, die theoretisch mit "-L${SRCDIR}
-lname", hinzufügen
Zusätzliche Objektdateien für den Linker-Befehl können auf diese Weise nicht behoben werden.

Eine Problemumgehung besteht darin, CGO_LDFLAGS_ALLOW festzulegen, aber das ist sehr umständlich.
Andere
Alternative besteht darin, meine Datei.o in Datei.syso umzubenennen, jedoch für meine spezifischen
Fall kann ich nicht verwenden
diese Option, weil ich diese Datei nur einfüge.o, wenn ein bestimmtes Build-Tag ist
enthalten (die
build-Tag gilt für Datei, die die Präambel #cgo LDFLAGS enthält) und
es gibt keine Möglichkeit
um ein beliebiges Build-Tag in Syso-Dateinamen zu setzen.

Wenn wir frühere bereitgestellte Go-Versionen ignorieren, können wir möglicherweise a
Neu
"#cgo LDLIBS", das speziell zum Hinzufügen weiterer Dateien zum Linker entwickelt wurde
Befehlszeile.
Dann können wir eine strengere Regel für LDLIBS haben (nur Dateinamen und kein Bindestrich)
im Präfix erlaubt.)

Wir haben das mit --std=c99

-std=c++11

Ich denke -std=sollte in die Whitelist aufgenommen werden?

Wahrscheinlich auf Whitelist: -fopenmp

Fehler beim Erstellen des Bimg-Pakets mit 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

Ich kann -isystem nicht auf die Whitelist setzen, da das Argument daneben (das ist ein Pfad) verweigert wird

Wir mussten auch diesen Workaround verwenden: https://github.com/golang/go/issues/23749#issuecomment -364239496

Wir hatten vorher:

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

und sind umgestiegen auf:

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

Das .../path/to/thing befindet sich außerhalb von ${SRCDIR} .

Fügen Sie diesen Kommentar hinzu, sodass dieses Problem ein Beispiel mit einer libthing.a Referenz enthält, für die eine Erweiterung von SRCDIR erforderlich ist.

auf OSX, mit dem neu geprägten go1.9.4 mit seinen cgo-Flag-Einschränkungen, habe ich dem Linker speziell gesagt, gegen welches .a-Archiv er verlinken soll: (hier https://github.com/gijit/gi/blob/master/vendor/ github.com/glycerin/golua/lua/lua.go#L10 )

~~~

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

~~~

produziert beim Versuch zu bauen:

~machen bauengo build -ldflags "-X main.LastGitCommitHash=30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp=2018-02-09T22:49:48+0700 -X main.GitBranch=master -X main.NearestGitTag main=v0.9.6 -Version =go_version_go1.9.4_darwin/amd64" -o gigo build github.com/gijit/gi/vendor/github.com/glycerin/golua/lua: ungültiges Flag in #cgo LDFLAGS: /Users/jaten/go/src/github.com/gijit/gi/vendor/github. com/glycerin/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.amake[2]: * [build] Fehler 1make[1]: [install] Fehler 2machen: ** [installieren] Fehler 2jaten@jatens-MacBook-Pro ~/go/src/github.com/gijit/gi (master) $~
Ich habe die Problemumgehung -L -l ausprobiert,
~~~

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

~~~
aber dann denkt der Linker, dass er eine andere Bibliothek mit demselben Namen an einem anderen Ort verwenden kann, und ich erhalte einen Laufzeitfehler statt einen Linkzeitfehler.

~~~
zur Laufzeit...
dyld: Lazy Symbol Binding fehlgeschlagen: Symbol nicht gefunden: _luajit_ctypeid
Referenziert von: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Erwartet in: /usr/local/lib/ligluajit-5.1.2.dylib

dyld: Symbol nicht gefunden: _luajit_ctypeid
Referenziert von: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Erwartet in: /usr/local/lib/ligluajit-5.1.2.dylib

SIGTRAP: Trace-Falle
PC=0x7fff66ff4075 m=0 Sigcode=1
Signal ist während der cgo-Ausführung angekommen
~~~
/usr/local/lib/libluajit-5.1.2.dylib ist nicht die erforderliche Bibliothek, obwohl sie dynamisch gelinkt wurde; es muss vielmehr die in ${SRCDIR}/../../../LuaJIT/LuaJIT/src/libluajit.a angegebene sein.

Also immer noch auf der Suche nach einem Workaround.

Update: Es sieht so aus, als ob das Hinzufügen zu meinen Makefiles den Trick macht.
~export CGO_LDFLAGS_ALLOW="${GOPATH}/src/github.com/gijit/gi/vendor/github.com/glycerin/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a";~

Update: Zum Glück wies Ian darauf hin, dass die kürzere Regex-Version ausreichen wird:
~export CGO_LDFLAGS_ALLOW=".*.a";~

Wozu dient -Wl,-Framework? Wenn dies das Apple-Framework ist, hat es ein Argument, also möchten Sie wahrscheinlich -Wl,-framework,foo. Aber wenn es das Apple-Framework ist, dann funktioniert -framework (kein -Wl,) genauso gut.

Mit 1.10rc2 baut golang.org/x/net/internal/socket nicht mehr für 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

(Hier findet kein cgo statt, da dies ein Cross-Build ist, aber ich denke, das spielt keine Rolle.)

Ich kann nicht auf eine statische Bibliotheksdatei verlinken, indem ich einen vollständigen Pfad dazu angebe:

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

Ich sehe keinen Workaround dafür :(

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

@ianlancetaylor , danke!

das wird für mich ausreichen, aber all den anderen Leuten, die mein Projekt verwenden, zu sagen, dass sie CGO_LDFLAGS_ALLOW='.*\.a$' für go 1.9.4 machen sollen, scheint ein bisschen zwielichtig.

Hoffentlich wird es in Zukunft eine bessere (out of the box) Lösung geben.

@piotrnar Ja, der Sinn dieses Problems besteht darin, alle Änderungen zu sammeln, die wir an der Whitelist vornehmen müssen. Natürlich werden wir .a-Dateien auf die Whitelist setzen.

kannst du bitte auch -fstack-protector hinzufügen?

Danke :)

Bitte -static-libstdc++ weiße Liste setzen.

Das Paket github.com/flynn/hid kann nicht mit 1.9.4 erstellt werden, da -fconstant-cfstrings über LDFLAGS auf Darwin übergeben wird.

Bitte fügen Sie diese Linker-Flags zur Whitelist hinzu
-Wl,-Bstatisch
-Wl,-Bdynamisch
-Wl,--startgruppe
-Wl,--Endgruppe

Ganz ehrlich: An dieser Stelle erscheint mir eine Blacklist mit schlechten Optionen sinnvoller als eine so umfangreiche Whitelist.

In Zukunft würde eine Blacklist bedeuten, dass alle Go-Releases für diese Option anfällig werden, wenn eine neue potenziell unsichere Compileroption eingeführt würde. Soweit wir uns gegen diese Art von Angriffen überhaupt schützen können, muss es meiner Meinung nach eine Whitelist sein.

einige neue potenziell unsichere Compiler-Optionen wurden eingeführt

Ich denke immer noch, dass eine schwarze Liste vorzuziehen ist. Weil es in beide Richtungen schneidet. Wenn eine neue Compileroption nicht verwendet werden kann, bis sie auf die Whitelist gesetzt wird, scheint dies jedes Mal eine neue Go-Version zu erfordern, wenn ein neuer C-Compiler ein Flag hinzufügt ...

@glycerin Deshalb stellen wir die Umgebungsvariablen als

Das Problem ist, dass env-Variablen nicht für Projekte funktionieren, die rein über 'go get' installiert werden.

Ein anderer Ansatz: Erlauben Sie der obersten Ebene mit dem Namen go project, Umgebungsvariablen zu setzen.

Dann kann das primäre 'go build'-Projekt, das installiert wird, die benötigten Flags auf die Whitelist setzen, z.

@Glycerin Ich bin mir nicht sicher, ob ich verstehe, wie das funktionieren würde. Ich schlage jedoch vor, dass Sie für diesen Vorschlag ein separates Thema eröffnen, anstatt es zu diesem Thema zu diskutieren, das Optionen sammeln soll, die auf die weiße Liste gesetzt werden müssen.

Vorerst haben wir uns für die Implementierung einer Whitelist entschieden. Das kann sich in Zukunft ändern, aber dieses Thema ist nicht der Ort, um es zu diskutieren (Sie können gerne ein neues einreichen). Wir versuchen, Optionen zu sammeln, die hier auf die Whitelist gesetzt werden sollten und nicht mehr.

Dankeschön.

Ungültiges Flag in #cgo CFLAGS: -pipe

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

Hallo, bitte fügen Sie diese Flags zur Whitelist hinzu, -Wl,--enable-new-dtags

Rezept/qt kann nicht erstellt werden

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

Das Hinzufügen von .*\.a zu den zulässigen Flags wäre großartig.
Siehe https://github.com/golang/go/issues/23807

--mms-bitfields scheint ebenfalls erforderlich zu sein.

Ist es nicht vernünftig anzunehmen, dass jede Compiler- (und Linker- usw.) Option aus einem bestimmten Grund existiert und die Whitelist alle davon abdecken sollte, außer den speziell als gefährlich eingestuften? Offensichtlich gibt es Hunderte von ihnen und die Pflege der Whitelist wird keinen Spaß machen, aber wenn das der Weg ist, für den man sich entschieden hat...

Ist es nicht vernünftig anzunehmen, dass jede Compiler- (und Linker- usw.) Option aus einem bestimmten Grund existiert und die Whitelist alle davon abdecken sollte, außer den speziell als gefährlich eingestuften? Offensichtlich gibt es Hunderte von ihnen und die Pflege der Whitelist wird keinen Spaß machen, aber wenn das der Weg ist, für den man sich entschieden hat...

Dies wurde wahrscheinlich intern diskutiert, aber ich fand die Sache für ein Patch-Release überraschend: Ich hätte erwartet, dass die beleidigenden Flags zuerst auf die schwarze Liste gesetzt worden wären, um die Compiler-Plugin-Lücke zu schließen, und ein Whitelist-System für 1.10 aktiviert worden wäre, dessen Liste hätte erstellt werden können während RC auf. Die zusätzlichen env vars sind nicht ganz praktisch in einige Build-Systeme zu integrieren, und ich habe beobachtet, dass dies dazu führt, dass die Leute einfach zu 1.9.3 zurückkehren und somit völlig ungeschützt sind, was meiner Meinung nach völlig kontraproduktiv ist.

An welchem ​​Punkt wird eine Whitelist voller Wildcards und Regexes zu einer getarnten Blacklist?

gomobile verwendet die Flags -fobjc-arc -fmodules -fblocks:

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

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

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

-flto

Könnten Sie zur Übersicht bis zum nächsten Update eine alphabetisch sortierte Liste der "Freigegebenen" oben in dieser Ausgabe platzieren? Wer den CL einreicht, kann das auch zu schätzen wissen.

Im Moment (besonders da dieses Problem existiert) mache ich mir mehr Sorgen darüber, was durch die Ritzen rutscht: Welche Build-Flags haben die Leute aus ihren Projekten entfernt, ohne uns vorher zu konsultieren, was ihnen den irrigen Glauben gibt, dass cgo (und damit auch Go) kaputt ist? und Buggy und hat Rückschritte und seine Entwickler wissen nicht, was sie tun. :S (Oder noch schlimmer, du weißt nicht was du tust und baust mein Paket dir die Abhängigkeit xyz fehlt!)

Einige der Links "auf dieses Problem verwiesen" führen weitere Flags auf der schwarzen Liste auf, die noch nicht in diesem Problem enthalten sind. Ich bürge auch dafür, eine Masterliste ganz oben zu haben, vor allem um Dubletten abzuwehren. Die Leute stoßen immer noch auf das Problem mit dem statischen Archiv ...

Das lässt mich fragen, ob gcc und clang selbst eine Option --no-unsafe-options bieten könnten oder sogar sollten , die a) die Drecksarbeit für uns erledigen würde b) widerstandsfähig gegenüber zukünftigen Änderungen ist und c) nicht von anderen ausgeschaltet werden kann Option (sobald es da ist, ist es da, Punkt). Oder ist go get die erste und einzige Situation, in der diese Art von Filterung erforderlich ist?

Wenn wir auf einer Whitelist bestehen, dann weiß ich nicht, warum es Verzögerungen beim Warten auf Eingaben geben muss.

Die Compiler dokumentieren ihre Flags. Wie oben erwähnt, gibt es jede Flagge aus einem bestimmten Grund.

Das Sampling durch Warten auf Benutzereingaben bei der Verwendung wird unterrepräsentiert, unzuverlässig sein und schmerzhafte Ergebnisse für uns alle produzieren, die in Zukunft ein Flag benötigen, das jetzt nicht realisiert oder gesampelt wurde.

Darüber hinaus scheint es einfach, die Whitelist durch dieses Verfahren in Pseudocode abzuleiten:

Listen Sie alle C/C++-Compiler und Versionen jedes unterstützten Compilers auf;
Listen Sie für jede Compiler-Version alle Flags auf, die in ihren Dokumenten verfügbar sind;
Entscheiden Sie sich für jede Flagge, sie auf die Whitelist oder die (unsichtbare) Blacklist zu setzen.

Fügen Sie Whitelisting-Code für alle Flags auf der angesammelten Whitelist hinzu.

Ich denke immer noch, dass dies verrückt ist (an der Grenze zur reductio ad absurdum), verglichen mit der schwarzen Liste der einen (oder zwei) anfälligen Flags. Aber im Ernst, wenn wir auf einer Whitelist bestehen wollen, ist der obige Algorithmus richtig, eliminiert das Rätselraten und kann ohne Verzögerung ausgeführt werden. Möglicherweise besteht die einzige zusätzliche Benutzereingabe darin, den Bereich der zu unterstützenden Compiler/Versionen festzulegen.

Die einzigen Optionen, die hier von Bedeutung sind, sind diejenigen, die sinnvoll sind, um eine #cgo CFLAGS oder #cgo LDFLAGS Zeile in eine .go-Datei einzufügen, oder die vernünftigerweise von einem Aufruf an pkg-config --cflags ausgegeben werden kann. pkg-config --libs . Das ist eine kleine Teilmenge der Gesamtzahl der Compileroptionen.

Außerdem unterschätzen Sie bei weitem, wie viele Optionen gcc und clang überhaupt haben. Ich bezweifle, dass sie alle dokumentiert sind, selbst im Quellcode – ich würde mich nicht wundern, wenn einige zur Laufzeit generiert werden! Es könnte auch Optionen geben, die vom Target-Triple abhängig sind ... (Deshalb sage ich auch, dass eine kanonische Liste sicherer Flags von den gcc- und clang-Entwicklern gepflegt werden müsste.)

Über die Verzögerung beim Patchen einzelner Flags kann ich jedoch nichts sagen.

@anacrolix Drüben in #23672 hast du vorgeschlagen, dass wir -Wl,-framework auf die Whitelist setzen müssen. Aber -framework nimmt normalerweise eine Option. Können Sie den genauen Anwendungsfall zeigen? Vielen Dank.

Sie unterschätzen auch gewaltig, wie viele Optionen gcc und clang überhaupt haben

@andlabs Ian ist gcc-Entwickler. Ich bin sicher, er ist sich dessen bewusst.

Änderung https://golang.org/cl/93836 erwähnt dieses Problem: cmd/go: add options to security whitelist

Ich habe eine CL gesendet, die meiner Meinung nach alle oben genannten Optionen abdeckt: https://golang.org/cl/93836.

Bitte lassen Sie es mich wissen, wenn Sie Probleme damit sehen oder wenn Sie von Optionen wissen, die Leute verwenden, die es nicht abdeckt. Vielen Dank.

Aus Sicht der LLVM Go-Bindungen sollten sich die folgenden Linker-Optionen in der Whitelist befinden.

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

Linker-Optionen werden durch den Befehl llvm-config --ldflags generiert und sind in der Ausgabe enthalten.

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

@magical Ich habe dort auf @glycerin geantwortet =P

@ianlancetaylor entschuldigt sich auch, wenn ich dich damit gehetzt fühle

@andlabs Ah, tut mir leid

@ianlancetaylor Mit dieser CL kann ich golang.org/x/net/internal/socket für Solaris immer noch nicht bauen. Aus dem Fehler ist für mich nicht ersichtlich, nach welchen Flags ich fragen muss.

$ ./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 Ja. Ich denke, wir müssen das mit Änderungen an golang.org/x/net beheben. Es stützt sich bereits auf viele interne Details, und ich denke, wir müssen die Art und Weise ändern, wie es funktioniert.

@calmh Könnten Sie https://golang.org/cl/94015 auf einem tatsächlichen Solaris-System testen?

Änderung https://golang.org/cl/94015 erwähnt dieses Problem: internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix Ich habe herausgefunden, woher -Wl,-framework kommt: Es kommt aus der pkg-config-Datei für GLib, die eine Abhängigkeit von GTK+ ist. Insbesondere enthält es den CoreFoundation-Link für Internationalisierungszwecke.

Spezifische Referenzen: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 wobei @INTLLIBS@ -Wl,-framework -Wl,CoreFoundation von https://gitlab erhält .gnome.org/GNOME/glib/blob/master/m4macros/glib-gettext.m4#L143

Es gibt andere -Wl,-framework Instanzen in verschiedenen anderen pkg-config-Dateien; einige sind Teil der Projekte selbst (wie oben), und einige werden von Homebrew injiziert. Auf meinem System sehe ich gerade, dass libcdio und SDL beide -Wl,-framework,FrameworkName . (Das heißt, ja, sowohl -Wl,-framework -Wl,FrameworkName als auch -Wl,-framework,FrameworkName befinden sich in pkg-config-Dateien. Gehen Sie zur Abbildung.)

Änderung https://golang.org/cl/94018 erwähnt dieses Problem: cmd/compile: permit go:cgo_import_dynamic anywhere

@calmh Versuch einen anderen Ansatz in https://golang.org/cl/94018.

@andlabs Danke, zu CL 93836 hinzugefügt.

Ich verlinke statisch SDL und die pgkconfig enthält -Wl,--no-undefined sowie Präprozessordefinitionen.

Sie müssen die Flags unter der Whitelist hinzufügen, damit sie Projekte kompilieren können, die das cgoemitter-Paket verwenden

go build github.com/supermock/cgoemitter-demo/x: ungültiges Flag in #cgo LDFLAGS: -Wl,-unresolved-symbols=ignore-all

Vielen Dank im Voraus

CL erneut aktualisieren.

Ich habe eine Wiki-Seite hinzugefügt, um dieses Problem unter https://golang.org/wiki/InvalidFlag zu beschreiben, und ich aktualisiere die CL, damit die Fehlermeldung Leute auf das Wiki verweist.

Änderung https://golang.org/cl/94158 erwähnt dieses Problem: doc: add note about invalid flag errors to 1.10 release notes

invalid flag in #cgo LDFLAGS: -O3

Änderung https://golang.org/cl/94655 erwähnt dieses Problem: [release-branch.go1.10] doc: add note about invalid flag errors to 1.10 release notes

Änderung https://golang.org/cl/94675 erwähnt dieses Problem: [release-branch.go1.10] cmd/compile: permit go:cgo_import_dynamic anywhere

Änderung https://golang.org/cl/94676 erwähnt dieses Problem: [release-branch.go1.10] cmd/go: add options to security whitelist

Erhalten Sie auch diese Ausgabe, wenn Folgendes hinzugefügt werden kann

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

@bgk- Der angewendete Patch behebt dies. Wenn ein Upgrade auf 1.10 derzeit nicht möglich ist, würde ich vorschlagen, abzuwarten, ob eine 1.9.5 auftritt.

Hätte 1.10 das Problem mit invalid pkg-config package name: --static beheben sollen? Ich habe gerade die neueste Version von Homebrew heruntergezogen und sehe sie immer noch:

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

@ptoomey3 Siehe #23875

Wiedereröffnung zum 1.9.5.

Ich werde das XY-Problem vermeiden und lieber ausführlich erklären, was ich tue. Ich erstelle eine postgresql-Erweiterung in go mit -buildmode=c-shared .

In der Dokumentation zum Erstellen von C-Erweiterungen für postgresql ist dies der Weg, um das Shared Object zu erstellen:

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

Also habe ich meinem Quellcode #cgo LDFLAGS: -shared hinzugefügt. Es funktionierte bis vor kurzem (go1.10), als es aufhörte zu bauen mit:

invalid flag in #cgo LDFLAGS: -shared

Habe mir gerade go 1.10 geschnappt und bin darauf gestoßen:

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

Dies ist ein gcc-Linker-Flag, um statisches Verknüpfen für alles nach dieser Option in der Link-Zeile zu erzwingen.

@spackard Um es -Bstatic . Die Option -static weist den Linker an, nicht nach freigegebenen Bibliotheken zu suchen, um alle -l Optionen zu erfüllen. -static ist keine Positionsoption; Es spielt keine Rolle, wo es in der Befehlszeile angezeigt wird.

@ianlancetaylor Sie haben CGO_LDFLAGS_ALLOW .

Ich habe das gleiche Problem

invalid flag in #cgo CFLAGS: -m32

Wir haben dies mit -O3, -static-libgcc und -static-libstdc++ erreicht

-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

Ungültiges Flag in #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++

Ungültiges Flag in #cgo LDFLAGS: -static-libgcc

-static-libstdc++:

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

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

Ungültiges Flag in #cgo LDFLAGS: -static-libstdc++

Die Verwendung von fest codierten statischen Whitelists ist eine schlechte Idee, vielleicht sollten wir eine Konfigurationsdatei mit einigen Standardeinstellungen verwenden wie

$GOROOT/bin/cgo.cfg
[weiße Listen]
bla bla bla
...

damit wir etwas anpassen können

@kruglinski Sie können anpassen, indem Sie die Umgebungsvariable CGO_CFLAGS_ALLOW und Freunde verwenden.

@ianlancetaylor

Sorry, das habe ich nur übersehen, :-) Gut zu wissen, denken viele!

24124 meldet die folgende Linker-Option:

-Wl,-z,relro

Die Linker-Option -Wl,--subsystem,windows und die Compiler-Option -mwindows fehlen beide.

Ich versuche, gomobile/gobind dazu zu bringen, eigenständige Bindungen zu generieren. Ein Teil dieser Arbeit beinhaltet die Konvertierung von CGO_*FLAGS-Umgebungsvariablen in #cgo-Direktiven, wodurch einige weitere Flags aufgedeckt wurden:

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

-Ziel(für Android)
--sysroot(für Android)
-gcc-toolchain(für Android)
````

Ich glaube, dass alle bis auf die letzte, -gcc-toolchain, sicher zur Whitelist hinzugefügt werden können.

Die folgenden Flags werden benötigt, um Go-Bindungen für die Godot-Spiele-Engine ohne CGO_LDFLAGS_ALLOW auf macOS zu erstellen:

-Wl,-undefined,dynamic_lookup

Mehr CFLAGS von zchee/libhyperkit :

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

v8worker benötigt -stdlib=libstdc++ unter Mac OS X .

CL 103156 OK für Go 1.9.5

Änderung https://golang.org/cl/103135 erwähnt dieses Problem: [release-branch.go1.9] cmd/go: add options to security whitelist

Ich konnte es nicht in der Liste sehen, könnte libtool auch auf die weiße Liste gesetzt werden?

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

@PassKit -I ist eine cflag (die in der Liste steht) kein ldflag, warum fügst du es in ldflags ein?

Wiedereröffnung, um mehr Whitelist-Anfragen zu sammeln.

Ab #24703

CFLAGS: -fno-plt

An dieser Stelle denke ich, dass es in Ordnung ist, zu entscheiden, dass wir die Release-Zweigs 1.9 und 1.10 nur aktualisieren, wenn ein beliebtes Paket nicht erstellt werden kann und das irgendwie noch nicht gemeldet wurde. Ich glaube nicht, dass wir jede zufällige Option zurückportieren müssen. Wir können sie einfach zum Trinkgeld für 1.11 hinzufügen. Ob wir sie in dieser Ausgabe oder anderswo verfolgen, ist mir egal.

sgtm

@AlexRouSg mein Problem bezog sich auf diese Bibliothek, die empfahl, "-I" als ldflag auf die Whitelist zu setzen, was ich derzeit als Problemumgehung verwende. https://github.com/miekg/pkcs11/issues/63

Entschuldigung für die Verspätung, aber es wäre toll, wenn diese in 1.9.5 oder 1.10.2 auf die Whitelist gesetzt würden

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

und

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

Danke im Voraus.

@therecipe Wir können diese zu 1.11 hinzufügen. Aber für 1.9.5 oder 1.10.2: Welche Pakete benötigen diese?

@ianlancetaylor Diese werden alle für die verschiedenen Ziele von https://github.com/therecipe/qt benötigt
Es ist in Ordnung, wenn Sie sie nicht alle gleichzeitig auf die Whitelist setzen, aber lassen Sie mich bitte wissen, um welche ich mich selbst kümmern muss.

Ich vermute, es ist ihr eigenes Qt-Paket, von dem ich weiß, dass es alt genug ist, um gut etabliert zu sein; Ich bin mir nicht ganz sicher, ob das so ist (das muss jemand anderes sagen).

Davon abgesehen:

• Sind nicht einige der LDFLAGS bereits ohne die weiße Liste gesetzt -Wl, prefix?
• Hat -e einen Effekt in Go?
• War -F bereits auf der Whitelist? Das ist die Option, die ich oben erwähnt habe .
• (Zu @therecipe) Warum bewachen Sie ein -D mit einem -Wp ? Gibt es einen Grund, ein Makro definiert zu haben, aber nur im Präprozessor? Ich weiß nicht, welche Art von Voodoo Qt hier macht ... Oder ist dies eine empfohlene Liste von Optionen, die von Qt selbst bereitgestellt werden?
• (An @ianlancetaylor) Ich kann irgendwie verstehen, dass neue Optionen nicht auf 1.9 zurückportiert werden (ich bin in Bezug auf das Problem ambivalent, weil ich keine Nutzungsmetriken für die Go-Version habe), aber warum nicht 1.10 bis 1.12 veröffentlicht wird?
• Unabhängig von der oben genannten Antwort frage ich mich, ob es sich lohnt, die dort aufgeführten ARM ABI-Optionen zurückzuportieren ...

@andlabs Nur weil wir irgendwann aufhören müssen, also warum nicht jetzt aufhören? Aber ich bin damit einverstanden, weiterhin Patches zurückzuportieren, wenn es ausreichend nützlich erscheint.

@andlabs Ja, das sind alles empfohlene Flags. Ich habe selbst keinen einzigen manuell hinzugefügt.
-Wp,-D_FORTIFY_SOURCE=2 war vom Segelfisch-Ziel iirc, ich weiß nicht, warum sie das taten.

@therecipe Wo machen Qt und Sailfish in diesem Fall diese Vorschläge (

In der Zwischenzeit, während diese Liste vom Go-Team bearbeitet wird, frage ich mich immer noch, wie viele Ihrer LDFLAGS-Warnungen verschwinden, wenn Sie -Wl, Präfixe entfernen; versuch das und siehst du? Dasselbe gilt für das Präfix -Wp, in dem Präfix CFLAGS . Ich weiß nicht, ob dies negative Auswirkungen auf den Build hat, aber in einer idealen Welt sollte es nicht so sein, denn dafür ist LDFLAGS da ... (Sie müssen auch die Kommas in Leerzeichen ändern. Diese -Wx, Optionen weisen gcc und clang grundsätzlich an, die Argumente direkt an den Linker (oder Assembler oder Präprozessor) zu senden, anstatt sie selbst zu behandeln; wenn ich richtig vermute, handelt es sich um betriebssystemspezifische Optionen, die noch nicht von gcc bereitgestellt werden und klingeln direkt, aber ich weiß es nicht genau...)

@andlabs Ja, eines der Build-Tools von Qt qmake verbraucht *.pro , *.spec (mkspec), *.conf und viele andere Formate, um reguläre Makefiles zu generieren. Ich füttere es einfach mit einigen Dummy- *.pro Dateien und extrahiere die Flags aus den Makefiles. Auf diese Weise muss ich die Abhängigkeiten nicht wirklich selbst auflösen, der Build-Prozess kann mit Bibliotheken von Drittanbietern einfacher funktionieren, ich muss die c- oder ld-Flags und ungetestete Ziele nicht manuell verwalten oder neuere/ältere Versionen von Qt funktionieren die meiste Zeit aus der Box. Ich muss nur gelegentlich einige Flags auf die schwarze Liste setzen, die Probleme verursachen, aber das ist sehr selten.

Ich habe versucht, den sailfish mkspec zu finden, der -Wp,-D_FORTIFY_SOURCE=2 einzieht, aber er ist wahrscheinlich irgendwo im Mersdk oder so vergraben. Aber hier ist die offizielle Liste der Ziele, die TQtC unterstützt: https://github.com/qt/qtbase/tree/5.11/mkspecs und es gibt viele inoffizielle Ziele, die von unabhängigen Parteien gepflegt werden. Deshalb möchte ich wirklich nicht manuell mit den Flags herumspielen.

Ich kann sie in der Zwischenzeit im Build-Tool, das von der Bindung verwendet wird (das go umschließt) auf die Whitelist setzen, aber der normale Go-Benutzer, der nur go build ... möchte, wird früher oder später ein Problem melden. . (zumindest für die Desktop-Ziele)

-ffast-mathe

Der offizielle SAP HANA-Client-Treiber (die cgo-basierte Shared Library) wird mit #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN geliefert, was zu go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath . Weitere Informationen finden Sie in der SAP-Dokumentation unter https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca5629083869069e5.html?q=golang%20driver .

@cbgo siehe #23672

Code, der ein Flag- und Argumentpaar an den Linker übergibt, muss jetzt ein Flag -Wl statt zwei verwenden: use #cgo LDFLAGS: -Wl,-rpath,$ORIGIN, nicht #cgo LDFLAGS: -Wl,-rpath -Wl,$ URSPRUNG.

@AlexRouSg vielen Dank. Das hätte ich genauer lesen sollen :-)

@PassKit Hast du dieses Problem gelöst?

@zcm211 Wenn Sie über https://github.com/miekg/pkcs11 sprechen, haben sie im Februar das -I... Linker-Flag entfernt. Wenn Sie ein Paket verwenden, das es verwendet, müssen Sie die Umgebungsvariable CGO_LDFLAGS_ALLOW="-I.*"

darwin 64-bit, go1.10.2, ich dachte, dass .o Dateien für LDFLAGs auf der Whitelist stehen, aber ich bekomme:
~jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (master) $ make runcd chez_scheme_9.5.1/c;








aufgrund der cgo-Präambel in 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

~~~

@glycerin Laut https://go-review.googlesource.com/c/go/+/94676 sind sie es. Vielleicht versuchen Sie es mit einem vollständigen Pfad anstelle eines relativen?

Guter Fang @AlexRouSg , das Akzeptieren von Regex ist
~re( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) ), // direkte Linker-Eingaben: xo oder libfoo.so (aber nicht -foo.o oder @foo.o)~
src/cmd/go/internal/work/security.go#121 sollte .o Dateien erlauben, mit einem . zu beginnen, um relative Pfade zu unterstützen.

Schließlich kann ich den GOPATH der Benutzer nicht vorhersagen oder wie verschachtelt der Speicherort dieser Datei wird, daher ist das Festlegen eines absoluten Pfads nicht praktikabel.

Befindet sich die .o-Datei im Quellverzeichnis? Wenn ja, bezieht sich ${SRCDIR} auf das Quellverzeichnis. (Ich vergesse speziell, warum dies eingeführt wurde, aber es lag nicht an diesem Problem.)

@andlabs Selbst wenn es klobige

Es ist, außer IIRC gibt es keine Garantie, dass der Link relativ zum Quellverzeichnis ist (er könnte sehr gut in $WORK , und dann bricht Ihr relativer Pfad wieder ab)... Wieder habe ich es vergessen die Geschichte; jemand anderes muss es erklären.

gtk4 verwendet -mfpmath=sse

@ianlancetaylor Anstatt separate Whitelists für cflags und ldflags zu haben, sollte es nur eine Liste geben? gcc/llvm scheint sich nicht darum zu kümmern, dass Sie ldflags in cflags mischen und umgekehrt. Und es scheint, dass C-Entwickler manchmal Probleme wie #25493 oder https://github.com/golang/go/issues/23749#issuecomment -379969818 verursachen

Ah, ich sehe, wir haben bereits ein Ticket, also lassen Sie mich "-D_THREAD_SAFE" von protobuf erwähnen, wie in #25493 dokumentiert

Änderung https://golang.org/cl/115415 erwähnt dieses Problem: cmd/go: accept more safe CFLAGS/LDFLAGS

Änderung https://golang.org/cl/115435 erwähnt dieses Problem: [release-branch.go1.10] cmd/go: accept more safe CFLAGS/LDFLAGS

Änderung https://golang.org/cl/115436 erwähnt dieses Problem: [release-branch.go1.9] cmd/go: accept more safe CFLAGS/LDFLAGS

Hallo Leute,
Warum ist dieses Problem geschlossen, wenn wir bimg mit der neuesten Version von Go am 04.09.2018 immer noch nicht erstellen können?
Siehe Problem: https://github.com/h2non/bimg/issues/230
Wir können seit Go 1.10 nichts mehr bauen, was bimg importiert, und das Problem besteht weiterhin in Go 1.11
Die Fehlermeldung, die wir erhalten, ist diese:

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

Irgendwelche Ratschläge?

BEARBEITEN:
Ich habe ein neues Problem erstellt: https://github.com/golang/go/issues/27496

Ich glaube, diese Whitelist ist für Folgendes verantwortlich: https://github.com/alexflint/gallium/issues/63

@alexflint Dieses Problem ist geschlossen, bitte erstelle ein neues