23737 signale que les indicateurs générés par pkg-config -libs sont vérifiés par rapport à la liste blanche du compilateur et CGO_CFLAGS_ALLOW , alors qu'ils devraient plutôt être vérifiés par rapport à la liste blanche de l'éditeur de liens et à CGO_LDFLAGS_ALLOW . Il existe une CL pour résoudre ce problème : https://golang.org/cl/92755.

La liste blanche de l'éditeur de liens doit accepter les fichiers .a car elle accepte déjà les fichiers .o , .so , etc. Il existe une CL pour résoudre ce problème : https://golang.org/cl/92855. C'est #23739.

Les commentaires sur #23672 répertorient ces options de compilateur :

-fno-rtti
-fpermissive

et ces options d'éditeur de liens :

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

23742 suggère d'ajouter l'option de compilation -fmodules . Le compilateur clang prend en charge un certain nombre d'options -fmodules , mais il n'est pas certain qu'elles soient toutes sûres. En particulier, -fmodules-cache-path et -fmodules-user-build-path semblent permettre de spécifier un chemin que clang utilisera pour lire les modules, ce qui pourrait peut-être changer le mode de compilation de diverses manières.

23743 suggère d'ajouter l'option d'éditeur de liens -Wl,--no-as-needed . Il existe une CL pour cela : https://golang.org/cl/92795.

23744 suggère d'ajouter ces options de compilateur :

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

Il existe de nombreuses options de compilateur et d'éditeur de liens qui peuvent être utilisées avec un tiret simple ou un tiret double. Nous devrions être tout aussi laxistes dans les listes blanches.

Pour l'orthogonalité : j'oublie si l'option d'ajouter un répertoire au chemin de recherche de -framework est déjà couverte ou non. J'oublie aussi de quelle option il s'agit. (Le cas d'utilisation typique auquel je peux penser est /Library/Frameworks , c'est là qu'Apple met des frameworks spécifiques aux applications, et n'est pas recherché par défaut.)

Est-ce que -as-needed sûr à utiliser avec cgo en premier lieu ? Ce billet de blog (qui est le premier résultat que je peux trouver pour "gcc selon les besoins") dit qu'il s'agit d'un argument de position, mais je ne sais pas si cgo garantit quoi que ce soit sur l'emplacement de vos indicateurs sur les lignes de commande résultantes.

@andlabs C'est bien d'écrire

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

Dans tous les cas, le sujet de ce problème devrait être de savoir si les options sont sûres à utiliser à partir de go get .

Lors de l'utilisation :

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

la compilation échoue avec le message suivant :

invalid pkg-config package name: --static

En parcourant le code (pour go 1.9.4), il semble qu'il n'y ait aucune variable d'environnement pouvant être utilisée pour mettre en liste blanche les arguments de pkg-config.

La sortie @rgburke pkg-config passe par les mêmes variables FLAGS_ALLOW que les autres sorties.

Cependant, il semble que pkg-config -libs vérifie CGO_CFLAGS_ALLOW alors qu'il devrait vérifier CGO_LDFLAGS_ALLOW .

Nous relions un grand nombre de bibliothèques C de manière statique dans un projet à source fermée. Jusqu'à présent, nous avons effectué les opérations suivantes :

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

Ceci est bien sûr interdit maintenant. Une solution de contournement :

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

Cependant, certains de ces répertoires contiennent également des bibliothèques dynamiques, ce qui déroute l'éditeur de liens. Une autre option consiste à ajouter « / » à la liste des « noms » autorisés dans https://go-review.googlesource.com/c/go/+/92855 En particulier, le changement à la ligne 91 est :

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)

cette dernière option résout notre problème mais je ne peux pas parler de son impact sur la sécurité.

