23737 relata que os sinalizadores gerados por pkg-config -libs estão sendo verificados na lista de permissões do compilador e CGO_CFLAGS_ALLOW , quando deveriam ser verificados na lista de permissões do vinculador e CGO_LDFLAGS_ALLOW . Existe um CL para corrigir isso: https://golang.org/cl/92755.

A lista de permissões do vinculador deve aceitar .a arquivos, pois já aceita .o , .so , etc., arquivos. Existe um CL para corrigir isso: https://golang.org/cl/92855. Este é o # 23739.

Os comentários em # 23672 listam estas opções do compilador:

-fno-rtti
-fpermissive

e estas opções de vinculador:

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

23742 sugere adicionar a opção do compilador -fmodules . O compilador do clang suporta várias opções -fmodules , mas não está claro se todas são seguras. Em particular -fmodules-cache-path e -fmodules-user-build-path parecem permitir a especificação de um caminho que o clang usará para ler os módulos, o que talvez possa alterar o modo de compilação de várias maneiras.

23743 sugere adicionar a opção de vinculador -Wl,--no-as-needed . Existe um CL para isso: https://golang.org/cl/92795.

23744 sugere adicionar estas opções de compilador:

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

Existem muitas opções de compilador e vinculador que podem ser usadas com um único traço ou um traço duplo. Devemos ser igualmente relaxados nas listas de permissões.

Para ortogonalidade: esqueci se a opção de adicionar um diretório ao caminho de busca de -framework já está coberta ou não. Eu também esqueço que opção é essa. (O caso de uso típico que posso imaginar é /Library/Frameworks , que é onde a Apple coloca estruturas específicas do aplicativo e não é pesquisado por padrão.)

Também é -as-needed seguro usar com cgo em primeiro lugar? Esta postagem do blog (que é o primeiro resultado que posso encontrar para "gcc conforme necessário") diz que é um argumento posicional, mas não tenho certeza se cgo garante algo sobre onde seus sinalizadores vão nas linhas de comando resultantes.

@andlabs É bom escrever

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

Em qualquer caso, o tópico para este problema deve ser se as opções são seguras para usar em go get .

Ao usar:

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

a compilação falha com a seguinte mensagem:

invalid pkg-config package name: --static

Examinando o código (para o go 1.9.4), parece que não há nenhuma variável de ambiente que possa ser usada para colocar os argumentos do pkg-config na lista branca.

A saída do pkg-config do FLAGS_ALLOW variáveis ​​de outras saídas.

No entanto, parece que pkg-config -libs verifica CGO_CFLAGS_ALLOW quando deveria verificar CGO_LDFLAGS_ALLOW .

Vinculamos um grande número de bibliotecas C estaticamente em um projeto de código-fonte fechado. Até agora, temos feito o seguinte:

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

É claro que isso não é permitido agora. Uma solução alternativa:

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

No entanto, alguns desses diretórios também contêm bibliotecas dinâmicas, o que confunde o vinculador. Outra opção é adicionar '/' à lista de "nomes" permitidos em https://go-review.googlesource.com/c/go/+/92855. Em particular, a mudança na linha 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)

a última opção corrige nosso problema, mas não posso falar sobre seu impacto na segurança.

@mirtchovski, há um patch para isso (o problema é que .a não foi incluído na lista de permissões, mas outros formatos de arquivo de objeto foram)

.a agora está na lista de permissões (após esse patch), então 'libsomething.a' funcionará, mas '/path/to/libsomething.a' não funcionará.

@ianlancetaylor @rgburke Na verdade, tive o mesmo problema com --static que me levou até o buraco # 23737. --static foi rejeitado porque não parece ser um nome de pacote válido _antes_ tentando executar pkg-config , aqui https://github.com/golang/go/blob/104445e3140f4468839db49a25cb0182f7923174/src/ cmd / go / internal / work / exec.go # L939 -L940.

Nossa solução rápida internamente foi apontar PKG_CONFIG para um script que simplesmente executou pkg-config --static "$@" .

@jeddenlea - Muito obrigado! Eu estava tentando encontrar uma solução alternativa, mas não pensei nisso.

Acertamos isso com -msse e -msse4.2 .

Eu encontrei este problema com "$ {SRCDIR} /file.o" em cgo LDFLAGS.