@mirtchovski, il existe un correctif pour cela (le problème est que .a n'était pas sur liste blanche, mais d'autres formats de fichiers objets l'étaient)

.a est maintenant sur liste blanche (après ce correctif) donc 'libsomething.a' fonctionnera, mais '/path/to/libsomething.a' ne fonctionnera pas.

@ianlancetaylor @rgburke J'ai en fait rencontré le même problème avec --static qui m'a conduit au n°23737. --static est rejeté car il ne semble pas être un nom de package valide _avant_ d'essayer d'exécuter pkg-config , ici https://github.com/golang/go/blob/104445e3140f4468839db49a25cb0182f7923174/src/ cmd/go/internal/work/exec.go#L939 -L940.

Notre solution rapide en interne consistait à pointer PKG_CONFIG vers un script qui exécutait simplement pkg-config --static "$@" .

@jeddenlea - Merci beaucoup ! J'essayais de trouver une solution de contournement mais je n'y ai pas pensé.

Nous atteignons cela avec -msse et -msse4.2 .

J'ai rencontré ce problème avec "${SRCDIR}/file.o" dans cgo LDFLAGS.

Je voudrais faire valoir que nous devrions autoriser les noms de fichiers simples qui sont l'entrée de l'éditeur de liens
fichiers dans LDFLAGS
(au moins *.a, *.o et *.so).

Contrairement à .a et .so qui en théorie pourraient être traités avec "-L${SRCDIR}
-lname", ajoutant
les fichiers d'objets supplémentaires à la commande de l'éditeur de liens ne peuvent pas être corrigés de cette façon.

Une solution de contournement consiste à définir CGO_LDFLAGS_ALLOW, mais c'est très lourd.
Un autre
l'alternative est de renommer mon fichier.o en fichier.syso, cependant, pour mon
cas, je ne peux pas utiliser
cette option car je n'inclus ce fichier.o que lorsqu'une balise de construction spécifique est
inclus (le
la balise de construction s'applique au fichier qui contient le préambule #cgo LDFLAGS) et
il n'y a pas moyen
pour définir une balise de construction arbitraire dans les noms de fichiers syso.

Si nous ignorons les versions précédentes de Go déployées, nous pourrions peut-être inclure un
Nouveau
"#cgo LDLIBS" conçu spécifiquement pour ajouter plus de fichiers à l'éditeur de liens
ligne de commande.
Ensuite, nous pouvons avoir une règle plus stricte pour LDLIBS (noms de fichiers uniquement, et pas de tiret
autorisé dans le préfixe.)

Nous avons atteint cela avec --std=c99

-std=c++11

Je suppose que -std=devrait être sur la liste blanche ?

Probablement sur liste blanche : -fopenmp

Erreur lors de la création du package bimg à l'aide de 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

Je ne parviens pas à ajouter -isystem à la liste blanche car l'argument à côté (qui est un chemin) sera refusé

Nous devions également utiliser cette solution de contournement : https://github.com/golang/go/issues/23749#issuecomment -364239496

Nous avions auparavant :

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

et sont passés à :

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

Le .../path/to/thing est à l'extérieur de ${SRCDIR} .

Ajout de ce commentaire afin que ce problème inclue un exemple avec une référence libthing.a qui nécessite SRCDIR extension

sur OSX, avec le nouveau go1.9.4 avec ses restrictions d'indicateur cgo, je disais spécifiquement à l'éditeur de liens avec quoi .a archive lier: (ici 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

~~~

produit lors d'une tentative de construction :

~faire construireallez construire -ldflags "-X main.LastGitCommitHash=30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp=2018-02-09T22:49:48+0700 -X main.GitBranch=master -X main.NearestGitTag=v0.9.6 =go_version_go1.9.4_darwin/amd64" -o giallez compiler github.com/gijit/gi/vendor/github.com/glycerine/golua/lua : indicateur invalide dans #cgo LDFLAGS : /Users/jaten/go/src/github.com/gijit/gi/vendor/github. com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.amake[2]: * [build] Erreur 1make[1] : [installer] Erreur 2make : ** [installer] Erreur 2jaten@jatens-MacBook-Pro ~/go/src/github.com/gijit/gi (maître) $~
J'ai essayé la solution de contournement -L -l,
~~~

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

~~~
mais ensuite l'éditeur de liens pense qu'il peut utiliser une bibliothèque différente du même nom dans un emplacement différent, et j'obtiens une erreur d'exécution plutôt qu'une erreur de liaison.

~~~
à l'exécution...
dyld : échec de la liaison de symboles paresseux : Symbole introuvable : _luajit_ctypeid
Référencé à partir de : /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Attendu dans : /usr/local/lib/libluajit-5.1.2.dylib

dyld : Symbole introuvable : _luajit_ctypeid
Référencé à partir de : /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Attendu dans : /usr/local/lib/libluajit-5.1.2.dylib

SIGTRAP : piège à trace
PC=0x7fff66ff4075 m=0 sigcode=1
le signal est arrivé pendant l'exécution de cgo
~~~
/usr/local/lib/libluajit-5.1.2.dylib n'est pas la bibliothèque requise, bien qu'elle ait été liée dynamiquement ; il doit plutôt être celui spécifié dans ${SRCDIR}/../../../LuaJIT/LuaJIT/src/libluajit.a.

Donc toujours à la recherche d'une solution de contournement.

Mise à jour : on dirait que l'ajout de ceci à mes makefiles fait l'affaire.
~export CGO_LDFLAGS_ALLOW="${GOPATH}/src/github.com/gijit/gi/vendor/github.com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a" ;~

Mise à jour : Heureusement, Ian a souligné que la version plus courte de l'expression régulière suffira :
~export CGO_LDFLAGS_ALLOW=".*.a" ;~

A quoi sert -Wl,-framework ? Si c'est le framework Apple, il a un argument, donc vous voudriez probablement -Wl,-framework,foo. Mais s'il s'agit du framework Apple, alors -framework (pas de -Wl) fonctionne tout aussi bien.

Avec la 1.10rc2, golang.org/x/net/internal/socket ne construit plus pour 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

(Il n'y a pas de cgo ici car il s'agit d'une construction croisée, mais je suppose que cela n'a pas d'importance.)

Je ne peux pas créer de lien vers un fichier lib statique en spécifiant un chemin complet vers celui-ci :

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

Je ne vois aucune solution de contournement pour cela :(

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

@ianlancetaylor , merci !

cela fera l'affaire pour moi, mais dire à toutes les autres personnes qui utilisent mon projet de faire CGO_LDFLAGS_ALLOW='.*\.a$' pour go 1.9.4 semble un peu louche.

j'espère qu'il y aura une meilleure solution (prête à l'emploi) à l'avenir.

@piotrnar Oui, le but de ce numéro est de collecter toutes les modifications que nous devons apporter à la liste blanche. Nous allons certainement ajouter les fichiers .a à la liste blanche.

pouvez-vous s'il vous plaît ajouter aussi -fstack-protector ?

Merci :)

Liste blanche -static-libstdc++ s'il vous plaît.

Le package github.com/flynn/hid ne parvient pas à se compiler avec la 1.9.4 en raison du passage de -fconstant-cfstrings via LDFLAGS sur darwin.

Veuillez ajouter ces indicateurs de liens à la liste blanche
-Wl, -Bstatique
-Wl,-Bdynamique
-Wl,--start-group
-Wl,--fin-groupe

Honnêtement : à ce stade, une liste noire de mauvaises options me semble plus utile qu'une liste blanche aussi étendue.

À l'avenir, une liste noire signifierait que si une nouvelle option de compilateur potentiellement non sécurisée était introduite, toutes les versions de Go deviendraient vulnérables à cette option. Dans la mesure où nous pouvons nous protéger contre ce genre d'attaque, je pense que ce doit être une liste blanche.

une nouvelle option de compilateur potentiellement non sécurisée a été introduite

Je pense toujours que la liste noire est préférable. Parce que ça va dans les deux sens. Si une nouvelle option de compilateur ne peut pas être utilisée tant qu'elle n'est pas sur liste blanche, cela semblerait nécessiter une nouvelle version Go à chaque fois qu'un nouveau compilateur C ajoute un indicateur ...

@glycerine C'est pourquoi nous fournissons les variables d'environnement comme une trappe d'évacuation. Vous pouvez toujours utiliser les variables d'environnement jusqu'à ce que la liste blanche soit mise à jour.

Le problème est que les variables env ne fonctionnent pas pour les projets qui sont installés uniquement via « go get ».

Autre approche : autoriser le niveau supérieur, nommé go project, à définir des variables d'environnement.

Ensuite, le projet principal « go build » en cours d'installation peut mettre en liste blanche les indicateurs dont il a besoin, par exemple en utilisant l'expression régulière ALLOW, tout en empêchant les projets dépendants de faire des choses arbitraires.

@glycerine Je ne suis pas sûr de comprendre comment cela fonctionnerait. Mais je suggère que vous ouvriez une question distincte pour cette suggestion, plutôt que d'en discuter sur cette question, qui est destinée à collecter les options qui doivent être ajoutées à la liste blanche.

Pour l'instant, nous avons décidé de mettre en place une liste blanche. Cela peut changer à l'avenir mais cette question n'est pas le lieu d'en discuter (n'hésitez pas à en déposer une nouvelle). Nous essayons de collecter des options qui devraient être ajoutées à la liste blanche ici et rien de plus.

Merci.

indicateur invalide dans #cgo CFLAGS : -pipe

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

Bonjour, veuillez ajouter ces drapeaux à la liste blanche, -Wl,--enable-new-dtags

Impossible de construire la recette/qt

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

L'ajout de .*\.a aux drapeaux autorisés serait formidable.
Voir https://github.com/golang/go/issues/23807

--mms-bitfields semble également être requis.

N'est-il pas raisonnable de supposer que chaque option du compilateur (et de l'éditeur de liens, etc.) existe pour une raison, et que la liste blanche devrait les couvrir toutes, à l'exception de celles spécifiquement considérées comme dangereuses ? Evidemment il y en a des centaines et le maintien de la liste blanche ne va pas être amusant, mais si c'est la voie qui a été décidée...

N'est-il pas raisonnable de supposer que chaque option du compilateur (et de l'éditeur de liens, etc.) existe pour une raison, et que la liste blanche devrait les couvrir toutes, à l'exception de celles spécifiquement considérées comme dangereuses ? Evidemment il y en a des centaines et le maintien de la liste blanche ne va pas être amusant, mais si c'est la voie qui a été décidée...

Cela a probablement été discuté en interne mais j'ai trouvé la chose surprenante pour une version de correctif : je me serais attendu à ce que les drapeaux incriminés aient d'abord été mis sur liste noire pour boucher le trou du plug-in du compilateur, et un système de liste blanche activé pour la 1.10, dont la liste aurait pu être construite pendant la RC. Les variables d'environnement supplémentaires ne sont pas très pratiques à intégrer dans certains systèmes de construction, et j'ai observé que cela conduisait les gens à revenir simplement à la version 1.9.3 et à être donc complètement non protégés, ce qui, à mon avis, est entièrement contre-productif.

À quel moment une liste blanche pleine de caractères génériques et d'expressions régulières devient-elle une liste noire déguisée ?

gomobile utilise les drapeaux -fobjc-arc -fmodules -fblocks :

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

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

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

-flto

Pourriez-vous mettre une liste triée par ordre alphabétique des « approuvés » en haut de ce numéro pour un aperçu jusqu'à la sortie de la prochaine mise à jour ? Quiconque soumet la CL peut également l'apprécier.

À l'heure actuelle (d'autant plus que ce problème existe), je suis plus préoccupé par ce qui passe entre les mailles du filet : quels indicateurs de construction les gens ont supprimé de leurs projets sans nous consulter au préalable, leur donnant la croyance erronée que cgo (et par extension Go) est cassé et buggy et a des régressions et ses développeurs ne savent pas ce qu'ils font. :S (Ou pire, vous ne savez pas ce que vous faites et vous construisez manifestement mal mon package, car vous êtes la seule dépendance xyz manquante !)

Certains des liens "référencés dans ce problème" répertorient d'autres drapeaux sur liste noire qui ne figurent pas encore dans ce problème. Je me porte également garant d'avoir une liste principale en haut, en particulier pour éviter les doublons. Les gens sont toujours confrontés au problème des archives statiques...

Cela me fait me demander si gcc et clang eux-mêmes pourraient, ou même devraient , fournir une option --no-unsafe-options qui a) ferait le sale boulot pour nous b) serait résilient aux changements futurs et c) ne peut pas être désactivé par un autre option (une fois que c'est là, c'est là, point final). Ou est-ce que go get la première et unique situation où ce type de filtrage est nécessaire ?