Eu gostaria de argumentar que devemos permitir nomes de arquivo simples que sejam entradas de link
arquivos em LDFLAGS
(pelo menos * .a, * .o e * .so).

Ao contrário de .a e .so que, em teoria, poderia ser tratado com "-L $ {SRCDIR}
-lname ", adicionando
arquivos de objeto extras para o comando do vinculador não podem ser corrigidos dessa maneira.

Uma solução alternativa é definir CGO_LDFLAGS_ALLOW, mas isso é muito complicado.
Outro
alternativa é renomear meu arquivo.o para arquivo.syso, no entanto, para meu específico
caso, eu não posso usar
esta opção porque eu só incluo esse arquivo.o quando uma tag de construção específica é
incluído (o
tag build se aplica ao arquivo que contém o preâmbulo #cgo LDFLAGS) e
não tem jeito
para definir uma tag de construção arbitrária em nomes de arquivos do sistema.

Se ignorarmos as versões Go implantadas anteriores, poderemos incluir um
novo
"#cgo LDLIBS" que é projetado especificamente para adicionar mais arquivos ao vinculador
linha de comando.
Então, podemos ter uma regra mais rígida para LDLIBS (nomes de arquivos apenas, e sem traço
permitido no prefixo.)

Conseguimos isso com --std=c99

-std = c ++ 11

Acho que -std =deve estar na lista branca?

Provavelmente na lista de permissões: -fopenmp

Erro ao compilar o pacote bimg usando 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

Não consigo colocar -isystem na lista de permissões, pois o argumento próximo a ele (que é um caminho) será negado

Também precisávamos usar esta solução alternativa: https://github.com/golang/go/issues/23749#issuecomment -364239496

Anteriormente, tínhamos:

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

e mudaram para:

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

O .../path/to/thing está fora de ${SRCDIR} .

Adicionar este comentário para que este problema inclua um exemplo com uma referência libthing.a que precisa da expansão SRCDIR para ser resolvida.

no OSX, com o go1.9.4 recém-criado com suas restrições de sinalizador cgo, eu estava dizendo ao vinculador especificamente a qual arquivo .a vincular: (aqui 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

~~~

produz na tentativa de construir:

~fazer construirgo build -ldflags "-X main.LastGitCommitHash = 30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp = 2018-02-09T22: 49: 48 + 0700 -X main.GitBranch = master -X main.NearestGitTagers = master0.6 main.NearestGitTagers = master0.9.6 = go_version_go1.9.4_darwin / amd64 "-o gigo build github.com/gijit/gi/vendor/github.com/glycerine/golua/lua: sinalizador inválido em #cgo LDFLAGS: /Users/jaten/go/src/github.com/gijit/gi/vendor/github. com / glycerine / golua / lua /../../../ LuaJIT / LuaJIT / src / libluajit.amake [2]: * [build] Erro 1make [1]: [install] Erro 2make: ** [instalar] Erro 2jaten @ jatens-MacBook-Pro ~ / go / src / github.com / gijit / gi (master) $~
Eu tentei a solução alternativa -L -l,
~~~

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

~~~
mas o vinculador pensa que pode usar uma biblioteca diferente com o mesmo nome em um local diferente e recebo um erro de tempo de execução em vez de um erro de tempo de link.

~~~
em tempo de execução...
dyld: lazy symbol binding falhou: Símbolo não encontrado: _luajit_ctypeid
Referência de: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Esperado em: /usr/local/lib/libluajit-5.1.2.dylib

dyld: Símbolo não encontrado: _luajit_ctypeid
Referência de: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Esperado em: /usr/local/lib/libluajit-5.1.2.dylib

SIGTRAP: armadilha de rastreamento
PC = 0x7fff66ff4075 m = 0 sigcode = 1
o sinal chegou durante a execução do cgo
~~~
/usr/local/lib/libluajit-5.1.2.dylib não é a biblioteca necessária, embora tenha um link dinâmico; em vez disso, deve ser o especificado em $ {SRCDIR} /../../../ LuaJIT / LuaJIT / src / libluajit.a.

Então, ainda estou procurando uma solução alternativa.

Atualizar: parece que adicionar isso aos meus makefiles resolve.
~export CGO_LDFLAGS_ALLOW = "$ {GOPATH} /src/github.com/gijit/gi/vendor/github.com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a ";~

Atualização: felizmente, Ian apontou que a versão mais curta regex fará:
~exportar CGO_LDFLAGS_ALLOW = ". *. a";~

Para que serve -Wl, -framework? Se essa for a estrutura da Apple, tem um argumento, então você provavelmente vai querer -Wl, -framework, foo. Mas se for a estrutura da Apple, então -framework (não -Wl,) funciona da mesma forma.

Com 1.10rc2, golang.org/x/net/internal/socket não compila mais para 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

(Não há cgo acontecendo aqui, pois esta é uma construção cruzada, mas acho que isso não importa.)

Não consigo vincular a um arquivo lib estático especificando um caminho completo para ele:

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

Não vejo solução para isso :(

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

@ianlancetaylor , obrigado!

isso vai servir para mim, mas dizer a todas as outras pessoas que usam meu projeto para fazer CGO_LDFLAGS_ALLOW='.*\.a$' para ir 1.9.4 parece um pouco duvidoso.

esperançosamente, haverá uma solução melhor (fora da caixa) no futuro.

@piotrnar Sim, o objetivo deste problema é coletar todas as alterações que precisamos fazer na lista de permissões. Certamente vamos colocar arquivos .a na lista de permissões.

você pode adicionar também -fstack-protector ?

obrigado :)

Whitelist -static-libstdc++ por favor.

O pacote github.com/flynn/hid falha ao construir com 1.9.4 devido à passagem de -fconstant-cfstrings via LDFLAGS em darwin.

Por favor, adicione estes sinalizadores de linker à lista branca
-Wl, -Bstatic
-Wl, -Bdynamic
-Wl, - start-group
-Wl, - grupo final

Honestamente: neste ponto, uma lista negra de opções ruins parece mais útil do que uma lista branca tão extensa para mim.

No futuro, uma lista negra significaria que, se alguma nova opção de compilador potencialmente insegura fosse introduzida, todas as versões Go se tornariam vulneráveis ​​a essa opção. Na medida em que possamos nos proteger contra esse tipo de ataque, acho que deve ser uma lista de permissões.

algumas novas opções de compilador potencialmente inseguras foram introduzidas

Ainda acho que a lista negra é preferível. Porque corta nos dois sentidos. Se qualquer nova opção de compilador não puder ser utilizada até que seja incluída na lista de permissões, isso parece exigir uma nova versão Go sempre que qualquer novo compilador C adiciona um sinalizador ...

@glycerine É por isso que fornecemos as variáveis ​​de ambiente como uma saída de emergência. Você sempre pode usar as variáveis ​​de ambiente até que a lista de desbloqueio seja atualizada.

O problema é que as variáveis ​​env não funcionam para projetos que são instalados puramente por meio de 'go get'.

Outra abordagem: permitir que o nível superior, denominado go project, defina as variáveis ​​de ambiente.

Então, o projeto principal 'go build' sendo instalado pode colocar na lista de permissões os sinalizadores de que precisa, por exemplo, usando o regex ALLOW, enquanto ainda impede que projetos dependentes façam coisas arbitrárias.

@glycerine Não tenho certeza se entendi como isso funcionaria. Mas sugiro que você abra um exemplar separado para essa sugestão, em vez de discuti-lo neste assunto, que tem como objetivo coletar opções que precisam ser colocadas na lista de permissões.

Por enquanto, decidimos implementar uma lista de permissões. Isso pode mudar no futuro, mas este assunto não é o lugar para discuti-lo (sinta-se à vontade para registrar um novo). Estamos tentando coletar opções que deveriam estar na lista de permissões aqui e nada mais.

Obrigada.

sinalizador inválido em #cgo CFLAGS: -pipe

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

Olá, adicione esses sinalizadores à lista de permissões, -Wl, - enable-new-dtags

Não é possível construir a receita / qt

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

Adicionar .*\.a aos sinalizadores permitidos seria ótimo.
Veja https://github.com/golang/go/issues/23807

--mms-bitfields também parece ser necessário.

Não é razoável supor que cada opção de compilador (e vinculador, etc.) existe por uma razão, e a lista de permissões deve abranger todas elas, exceto aquelas especificamente consideradas perigosas? Obviamente, existem centenas deles e a manutenção da lista branca não vai ser divertida, mas se esse é o caminho que está decidido ...

Não é razoável supor que cada opção de compilador (e vinculador, etc.) existe por uma razão, e a lista de permissões deve abranger todas elas, exceto aquelas especificamente consideradas perigosas? Obviamente, existem centenas deles e a manutenção da lista branca não vai ser divertida, mas se esse é o caminho que está decidido ...

Isso provavelmente foi discutido internamente, mas eu achei uma coisa surpreendente para um lançamento de patch: eu esperava que os sinalizadores ofensivos fossem colocados na lista negra primeiro para tapar o buraco do plug-in do compilador e um sistema de lista branca habilitado para 1.10, cuja lista poderia ter sido construída durante o RC. Os env vars extras não são muito práticos de integrar em alguns sistemas de compilação, e eu observei que isso leva as pessoas apenas a reverter para 1.9.3 e, portanto, ficar completamente desprotegidas, o que acredito ser totalmente contraproducente.

Em que ponto uma lista de permissões cheia de curingas e regexes se torna uma lista negra disfarçada?

gomobile usa os sinalizadores -fobjc-arc -fmodules -fblocks:

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

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

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

-flto

Você poderia colocar uma lista em ordem alfabética dos "aprovados" no início desta edição para uma visão geral até que a próxima atualização seja lançada? Quem envia o CL também pode apreciar isso.

No momento (especialmente porque esse problema existe), estou mais preocupado com o que está escapando pelas rachaduras: quais sinalizadores de construção as pessoas removeram de seus projetos sem nos consultar primeiro, dando-lhes a crença equivocada de que o cgo (e por extensão o Go) está quebrado e com erros e tem regressões e seus desenvolvedores não sabem o que estão fazendo. : S (Ou pior, você não sabe o que está fazendo e obviamente está construindo meu pacote errado, porque é você quem está faltando a dependência xyz!)

Alguns dos links de "referência a este problema" listam mais sinalizadores na lista negra que ainda não são relacionados a esse problema. Também atesto ter uma lista principal no topo, especialmente para evitar duplicatas. As pessoas ainda estão enfrentando o problema do arquivo estático ...

Isso me faz pensar se o gcc e o clang poderiam, ou mesmo deveriam , fornecer uma opção --no-unsafe-options que a) faria o trabalho sujo para nós b) ser resiliente a mudanças futuras ec) não pode ser desativado por outro opção (uma vez lá, está lá, ponto final). Ou go get a primeira e única situação em que esse tipo de filtragem é necessário?

Se insistirmos em uma lista de permissões, não sei por que deve haver algum atraso na espera de entrada.

Os compiladores documentam seus sinalizadores. Como alguém disse acima, cada sinalizador existe por um motivo.

A amostragem aguardando a entrada do usuário sobre o uso será pouco representativa, não confiável e produzirá resultados dolorosos para todos nós que, no futuro, encontraremos a necessidade de um sinalizador que não foi realizado ou amostrado agora.

Além disso, parece simples derivar a lista branca por este procedimento, em pseudocódigo:

Liste todos os compiladores C / C ++ e versões de cada compilador com suporte;
Para cada versão do compilador, liste todos os sinalizadores disponíveis em seus documentos;
Para cada sinalizador, decida colocá-lo na lista de permissões ou na lista negra (invisível).

Adicione o código da lista de permissões para todos os sinalizadores na lista de permissões acumulada.

Ainda acho que isso é loucura (beirando a reductio ad absurdum) em comparação com a lista negra de um (ou dois) sinalizadores vulneráveis. Mas, falando sério, se vamos insistir em uma lista de permissões, o algoritmo acima está correto, elimina as suposições e pode ser executado sem demora. Talvez a única entrada adicional do usuário necessária seja estabelecer a gama de compiladores / versões a serem suportados.