Si nous insistons sur une liste blanche, alors je ne sais pas pourquoi il doit y avoir un délai d'attente pour l'entrée.

Les compilateurs documentent leurs drapeaux. Comme quelqu'un l'a dit ci-dessus, chaque drapeau est là pour une raison.

L'échantillonnage en attendant l'entrée de l'utilisateur sur l'utilisation sera sous-représentatif, peu fiable et produira des résultats douloureux pour tous ceux d'entre nous qui, à l'avenir, auront besoin d'un indicateur qui n'a pas été réalisé ou échantillonné maintenant.

De plus il semble simple de dériver la liste blanche par cette procédure, en pseudo code :

Répertoriez tous les compilateurs C/C++ et les versions de chaque compilateur pris en charge ;
Pour chaque version du compilateur, listez tous les indicateurs disponibles dans leur documentation ;
Pour chaque drapeau, décidez de le mettre sur la liste blanche ou la liste noire (invisible).

Ajoutez un code de liste blanche pour tous les drapeaux de la liste blanche accumulée.

Je pense toujours que c'est fou (à la limite de la réduction à l'absurde) par rapport à la mise sur liste noire d'un (ou deux) drapeaux vulnérables. Mais plus sérieusement, si nous voulons insister sur une liste blanche, l'algorithme ci-dessus est correct, élimine les conjectures et peut être exécuté sans délai. Peut-être que la seule entrée utilisateur supplémentaire requise serait d'établir la gamme de compilateurs/versions à prendre en charge.

Les seules options qui comptent ici sont celles qu'il est raisonnable de mettre sur une ligne #cgo CFLAGS ou #cgo LDFLAGS dans un fichier .go, ou qu'il est raisonnable de sortir d'un appel à pkg-config --cflags ou pkg-config --libs . C'est un petit sous-ensemble du nombre total d'options du compilateur.

Vous sous-estimez également considérablement le nombre d'options que gcc et clang ont même. Je doute qu'ils soient tous documentés, même dans le code source — je ne serais pas surpris si certains sont générés à l'exécution ! Il peut également y avoir des options qui dépendent de la triple cible... (C'est aussi pourquoi je dis qu'une liste canonique d'indicateurs sûrs devrait être maintenue par les développeurs gcc et clang.)

Cependant, je ne peux rien dire sur le retard dans la mise à jour des drapeaux individuels.

@anacrolix Au #23672, vous avez suggéré que nous devions ajouter -Wl,-framework à la liste blanche. Mais -framework prend normalement une option. Pouvez-vous montrer le cas d'utilisation exact? Merci.

Vous sous-estimez également considérablement le nombre d'options que gcc et clang ont même

@andlabs Ian est un développeur gcc. Je suis sûr qu'il est bien au courant.

Le changement https://golang.org/cl/93836 mentionne ce problème : cmd/go: add options to security whitelist