As únicas opções que importam aqui são aquelas que são razoáveis ​​para colocar em uma linha #cgo CFLAGS ou #cgo LDFLAGS em um arquivo .go, ou são razoáveis ​​para a saída de uma chamada para pkg-config --cflags ou pkg-config --libs . Esse é um pequeno subconjunto do número total de opções do compilador.

Você também subestima muito quantas opções gcc e clang têm. Duvido que estejam todos documentados, mesmo no código-fonte - não ficaria surpreso se alguns fossem gerados em tempo de execução! Além disso, pode haver opções que são dependentes do triplo do destino ... (É também por isso que digo que uma lista canônica de sinalizadores seguros precisaria ser mantida pelos devs gcc e clang.)

Não posso dizer nada sobre o atraso no patch de sinalizadores individuais, no entanto.

@anacrolix Em # 23672, você sugeriu que precisamos colocar -Wl,-framework na lista de permissões. Mas -framework normalmente tem uma opção. Você pode mostrar o caso de uso exato? Obrigado.

Você também subestima muito quantas opções gcc e clang ainda têm

@andlabs Ian é um desenvolvedor gcc. Tenho certeza que ele está bem ciente.

Alterar https://golang.org/cl/93836 menciona este problema: cmd/go: add options to security whitelist

Enviei um CL que acho que cobre todas as opções acima: https://golang.org/cl/93836.