J'ai envoyé une CL qui, je pense, couvre toutes les options ci-dessus : https://golang.org/cl/93836.

S'il vous plaît laissez-moi savoir si vous voyez des problèmes avec cela ou si vous connaissez des options que les gens utilisent qu'il ne couvre pas. Merci.

Du point de vue des liaisons LLVM Go, les options d'éditeur de liens suivantes doivent figurer dans la liste blanche.

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

Les options de l'éditeur de liens sont générées par la commande llvm-config --ldflags et elles sont dans la sortie.

réf : https://reviews.llvm.org/D43070

@magical je répondais à @glycerine là =P

@ianlancetaylor s'excuse également si je vous fais vous sentir pressé avec ça

@andlabs Ah, désolé

@ianlancetaylor Avec cette CL, je ne peux toujours pas construire golang.org/x/net/internal/socket pour Solaris. Il n'est pas évident pour moi d'après l'erreur quels drapeaux je dois demander.

$ ./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 Oui. Je pense que nous allons devoir corriger ce problème en modifiant golang.org/x/net. Il s'appuie déjà sur de nombreux détails internes, et je pense que nous devons changer la façon dont il le fait.

@calmh Pourriez-vous tester https://golang.org/cl/94015 sur un système Solaris réel ?

Le changement https://golang.org/cl/94015 mentionne ce problème : internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix J'ai compris d'où vient -Wl,-framework : cela vient du fichier pkg-config pour GLib, qui est une dépendance de GTK+. Plus précisément, il inclut le lien CoreFoundation à des fins d'internationalisation.

Références spécifiques : https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 où @INTLLIBS@ obtient -Wl,-framework -Wl,CoreFoundation de https://gitlab .gnome.org/GNOME/glib/blob/master/m4macros/glib-gettext.m4#L143

Il existe d'autres instances de -Wl,-framework dans divers autres fichiers pkg-config ; certains font partie des projets eux-mêmes (comme ci-dessus), et certains sont injectés par Homebrew. Sur mon système en ce moment, je vois que libcdio et SDL utilisent tous les deux -Wl,-framework,FrameworkName . (Ce qui signifie, oui, à la fois -Wl,-framework -Wl,FrameworkName et -Wl,-framework,FrameworkName se trouvent dans les fichiers pkg-config. Allez comprendre.)

Le changement https://golang.org/cl/94018 mentionne ce problème : cmd/compile: permit go:cgo_import_dynamic anywhere

@calmh Essayer une approche différente dans https://golang.org/cl/94018.

@andlabs Merci, ajouté à CL 93836.

Je lie SDL statiquement et le pgkconfig contient -Wl,--no-undefined ainsi que les définitions du préprocesseur.

J'ai besoin que vous ajoutiez les drapeaux sous la liste blanche, afin qu'ils puissent compiler des projets qui utilisent le package cgoemitter

allez construire github.com/supermock/cgoemitter-demo/x: indicateur invalide dans #cgo LDFLAGS: -Wl,-unresolved-symbols=ignore-all

Merci beaucoup d'avance

Mettez à jour CL à nouveau.

J'ai ajouté une page wiki pour décrire ce problème sur https://golang.org/wiki/InvalidFlag , et je mets à jour la CL afin que le message d'erreur pointe les gens vers le wiki.

Le changement https://golang.org/cl/94158 mentionne ce problème : doc: add note about invalid flag errors to 1.10 release notes

invalid flag in #cgo LDFLAGS: -O3

Le changement https://golang.org/cl/94655 mentionne ce problème : [release-branch.go1.10] doc: add note about invalid flag errors to 1.10 release notes

Le changement https://golang.org/cl/94675 mentionne ce problème : [release-branch.go1.10] cmd/compile: permit go:cgo_import_dynamic anywhere

Le changement https://golang.org/cl/94676 mentionne ce problème : [release-branch.go1.10] cmd/go: add options to security whitelist

Recevoir également ce numéro, si ce qui suit peut être ajouté

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

@bgk- Le correctif qui a été appliqué adresse cela. Si la mise à niveau vers la 1.10 n'est pas possible pour le moment, je devrais suggérer d'attendre de voir si une 1.9.5 se produit.

La 1.10 aurait-elle dû résoudre le problème de invalid pkg-config package name: --static ? Je viens de récupérer la dernière version d'homebrew et je la vois toujours :

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

@ptoomey3 Voir #23875

Réouverture pour le 1.9.5.

J'éviterai le problème XY et expliquerai plutôt pleinement ce que je fais. Je crée une extension postgresql avec -buildmode=c-shared .

Dans la documentation pour la création d'extensions C pour postgresql, voici comment créer l'objet partagé :

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

J'ai donc ajouté #cgo LDFLAGS: -shared à mon code source. Cela fonctionnait jusqu'à récemment (go1.10) quand il arrête de construire avec :

invalid flag in #cgo LDFLAGS: -shared

Je viens de saisir la version 1.10, je suis tombé sur ceci :

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

Il s'agit d'un indicateur de l'éditeur de liens gcc pour forcer la liaison statique pour tout ce qui se trouve après cette option sur la ligne de liaison.

@spackard Pour mémoire, ce n'est pas ce que signifie cette option. Vous pensez à -Bstatic . L'option -static indique à l'éditeur de liens de ne rechercher aucune bibliothèque partagée pour satisfaire les options -l . -static n'est pas une option positionnelle ; peu importe où il apparaît sur la ligne de commande.

@ianlancetaylor Vous avez raison sur la position. C'est ainsi que nous forçons la liaison statique, peu importe. Pour mémoire, l'ajouter à CGO_LDFLAGS_ALLOW fonctionne.

J'ai le même problème

invalid flag in #cgo CFLAGS: -m32

Nous atteignons cela avec -O3, -static-libgcc et -static-libstdc++

-O3 :

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

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

cgo CLAGS : -O3

indicateur invalide dans #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++

indicateur invalide dans #cgo LDFLAGS : -static-libgcc

-static-libstdc++ :

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

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

indicateur invalide dans #cgo LDFLAGS : -static-libstdc++

utiliser des listes blanches statiques codées en dur est une mauvaise idée, nous devrions peut-être utiliser un fichier de configuration avec des paramètres par défaut comme

$GOROOT/bin/cgo.cfg
[listes blanches]
blablabla
...

donc nous pouvons faire un peu de personnalisation

@kruglinski Vous pouvez personnaliser en utilisant la variable d'environnement CGO_CFLAGS_ALLOW et ses amis.

@ianlancetaylor

Désolé, j'ai juste raté ça, :-) Bon à savoir, beaucoup de réflexions !

24124 signale l'option d'éditeur de liens suivante :

-Wl,-z,relro

L'option de l'éditeur de liens -Wl,--subsystem,windows et l'option du compilateur -mwindows sont toutes les deux manquantes.

J'essaie de faire en sorte que gomobile/gobind génère des liaisons autonomes. Une partie de ce travail consiste à convertir les variables d'environnement CGO_*FLAGS en directives #cgo, ce qui a permis de découvrir quelques indicateurs supplémentaires :

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

-cible(Pour Android)
--sysroot(Pour Android)
-gcc-toolchain(Pour Android)
````

Je crois que tous sauf le dernier, -gcc-toolchain, peuvent être ajoutés en toute sécurité à la liste blanche.

Les indicateurs suivants sont nécessaires pour créer des liaisons Go pour le moteur de jeu Godot sans CGO_LDFLAGS_ALLOW sur macOS :

-Wl,-undefined,dynamic_lookup

Plus de CFLAGS de zchee/libhyperkit :

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

v8worker a besoin de -stdlib=libstdc++ sur Mac OS X .

CL 103156 OK pour Go 1.9.5

Le changement https://golang.org/cl/103135 mentionne ce problème : [release-branch.go1.9] cmd/go: add options to security whitelist

Je ne pouvais pas le voir sur la liste, libtool pourrait-il également être ajouté à la liste blanche

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

@PassKit -I est un cflag (qui est dans la liste) pas un ldflag, pourquoi le mettez-vous dans ldflags ?

Réouverture pour collecter plus de demandes de liste blanche.

À partir de #24703

CFLAGS: -fno-plt

À ce stade, je pense qu'il est acceptable de décider que nous ne mettrons à jour les branches de version 1.9 et 1.10 que si un package populaire échoue à construire et que cela n'a pas encore été signalé. Je ne pense pas que nous ayons besoin de continuer à rétroporter toutes les options aléatoires. Nous pouvons simplement les ajouter au pourboire pour 1.11. Que nous les suivions dans ce numéro ou ailleurs, je m'en fiche.