Por favor, deixe-me saber se você encontrar algum problema com ele ou se você souber de alguma opção que as pessoas estejam usando e que ele não cobre. Obrigado.

Do ponto de vista das ligações do LLVM Go, as seguintes opções de vinculador devem estar na lista branca.

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

As opções do vinculador são geradas pelo comando llvm-config --ldflags e estão na saída.

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

@magical eu estava respondendo a @glycerine lá = P

@ianlancetaylor também me

@andlabs Ah, desculpe

@ianlancetaylor Com esse CL, ainda não consigo construir golang.org/x/net/internal/socket para Solaris. Não é óbvio para mim, a partir do erro, quais sinalizadores eu preciso pedir.

$ ./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 Sim. Acho que vamos ter que consertar isso com alterações em golang.org/x/net. Já depende de muitos detalhes internos e acho que precisamos mudar a forma como ele faz isso.

@calmh Você seria capaz de testar https://golang.org/cl/94015 em um sistema Solaris real?

Mudança https://golang.org/cl/94015 menciona este problema: internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix Eu descobri de onde -Wl,-framework está vindo: está vindo do arquivo pkg-config para GLib, que é uma dependência do GTK +. Especificamente, inclui o link CoreFoundation para fins de internacionalização.

Referências específicas: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 onde @INTLLIBS@ obtém -Wl,-framework -Wl,CoreFoundation de https: // gitlab .gnome.org / GNOME / glib / blob / master / m4macros / glib-gettext.m4 # L143

Existem outras instâncias de -Wl,-framework em vários outros arquivos pkg-config; alguns fazem parte dos próprios projetos (como acima) e alguns são injetados pelo Homebrew. No meu sistema agora, vejo que libcdio e SDL usam -Wl,-framework,FrameworkName . (O que significa, sim, -Wl,-framework -Wl,FrameworkName e -Wl,-framework,FrameworkName são encontrados em arquivos pkg-config. Vai entender.)

Mudança https://golang.org/cl/94018 menciona este problema: cmd/compile: permit go:cgo_import_dynamic anywhere

@calmh Tentando uma abordagem diferente em https://golang.org/cl/94018.

Obrigado @andlabs , adicionado ao CL 93836.

Estou vinculando o SDL estático e o pgkconfig contém -Wl,--no-undefined , bem como as definições do pré-processador.

Preciso que você adicione os sinalizadores abaixo da lista branca, para que eles possam compilar projetos que usam o pacote cgoemitter

go build github.com/supermock/cgoemitter-demo/x: sinalizador inválido em #cgo LDFLAGS: -Wl, -unresolved-symbols = ignore-all

Muito obrigado antecipadamente

Atualize CL novamente.

Eu adicionei uma página wiki para descrever este problema em https://golang.org/wiki/InvalidFlag , e estou atualizando o CL para que a mensagem de erro direcione as pessoas para o wiki.

Mudança https://golang.org/cl/94158 menciona este problema: doc: add note about invalid flag errors to 1.10 release notes

invalid flag in #cgo LDFLAGS: -O3

Mudança https://golang.org/cl/94655 menciona este problema: [release-branch.go1.10] doc: add note about invalid flag errors to 1.10 release notes

Mudança https://golang.org/cl/94675 menciona este problema: [release-branch.go1.10] cmd/compile: permit go:cgo_import_dynamic anywhere

Mudança https://golang.org/cl/94676 menciona este problema: [release-branch.go1.10] cmd/go: add options to security whitelist