sgtm

@AlexRouSg mon problème était lié à cette bibliothèque, qui recommandait la liste blanche "-I" en tant que ldflag, que j'utilise actuellement comme solution de contournement. https://github.com/miekg/pkcs11/issues/63

Désolé d'être en retard, mais ce serait bien si ceux-ci étaient sur liste blanche dans 1.9.5 ou 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

et

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

Merci d'avance.

@therecipe Nous pouvons les ajouter à 1.11. Mais pour 1.9.5 ou 1.10.2 : quel(s) paquet(s) en ont besoin ?

@ianlancetaylor Ceux-ci sont tous nécessaires pour les différentes cibles de https://github.com/therecipe/qt
Ce n'est pas grave si vous ne les mettez pas tous en liste blanche en même temps, mais faites-moi savoir de laquelle je devrais m'occuper moi-même.

Je vais supposer qu'il s'agit de leur propre package Qt, dont je sais qu'il est assez ancien pour être bien établi ; Je ne suis pas tout à fait sûr que ce soit le cas (quelqu'un d'autre devra le dire).

Cela étant dit:

• Certains des LDFLAGS ne sont-ils pas déjà sur liste blanche sans le préfixe -Wl, ?
• Est-ce que -e a un effet dans Go ?
• -F n'était-il pas déjà sur liste blanche ? Cela s'avère être l'option dont je parlais ci-dessus .
• (A @therecipe) Pourquoi gardez-vous un -D avec un -Wp ? Y a-t-il une raison de définir une macro mais uniquement dans le préprocesseur ? Je ne sais pas quel genre de vaudou Qt fait ici... Ou s'agit-il d'une liste recommandée d'options fournies par Qt lui-même ?
• (À @ianlancetaylor) Je peux en quelque sorte comprendre qu'il ne faut pas rétroporter les nouvelles options vers la 1.9 (je suis ambivalent sur le problème car je n'ai pas de métriques d'utilisation de la version Go), mais pourquoi pas la version 1.10 jusqu'à la sortie de la 1.12 ?
• Indépendamment de la réponse à ce qui précède, je me demande si le rétroportage des options ARM ABI répertoriées ici vaut la peine...

@andlabs Seulement parce que nous devons nous arrêter un jour, alors pourquoi ne pas nous arrêter maintenant ? Mais je suis d'accord pour continuer à rétroporter les correctifs si cela semble suffisamment utile.

@andlabs Oui, ce sont tous des indicateurs recommandés. Je n'en ai pas ajouté manuellement un seul moi-même.
-Wp,-D_FORTIFY_SOURCE=2 provenait de la cible du voilier iirc, je ne sais pas pourquoi ils ont fait ça.