Recebendo também este problema, se o seguinte puder ser adicionado

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

@ bgk- O patch que foi aplicado resolve isso. Se atualizar para o 1.10 não for viável agora, eu teria que sugerir esperar para ver se o 1.9.5 acontece.

1.10 deveria ter corrigido o problema invalid pkg-config package name: --static ? Acabei de retirar a versão mais recente do homebrew e ainda estou vendo:

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

@ ptoomey3 Ver # 23875

Reabertura para 1.9.5.

Vou evitar o problema XY e, antes, explicar completamente o que estou fazendo. Estou criando uma extensão postgresql em go com -buildmode=c-shared .

Na documentação para a criação de extensões C para postgresql, esta é a forma de construir o objeto compartilhado:

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

Portanto, adicionei #cgo LDFLAGS: -shared ao meu código-fonte. Funcionou até recentemente (go1.10), quando parou de construir com:

invalid flag in #cgo LDFLAGS: -shared

Apenas peguei o go 1.10 e dei de cara com isto:

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

Este é um sinalizador de vinculador gcc para forçar a vinculação estática para qualquer coisa após essa opção na linha de link.

@spackard Para que -Bstatic . A opção -static direciona o vinculador a não procurar por nenhuma biblioteca compartilhada para satisfazer quaisquer -l opções. -static não é uma opção posicional; não importa onde ele aparece na linha de comando.

@ianlancetaylor Você está correto sobre a posição. É assim que estamos forçando a vinculação estática de qualquer maneira. Para o registro, adicioná-lo a CGO_LDFLAGS_ALLOW funciona.

Estou tendo o mesmo problema

invalid flag in #cgo CFLAGS: -m32

Atingimos isso com -O3, -static-libgcc e -static-libstdc ++

-O3:

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

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

cgo CFLAGS: -O3

sinalizador inválido em #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 ++

sinalizador inválido em #cgo LDFLAGS: -static-libgcc

-static-libstdc ++:

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

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

sinalizador inválido em #cgo LDFLAGS: -static-libstdc ++

usar listas brancas estáticas codificadas é uma má ideia, talvez devêssemos usar um arquivo de configuração com algumas configurações padrão, como

$ GOROOT / bin / cgo.cfg
[listas de permissões]
blablabla
...

para que possamos personalizar

@kruglinski Você pode personalizar usando a variável de ambiente CGO_CFLAGS_ALLOW e amigos.

@ianlancetaylor

Desculpe, eu perdi isso, :-) Bom saber, muitos pensam!

24124 relata a seguinte opção de vinculador:

-Wl,-z,relro

A opção de vinculador -Wl,--subsystem,windows e a opção de compilador -mwindows estão ausentes.

Estou tentando fazer gomobile / gobind gerar ligações autônomas. Parte desse trabalho envolve a conversão de variáveis ​​de ambiente CGO_ * FLAGS em diretivas #cgo, que revelaram mais alguns sinalizadores:

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

-alvo(para Android)
--sysroot(para Android)
-gcc-toolchain(para Android)
`` ``

Acredito que todos, exceto o último, -gcc-toolchain, são seguros para adicionar à lista de permissões.

Os sinalizadores a seguir são necessários para criar ligações Go para o mecanismo de jogo Godot sem CGO_LDFLAGS_ALLOW no macOS:

-Wl,-undefined,dynamic_lookup

Mais CFLAGS de zchee / libhyperkit :

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

O v8worker precisa de -stdlib=libstdc++ no Mac OS X.

CL 103156 OK para Go 1.9.5

Mudança https://golang.org/cl/103135 menciona este problema: [release-branch.go1.9] cmd/go: add options to security whitelist

Não consegui ver na lista, a libtool também poderia estar na lista de permissões

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

@PassKit -I é um cflag (que está na lista) e não um ldflag, por que você o está colocando em ldflags?

Reabrindo para coletar mais solicitações de lista de permissões.

De # 24703

CFLAGS: -fno-plt

Neste ponto, acho que não há problema em decidir que atualizaremos apenas os branches de lançamento 1.9 e 1.10 se algum pacote popular falhar na construção e isso de alguma forma não tiver sido relatado ainda. Não acho que precisamos continuar relatando todas as opções aleatórias. Podemos apenas adicioná-los para dar gorjeta para 1.11. Se nós os rastreamos nesta edição ou em outro lugar, eu não me importo.