@therecipe dans ce cas, où Qt et Sailfish font-ils ces suggestions (c'est-à-dire, existe-t-il une page Web ou un outil CLI qui vous les donne) ? Je suis curieux maintenant.

En attendant, alors que cette liste est traitée par l'équipe Go, je me demande toujours combien de vos avertissements LDFLAGS disparaissent si vous supprimez les préfixes -Wl, ; essayez ça et voyez? Idem pour le préfixe -Wp, dans celui CFLAGS . Je ne sais pas si cela aura des effets négatifs sur la construction, mais cela ne devrait pas être le cas dans un monde idéal car c'est à cela que LDFLAGS est destiné... (Vous devrez également changer les virgules en espaces. Ces -Wx, options

@andlabs Oui, l'un des outils de construction de Qt qmake consomme *.pro , *.spec (mkspec), *.conf et beaucoup d'autres formats pour générer des Makefiles réguliers. Je viens de lui donner quelques fichiers factices *.pro et d'extraire les drapeaux des Makefiles. De cette façon, je n'ai pas vraiment à résoudre les dépendances moi-même, le processus de construction peut fonctionner plus facilement avec des bibliothèques tierces, je n'ai pas à gérer manuellement les indicateurs c ou ld et les cibles non testées ou les versions plus récentes/anciennes de Qt hors de la boîte la plupart du temps. Je dois juste occasionnellement mettre sur liste noire certains drapeaux qui causent des problèmes, mais c'est très rare.

J'ai essayé de trouver le sailfish mkspec qui tire -Wp,-D_FORTIFY_SOURCE=2 , mais il est probablement enterré quelque part dans le mersdk ou à peu près. Mais voici la liste officielle des cibles que TQtC prend en charge : https://github.com/qt/qtbase/tree/5.11/mkspecs et il y en a beaucoup non officielles maintenues par des parties indépendantes. C'est pourquoi je ne veux vraiment pas jouer manuellement avec les drapeaux.

Je peux les ajouter à la liste blanche dans l'outil de construction utilisé par la liaison (qui enveloppe go ) entre-temps, mais l'utilisateur Go régulier qui veut juste utiliser go build ... soulèvera tôt ou tard un problème .. . (au moins pour les cibles de bureau)

-ffast-mathématiques

Le pilote client officiel SAP HANA (la bibliothèque partagée basée sur cgo) est fourni avec #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN ce qui donne go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath . Voir également la documentation SAP sur https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca5629083869069e5.html?q=golang%20driver pour plus de détails.

@cbgo voir #23672

Le code qui passe un indicateur et une paire d'arguments à l'éditeur de liens doit maintenant utiliser un indicateur -Wl au lieu de deux : utilisez #cgo LDFLAGS : -Wl,-rpath,$ORIGIN, et non #cgo LDFLAGS : -Wl,-rpath -Wl,$ ORIGINE.

@AlexRouSg merci beaucoup. J'aurais dû lire ça plus attentivement :-)

@PassKit Avez-vous résolu ce problème？

@ zcm211 Si vous parlez de https://github.com/miekg/pkcs11, ils ont supprimé le drapeau de l'éditeur -I... liens CGO_LDFLAGS_ALLOW="-I.*"

darwin 64 bits, go1.10.2, je pensais que les fichiers .o étaient sur liste blanche pour les LDFLAG, mais j'obtiens :
~jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (master) $ make runcd chez_scheme_9.5.1/c;








en raison du préambule cgo dans 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 Selon https://go-review.googlesource.com/c/go/+/94676, ils le sont. Essayez peut-être un chemin complet au lieu d'un chemin relatif ?

Bonne prise @AlexRouSg , la regex d'acceptation est boguée comme vous le soulignez;
~re( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) ), // entrées directes de l'éditeur de liens : xo ou libfoo.so (mais pas -foo.o ou @foo.o)~
src/cmd/go/internal/work/security.go#121 devrait permettre aux fichiers .o de commencer par un . pour prendre en charge les chemins relatifs.

Après tout, je ne peux pas prédire le GOPATH des utilisateurs, ni à quel point l'emplacement de ce fichier deviendra imbriqué, il n'est donc pas pratique de définir un chemin absolu.

Le fichier .o se trouve-t-il dans le répertoire source ? Si c'est le cas, se référer au répertoire source est ce ${SRCDIR} quoi

@andlabs Même s'il existe des solutions de contournement maladroites, les chemins relatifs doivent pouvoir être liés, ce qui est clairement un bogue.

C'est le cas, sauf IIRC, il n'y a aucune garantie que le lien soit relatif au répertoire source (il pourrait très bien être dans $WORK , puis votre chemin relatif se casse à nouveau)... Encore une fois, j'ai oublié l'histoire; quelqu'un d'autre devra expliquer.

gtk4 utilise -mfpmath=sse

@ianlancetaylor Au lieu d'avoir des listes blanches séparées pour cflags et ldflags, devrait-il n'y avoir qu'une seule liste ? gcc/llvm ne semble pas se soucier du fait que vous mélangez des ldflags dans des cflags et vice versa. Et il semble parfois que les développeurs C le fassent, causant des problèmes comme #25493 ou https://github.com/golang/go/issues/23749#issuecomment -379969818

Ah, je vois que nous avons déjà un ticket, alors laissez-moi mentionner "-D_THREAD_SAFE" de protobuf comme documenté dans #25493

Le changement https://golang.org/cl/115415 mentionne ce problème : cmd/go: accept more safe CFLAGS/LDFLAGS

Le changement https://golang.org/cl/115435 mentionne ce problème : [release-branch.go1.10] cmd/go: accept more safe CFLAGS/LDFLAGS

Le changement https://golang.org/cl/115436 mentionne ce problème : [release-branch.go1.9] cmd/go: accept more safe CFLAGS/LDFLAGS

Salut les gars,
Pourquoi ce problème est-il résolu alors que nous ne pouvons toujours pas compiler bimg avec la dernière version de Go en date du 04/09/2018 ?
Veuillez consulter le problème : https://github.com/h2non/bimg/issues/230
Nous ne pouvons rien construire qui importe bimg depuis Go 1.10 et le problème persiste toujours dans Go 1.11
Le message d'erreur que nous obtenons est le suivant :

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

Un conseil ?

ÉDITER:
J'ai créé un nouveau problème : https://github.com/golang/go/issues/27496

Je pense que cette liste blanche est responsable des éléments suivants : https://github.com/alexflint/gallium/issues/63

@alexflint Ce problème est fermé, veuillez en créer un nouveau