sgtm

@AlexRouSg meu problema estava relacionado a esta biblioteca, que recomendava whitelisting "-I" como um ldflag, que estou usando atualmente como uma solução alternativa. https://github.com/miekg/pkcs11/issues/63

Desculpe pelo atraso, mas seria ótimo se eles fossem incluídos na lista de permissões em 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

e

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

Desde já, obrigado.

@therecipe Podemos adicioná-los a 1.11. Mas para 1.9.5 ou 1.10.2: quais pacotes precisam deles?

@ianlancetaylor Esses são todos necessários para os diferentes alvos de https://github.com/therecipe/qt
Não há problema se você não colocar todos na lista de permissões de uma vez, mas diga-me qual deles eu preciso cuidar sozinho.

Eu vou adivinhar que é o seu próprio pacote Qt, que eu sei que é antigo o suficiente para estar bem estabelecido; Não tenho certeza se é (alguém precisará dizer).

Dito isto:

• Alguns dos LDFLAGS já não estão na lista de permissões sem o prefixo -Wl, ?
• -e tem algum efeito no Go?
• -F já não estava na lista de permissões? Essa é a opção a que me referi acima .
• (Para @therecipe) Por que você está protegendo -D com -Wp ? Existe uma razão para ter uma macro definida, mas apenas no pré-processador? Não sei que tipo de vodu o Qt faz aqui ... Ou esta é uma lista de opções recomendada fornecida pelo próprio Qt?
• (Para @ianlancetaylor) Eu posso meio que entender não retratar novas opções para 1.9 (sou ambivalente sobre o problema porque não tenho métricas de uso da versão Go), mas por que não 1.10 até 1.12 ser lançado?
• Independentemente da resposta acima, eu me pergunto se vale a pena fazer backporting das opções ARM ABI listadas lá ...

@andlabs Somente porque temos que parar algum dia, então por que não parar agora? Mas estou bem em continuar a fazer backport de patches, se parecer suficientemente útil.

@andlabs Sim, todos esses sinalizadores são recomendados. Eu não adicionei manualmente um único deles.
-Wp,-D_FORTIFY_SOURCE=2 era do iirc alvo do veleiro, não sei por que eles fizeram isso.

@therecipe , nesse caso, onde o Qt e o Sailfish fazem essas sugestões (ou seja, há uma página da web ou ferramenta CLI que as fornece a você)? Estou curioso agora.

Nesse ínterim, embora essa lista seja abordada pela equipe Go, ainda me pergunto quantos de seus avisos LDFLAGS desaparecem se você remover os prefixos -Wl, ; tente isso e veja? O mesmo para o prefixo -Wp, em CFLAGS . Não sei se isso terá efeitos adversos na construção, mas não deveria em um mundo ideal, porque é para isso que LDFLAGS serve ... (Você também terá que mudar as vírgulas para espaços. Estes -Wx, opções

@andlabs Sim, uma das ferramentas de compilação do Qt qmake consome *.pro , *.spec (mkspec), *.conf e muitos outros formatos para gerar Makefiles regulares. Acabei de alimentá-lo com alguns arquivos *.pro fictícios e extrair as sinalizações dos Makefiles. Dessa forma, eu realmente não tenho que resolver dependências sozinho, o processo de construção pode funcionar mais fácil com libs de terceiros, eu não tenho que gerenciar manualmente os sinalizadores c ou ld e destinos não testados ou versões mais novas / antigas do Qt funcionam fora da caixa na maioria das vezes. Ocasionalmente, tenho que colocar alguns sinalizadores na lista negra que causam problemas, mas isso é muito raro.

Eu tentei encontrar o veleiro mkspec que puxa -Wp,-D_FORTIFY_SOURCE=2 , mas provavelmente está enterrado em algum lugar no mersdk ou algo assim. Mas aqui está a lista oficial de alvos que a TQtC mantém suporte para: https://github.com/qt/qtbase/tree/5.11/mkspecs e há muitos outros não oficiais mantidos por partes independentes. É por isso que eu realmente não quero mexer nos sinalizadores manualmente.

Posso colocá-los na lista de permissões na ferramenta de compilação usada pela vinculação (que envolve go ) enquanto isso, mas o usuário Go normal que deseja apenas usar go build ... , mais cedo ou mais tarde, levantará um problema. . (pelo menos para os destinos de desktop)

-rápida matemática

O driver cliente oficial do SAP HANA (a biblioteca compartilhada baseada em cgo) vem com #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN que resulta em go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath . Consulte também a documentação SAPs em https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca5629083869069e5.html?q=golang%20driver para obter detalhes.

@cbgo veja # 23672

O código que passa um sinalizador e um par de argumento para o vinculador agora deve usar um sinalizador -Wl em vez de dois: use #cgo LDFLAGS: -Wl, -rpath, $ ORIGIN, não #cgo LDFLAGS: -Wl, -rpath -Wl, $ ORIGEM.

@AlexRouSg muito obrigado. Eu deveria ter lido isso com mais atenção :-)

@PassKit Você resolveu este problema？

@ zcm211 Se você está falando sobre https://github.com/miekg/pkcs11, eles removeram a sinalização de linker -I... em fev. Se você estiver usando um pacote que o utiliza, você deve definir a variável de ambiente CGO_LDFLAGS_ALLOW="-I.*"

darwin 64 bits, go1.10.2, pensei que .o arquivos estavam na lista de permissões para LDFLAGs, mas estou recebendo:
~jaten @ jatens-MacBook-Pro ~ / go / src / github.com / go-interpreter / chezgo (master) $ make runcd chez_scheme_9.5.1 / c;








devido ao preâmbulo cgo em 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 De acordo com https://go-review.googlesource.com/c/go/+/94676 eles são. Talvez tente um caminho completo em vez de um relativo?

Boa captura @AlexRouSg , a muitos bugs, como você
~re ( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) ), // entradas do linker direto: xo ou libfoo.so (mas não -foo.o ou @ foo.o)~
src / cmd / go / internal / work / security.go # 121 deve permitir que .o arquivos comecem com . para suportar caminhos relativos.

Afinal, não posso prever o GOPATH dos usuários ou o quão aninhado o local desse arquivo ficará, portanto, definir um caminho absoluto não é prático.

O arquivo .o está no diretório de origem? Em caso afirmativo, referindo-se ao diretório de origem é o que ${SRCDIR} foi fornecido. (Eu esqueci especificamente por que isso foi introduzido, mas não foi por causa desse problema.)

@andlabs Mesmo se houver soluções alternativas klunky, os caminhos relativos devem ser vinculáveis, e isso é claramente um bug.

É, exceto IIRC, não há garantia de que o link seria relativo AO diretório de origem (poderia muito bem estar em $WORK , e então seu caminho relativo quebra novamente) ... Mais uma vez, esqueci a história; alguém precisará explicar.

gtk4 usa -mfpmath = sse

@ianlancetaylor Em vez de listas brancas separadas para cflags e ldflags, deveria haver apenas uma lista? gcc / llvm não parece se importar se você mistura ldflags em cflags e vice-versa. E parece que às vezes C devs fazem isso causando problemas como # 25493 ou https://github.com/golang/go/issues/23749#issuecomment -379969818

Ah, vejo que já temos um tíquete, então deixe-me mencionar "-D_THREAD_SAFE" do protobuf conforme documentado em # 25493

Mudança https://golang.org/cl/115415 menciona este problema: cmd/go: accept more safe CFLAGS/LDFLAGS

Mudança https://golang.org/cl/115435 menciona este problema: [release-branch.go1.10] cmd/go: accept more safe CFLAGS/LDFLAGS

Mudança https://golang.org/cl/115436 menciona este problema: [release-branch.go1.9] cmd/go: accept more safe CFLAGS/LDFLAGS

Ei pessoal,
Por que este problema foi resolvido quando ainda não podemos construir bimg com a versão mais recente do Go em 04/09/2018?
Consulte o problema: https://github.com/h2non/bimg/issues/230
Não podemos construir nada que importe bimg uma vez que Go 1.10 e o problema ainda persiste no Go 1.11
A mensagem de erro que recebemos é esta:

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

Qualquer conselho?

EDITAR:
Eu criei um novo problema: https://github.com/golang/go/issues/27496

Acredito que esta lista de permissões seja responsável pelo seguinte: https://github.com/alexflint/gallium/issues/63

@alexflint Este problema foi