23737 informa que los indicadores generados por pkg-config -libs se están comprobando con la lista blanca del compilador, y CGO_CFLAGS_ALLOW , cuando deberían comprobarse con la lista blanca del enlazador y CGO_LDFLAGS_ALLOW . Hay una CL para solucionar esto: https://golang.org/cl/92755.

La lista blanca del vinculador debe aceptar archivos .a ya que ya acepta archivos .o , .so , etc. Hay una CL para solucionar esto: https://golang.org/cl/92855. Este es el # 23739.

Los comentarios sobre # 23672 enumeran estas opciones del compilador:

-fno-rtti
-fpermissive

y estas opciones de enlazador:

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

23742 sugiere agregar la opción del compilador -fmodules . El compilador clang admite varias opciones -fmodules , pero no está claro que todas sean seguras. En particular, -fmodules-cache-path y -fmodules-user-build-path parecen permitir especificar una ruta que clang usará para leer módulos, lo que quizás podría cambiar el modo de compilación de varias formas.

23743 sugiere agregar la opción de enlazador -Wl,--no-as-needed . Hay una CL para esto: https://golang.org/cl/92795.

23744 sugiere agregar estas opciones del compilador:

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

Hay muchas opciones de compilador y enlazador que se pueden usar con un solo guión o con dos guiones. Deberíamos ser igualmente laxos en las listas blancas.

Para ortogonalidad: Olvidé si la opción de agregar un directorio a la ruta de búsqueda de -framework ya está cubierta o no. También olvido cuál es esa opción. (El caso de uso típico en el que puedo pensar es /Library/Frameworks , que es donde Apple coloca los marcos específicos de la aplicación y no se busca de forma predeterminada).

Además, ¿es seguro usar -as-needed con cgo en primer lugar? Esta publicación de blog (que es el primer resultado que puedo encontrar para "gcc según sea necesario") dice que es un argumento posicional, pero no estoy seguro de si cgo garantiza algo sobre dónde van sus banderas en las líneas de comando resultantes.

@andlabs Está bien escribir

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

En cualquier caso, el tema de este problema debería ser si las opciones son seguras de usar desde go get .

Cuando usas:

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

La compilación falla con el siguiente mensaje:

invalid pkg-config package name: --static

Al revisar el código (para go 1.9.4), parece que no hay variables de entorno que se puedan usar para incluir en la lista blanca los argumentos de pkg-config.

La salida de @rgburke pkg-config pasa por las mismas variables FLAGS_ALLOW que otras salidas.

Sin embargo, parece que pkg-config -libs comprueba CGO_CFLAGS_ALLOW cuando debería marcar CGO_LDFLAGS_ALLOW .

Vinculamos una gran cantidad de bibliotecas C de forma estática en un proyecto de código cerrado. Hasta ahora hemos estado haciendo lo siguiente:

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

Por supuesto, esto no está permitido ahora. Una solución alternativa:

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

Sin embargo, algunos de estos directorios también contienen bibliotecas dinámicas, lo que confunde al enlazador. Otra opción es agregar '/' a la lista de "nombres" permitidos en https://go-review.googlesource.com/c/go/+/92855 En particular, el cambio en la línea 91 es:

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)

la última opción soluciona nuestro problema, pero no puedo hablar de su impacto en la seguridad.

@mirtchovski hay un parche para eso (el problema es que .a no estaba en la lista blanca, pero otros formatos de archivos de objetos sí)

.a ahora está en la lista blanca (después de ese parche), por lo que 'libsomething.a' funcionará, pero '/path/to/libsomething.a' no funcionará.

@ianlancetaylor @rgburke De hecho, me encontré con el mismo problema con --static que me llevó por el agujero al # 23737. --static se rechaza porque no parece ser un nombre de paquete válido _antes_ de intentar ejecutar pkg-config , aquí https://github.com/golang/go/blob/104445e3140f4468839db49a25cb0182f7923174/src/ cmd / go / internal / work / exec.go # L939 -L940.

Nuestra solución rápida internamente fue apuntar PKG_CONFIG a un script que simplemente ejecutaba pkg-config --static "$@" .

@jeddenlea - ¡Muchas gracias! Estaba tratando de encontrar una solución, pero no pensé en eso.

Llegamos a esto con -msse y -msse4.2 .

Encontré este problema con "$ {SRCDIR} /file.o" en cgo LDFLAGS.

Me gustaría argumentar que deberíamos permitir nombres de archivo sin formato que sean la entrada del vinculador
archivos en LDFLAGS
(al menos * .a, * .o y * .so).

A diferencia de .ay .so, que en teoría podrían manejarse con "-L $ {SRCDIR}
-lname ", agregando
Los archivos de objetos adicionales al comando del vinculador no se pueden arreglar de esa manera.

Una solución alternativa es configurar CGO_LDFLAGS_ALLOW, pero eso es muy engorroso.
Otro
La alternativa es cambiar el nombre de mi file.o a file.syso, sin embargo, para mi
caso, no puedo usar
esta opción porque solo incluyo ese archivo. o cuando una etiqueta de compilación específica es
incluido (el
La etiqueta de compilación se aplica al archivo que contiene el preámbulo #cgo LDFLAGS) y
no hay manera
para establecer etiquetas de compilación arbitrarias en nombres de archivo syso.

Si ignoramos las versiones anteriores de Go implementadas, es posible que podamos incluir una
nuevo
"#cgo LDLIBS" que está diseñado específicamente para agregar más archivos al vinculador
línea de comando.
Entonces podemos tener una regla más estricta para LDLIBS (solo nombres de archivo, y sin guiones
permitido en prefijo.)

Lo hemos conseguido con --std=c99

-std = c ++ 11

Supongo -std =¿Debería figurar en la lista blanca?

Probablemente en la lista blanca: -fopenmp

Error al construir el paquete 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

No puedo incluir en la lista blanca -isystem ya que el argumento al lado (que es una ruta) será denegado

También necesitábamos utilizar esta solución alternativa: https://github.com/golang/go/issues/23749#issuecomment -364239496

Anteriormente teníamos:

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

y ha cambiado a:

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

El .../path/to/thing está fuera de ${SRCDIR} .

Agregar este comentario para que este problema incluya un ejemplo con una referencia libthing.a que necesita una expansión SRCDIR para resolverse.

en OSX, con el nuevo go1.9.4 con sus restricciones de bandera cgo, le estaba diciendo al vinculador específicamente contra qué archivo .a vincular: (aquí 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

~~~

produce al intentar construir:

~hacer construirgo build -ldflags "-X main.LastGitCommitHash = 30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp = 2018-02-09T22: 49: 48 + 0700 -X main.GitBranch = master -X main.NearestGitVagers = v0.9 = go_version_go1.9.4_darwin / amd64 "-o give a compilar github.com/gijit/gi/vendor/github.com/glycerine/golua/lua: indicador no válido en #cgo LDFLAGS: /Users/jaten/go/src/github.com/gijit/gi/vendor/github. com / glycerine / golua / lua /../../../ LuaJIT / LuaJIT / src / libluajit.amake [2]: * [compilación] Error 1make [1]: [instalar] Error 2make: ** [instalar] Error 2jaten @ jatens-MacBook-Pro ~ / go / src / github.com / gijit / gi (maestro) $~
Probé la solución alternativa -L -l,
~~~

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

~~~
pero luego el vinculador cree que puede usar una biblioteca diferente con el mismo nombre en una ubicación diferente, y obtengo un tiempo de ejecución en lugar de un error de tiempo de enlace.

~~~
en tiempo de ejecución...
dyld: error de enlace de símbolo perezoso: símbolo no encontrado: _luajit_ctypeid
Referenciado de: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Esperado en: /usr/local/lib/libluajit-5.1.2.dylib

dyld: Símbolo no encontrado: _luajit_ctypeid
Referenciado de: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Esperado en: /usr/local/lib/libluajit-5.1.2.dylib

SIGTRAP: trampa de rastreo
PC = 0x7fff66ff4075 m = 0 sigcode = 1
la señal llegó durante la ejecución de cgo
~~~
/usr/local/lib/libluajit-5.1.2.dylib no es la biblioteca necesaria, aunque se vinculó dinámicamente; más bien debe ser el especificado en $ {SRCDIR} /../../../ LuaJIT / LuaJIT / src / libluajit.a.

Así que sigo buscando una solución.

Actualización: parece que agregar esto a mis archivos MAKE hace el truco.
~exportar CGO_LDFLAGS_ALLOW = "$ {GOPATH} /src/github.com/gijit/gi/vendor/github.com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a ";~

Actualización: Afortunadamente, Ian señaló que la versión de expresiones regulares más corta funcionará:
~exportar CGO_LDFLAGS_ALLOW = ". *. a";~

¿Para qué sirve -Wl, -framework? Si ese es el marco de Apple, tiene un argumento, por lo que probablemente querrás -Wl, -framework, foo. Pero si es el marco de Apple, entonces -framework (no -Wl,) funciona igual de bien.

Con 1.10rc2, golang.org/x/net/internal/socket ya no se compila 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

(No hay cgo sucediendo aquí ya que esta es una compilación cruzada, pero supongo que eso no importa).

No puedo vincularme a un archivo lib estático especificando una ruta completa a él:

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

No veo ninguna solución alternativa :(

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

@ianlancetaylor , ¡gracias!

Eso servirá para mí, pero decirle a todas las demás personas que usan mi proyecto que hagan CGO_LDFLAGS_ALLOW='.*\.a$' for go 1.9.4 parece un poco dudoso.

con suerte, habrá una solución mejor (lista para usar) en el futuro.

@piotrnar Sí, el objetivo de este número es recopilar todos los cambios que necesitamos hacer en la lista blanca. Ciertamente, incluiremos archivos .a en la lista blanca.

¿Puede agregar también -fstack-protector ?

Gracias :)

Lista blanca -static-libstdc++ por favor.

El paquete github.com/flynn/hid no se puede compilar con 1.9.4 debido a que pasa -fconstant-cfstrings través de LDFLAGS en darwin.

Agregue estas banderas del vinculador a la lista blanca
-Wl, -Bstatic
-Wl, -Bdinámico
-Wl, - grupo de inicio
-Wl, - grupo final

Honestamente: en este punto, una lista negra de malas opciones me parece más útil que una lista blanca tan extensa.

En el futuro, una lista negra significaría que si se introdujera alguna nueva opción de compilador potencialmente insegura, todas las versiones de Go se volverían vulnerables a esa opción. En la medida en que podamos protegernos contra este tipo de ataque, creo que tiene que ser una lista blanca.

se introdujeron algunas nuevas opciones de compilador potencialmente inseguras

Sigo pensando que es preferible la lista negra. Porque corta en ambos sentidos. Si alguna nueva opción del compilador no se puede utilizar hasta que se incluya en la lista blanca, parecería que se requiere una nueva versión de Go cada vez que un nuevo compilador de C agrega una bandera ...

@glycerine Es por eso que proporcionamos las variables de entorno como una trampilla de escape. Siempre puede utilizar las variables de entorno hasta que se actualice la lista blanca.

El problema es que las variables env no funcionan para proyectos que se instalan simplemente a través de 'go get'.

Otro enfoque: permitir que el proyecto de nivel superior, denominado go, establezca variables de entorno.

Luego, el proyecto primario 'go build' que se está instalando puede incluir en la lista blanca los indicadores que necesita, por ejemplo, usando la expresión regular ALLOW, mientras que aún evita que los proyectos dependientes hagan cosas arbitrarias.

@glicerina No estoy seguro de entender cómo funcionaría. Pero le sugiero que abra un tema separado para esa sugerencia, en lugar de discutirlo sobre este tema, que está destinado a recopilar opciones que deben incluirse en la lista blanca.

Por ahora hemos decidido implementar una lista blanca. Eso puede cambiar en el futuro, pero este tema no es el lugar para discutirlo (siéntase libre de presentar uno nuevo). Estamos tratando de recopilar opciones que deberían incluirse en la lista blanca aquí y nada más.

Gracias.

bandera no válida en #cgo CFLAGS: -pipe

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

Hola, agregue estas banderas a la lista blanca, -Wl, - enable-new-dtags

No se puede construir la receta / qt

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

Agregar .*\.a a las banderas permitidas sería genial.
Ver https://github.com/golang/go/issues/23807

--mms-bitfields también parece ser necesario.

¿No es razonable suponer que todas las opciones del compilador (y enlazador, etc.) existen por una razón y que la lista blanca debería cubrirlas todas excepto las que se consideran específicamente peligrosas? Obviamente hay cientos de ellos y el mantenimiento de la lista blanca no va a ser divertido, pero si ese es el camino que se ha decidido ...

¿No es razonable suponer que todas las opciones del compilador (y enlazador, etc.) existen por una razón y que la lista blanca debería cubrirlas todas excepto las que se consideran específicamente peligrosas? Obviamente hay cientos de ellos y el mantenimiento de la lista blanca no va a ser divertido, pero si ese es el camino que se ha decidido ...

Esto probablemente se haya discutido internamente, pero encontré algo sorprendente para un lanzamiento de parche: hubiera esperado que las banderas ofensivas hubieran sido incluidas en la lista negra primero para tapar el orificio del complemento del compilador, y un sistema de lista blanca habilitado para 1.10, cuya lista podría haberse construido durante RC. Las variables de entorno adicionales no son muy prácticas de integrar en algunos sistemas de compilación, y observé que esto lleva a que las personas simplemente vuelvan a la versión 1.9.3 y, por lo tanto, estén completamente desprotegidas, lo que creo que es completamente contraproducente.

¿En qué momento una lista blanca llena de comodines y expresiones regulares se convierte en una lista negra disfrazada?

gomobile usa las banderas -fobjc-arc -fmodules -fblocks:

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

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

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

-flto

¿Podría poner una lista ordenada alfabéticamente de los "aprobados" en la parte superior de este número para una descripción general hasta que salga la próxima actualización? Quien presente la CL también puede apreciarlo.

En este momento (especialmente desde que existe este problema) estoy más preocupado por lo que se está escapando: las banderas de construcción que las personas han eliminado de sus proyectos sin consultarnos primero, lo que les da la creencia equivocada de que cgo (y, por extensión, Go) está roto. y tiene errores y regresiones y sus desarrolladores no saben lo que están haciendo. : S (O peor, que no saben lo que está haciendo y obviamente está construyendo mi paquete equivocado, porque usted es la que se perdió la dependencia XYZ!)

Algunos de los enlaces "hizo referencia a este problema" enumeran más banderas en la lista negra que aún no están en este problema. También doy fe de tener una lista maestra en la parte superior, especialmente para evitar duplicados. La gente todavía se encuentra con el problema del archivo estático ...

Esto me hace preguntarme si gcc y clang en sí mismos podrían, o incluso deberían , proporcionar una opción --no-unsafe-options que a) haría el trabajo sucio por nosotros b) ser resistente a cambios futuros yc) no puede ser desactivado por otro opción (una vez que está allí, está allí, punto). ¿O es go get la primera y única situación en la que se necesita este tipo de filtrado?

Si insistimos en una lista blanca, entonces no sé por qué debe haber demora en la espera de la entrada.

Los compiladores documentan sus banderas. Como alguien dijo anteriormente, cada bandera está ahí por una razón.

El muestreo al esperar la entrada del usuario sobre el uso será poco representativo, poco confiable y producirá resultados dolorosos para todos los que en el futuro encontremos la necesidad de una bandera que no se realizó o muestreó ahora.

Además, parece sencillo derivar la lista blanca mediante este procedimiento, en pseudocódigo:

Enumere todos los compiladores de C / C ++ y las versiones de cada compilador admitido;
Para cada versión del compilador, enumere todos los indicadores disponibles en sus documentos;
Para cada bandera, decida ponerla en la lista blanca o en la lista negra (invisible).

Agregue el código de la lista blanca para todas las banderas de la lista blanca acumulada.

Sigo pensando que esto es una locura (al borde de la reducción ad absurdum) en comparación con poner en la lista negra una (o dos) banderas vulnerables. Pero con toda seriedad, si vamos a insistir en una lista blanca, el algoritmo anterior es correcto, elimina las conjeturas y se puede ejecutar sin demora. Quizás la única entrada adicional requerida por el usuario sería establecer la gama de compiladores / versiones que se admitirán.

Las únicas opciones que importan aquí son las que son razonables para poner en una línea #cgo CFLAGS o #cgo LDFLAGS en un archivo .go, o son razonables para generar una salida desde una llamada a pkg-config --cflags o pkg-config --libs . Ese es un pequeño subconjunto del número total de opciones del compilador.

También subestimas enormemente cuántas opciones tienen gcc y clang. Dudo que estén todos documentados, incluso en el código fuente; ¡no me sorprendería que algunos se generen en tiempo de ejecución! También puede haber opciones que sean triplemente dependientes del objetivo ... (Esta es también la razón por la que digo que los desarrolladores de gcc y clang deberían mantener una lista canónica de banderas seguras).

Sin embargo, no puedo decir nada sobre la demora en parchear banderas individuales.

@anacrolix En # 23672 sugirió que debemos incluir en la lista blanca -Wl,-framework . Pero -framework normalmente toma una opción. ¿Puede mostrar el caso de uso exacto? Gracias.

También subestimas enormemente cuántas opciones tienen gcc y clang

@andlabs Ian es un desarrollador de gcc. Estoy seguro de que lo sabe muy bien.

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

Envié un CL que creo que cubre todas las opciones anteriores: https://golang.org/cl/93836.

Por favor, avíseme si ve algún problema con él o si conoce alguna de las opciones que la gente está usando y que no cubre. Gracias.

Desde el punto de vista de los enlaces LLVM Go, las siguientes opciones del enlazador deberían estar en la lista blanca.

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

Las opciones del vinculador se generan mediante el comando llvm-config --ldflags y están en la salida.

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

@magical Estaba respondiendo a @glycerine there = P

@ianlancetaylor también me

@andlabs Ah, lo siento

@ianlancetaylor Con ese CL todavía no puedo construir golang.org/x/net/internal/socket para Solaris. No es obvio para mí por el error qué indicadores debo 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 Sí. Creo que tendremos que arreglar eso con cambios en golang.org/x/net. Ya se basa en muchos detalles internos y creo que debemos cambiar la forma en que lo hace.

@calmh ¿Podrías probar https://golang.org/cl/94015 en un sistema Solaris real?

El cambio https://golang.org/cl/94015 menciona este problema: internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix Descubrí de dónde viene -Wl,-framework : proviene del archivo pkg-config para GLib, que es una dependencia de GTK +. En concreto, incluye el enlace CoreFoundation para fines de internacionalización.

Referencias específicas: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14 donde @INTLLIBS@ obtiene -Wl,-framework -Wl,CoreFoundation de https: // gitlab .gnome.org / GNOME / glib / blob / master / m4macros / glib-gettext.m4 # L143

Hay otras instancias -Wl,-framework en varios otros archivos pkg-config; algunos son parte de los proyectos en sí mismos (como arriba), y otros son inyectados por Homebrew. En mi sistema en este momento, veo que libcdio y SDL usan -Wl,-framework,FrameworkName . (Lo que significa que sí, tanto -Wl,-framework -Wl,FrameworkName como -Wl,-framework,FrameworkName se encuentran en los archivos pkg-config. Vaya a la figura).

El cambio https://golang.org/cl/94018 menciona este problema: cmd/compile: permit go:cgo_import_dynamic anywhere

@calmh Intentando un enfoque diferente en https://golang.org/cl/94018.

@andlabs Gracias, agregado a CL 93836.

Estoy vinculando SDL de forma estática y pgkconfig contiene -Wl,--no-undefined además de las definiciones del preprocesador.

Necesito que agregue las banderas debajo de la lista blanca, para que puedan compilar proyectos que usen el paquete cgoemitter

ve a compilar github.com/supermock/cgoemitter-demo/x: indicador no válido en #cgo LDFLAGS: -Wl, -unresolved-symbols = ignore-all

Muchas gracias por adelantado

Actualice CL nuevamente.

Agregué una página wiki para describir este problema en https://golang.org/wiki/InvalidFlag , y estoy actualizando la CL para que el mensaje de error dirija a las personas a la wiki.

El cambio 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

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

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

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

También recibiendo este problema, si se puede agregar lo siguiente

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

@ bgk: el parche que se ha aplicado aborda eso. Si actualizar a 1.10 no es factible en este momento, tendría que sugerir que espere para ver si ocurre un 1.9.5.

¿Debería 1.10 haber solucionado el problema invalid pkg-config package name: --static ? Acabo de descargar la última versión de homebrew y todavía la veo:

➜  ~ 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

Reapertura para 1.9.5.

Evitaré el problema XY y más bien explicaré completamente lo que estoy haciendo. Estoy creando una extensión postgresql con -buildmode=c-shared .

En la documentación para crear extensiones C para postgresql se encuentra esta como la forma de construir el objeto compartido:

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

Así que agregué #cgo LDFLAGS: -shared a mi código fuente. Funcionó hasta hace poco (go1.10) cuando deja de construir con:

invalid flag in #cgo LDFLAGS: -shared

Solo agarré go 1.10, me encontré con esto:

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

Esta es una bandera del enlazador gcc para forzar el enlace estático para cualquier cosa después de esa opción en la línea de enlace.

@spackard Para que conste, eso no es lo que significa esa opción. Estás pensando en -Bstatic . La opción -static indica al enlazador que no busque bibliotecas compartidas para satisfacer las opciones -l . -static no es una opción posicional; no importa dónde aparezca en la línea de comando.

@ianlancetaylor Tienes razón sobre lo posicional. Así es como estamos forzando la vinculación estática independientemente. Para el registro, agregarlo a CGO_LDFLAGS_ALLOW funciona.

Tengo el mismo problema

invalid flag in #cgo CFLAGS: -m32

Llegamos a esto con -O3, -static-libgcc y -static-libstdc ++

-O3:

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

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

cgo CFLAGS: -O3

bandera no válida en #cgo LDFLAGS: -O3

-static-libgcc:

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

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

indicador no válido en #cgo LDFLAGS: -static-libgcc

-static-libstdc ++:

LDFLAGS de Windows cgo: -L./ -lmass -static-libstdc ++

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

indicador no válido en #cgo LDFLAGS: -static-libstdc ++

usar listas blancas estáticas codificadas es una mala idea, tal vez deberíamos usar un archivo de configuración con algunas configuraciones predeterminadas como

$ GOROOT / bin / cgo.cfg
[listas blancas]
bla bla bla
...

para que podamos personalizar un poco

@kruglinski Puede personalizar utilizando la variable de entorno CGO_CFLAGS_ALLOW y sus amigos.

@ianlancetaylor

Lo siento, me perdí de esto :-) ¡Es bueno saberlo, muchos piensan!

24124 informa la siguiente opción de vinculador:

-Wl,-z,relro

La opción del enlazador -Wl,--subsystem,windows y la opción del compilador -mwindows faltan.

Estoy tratando de hacer que gomobile / gobind genere enlaces independientes. Parte de ese trabajo implica convertir las variables de entorno CGO_ * FLAGS en directivas #cgo, que revelaron algunas banderas más:

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

-objetivo(para Android)
--sysroot(para Android)
-gcc-cadena de herramientas(para Android)
`` ``

Creo que todos, excepto el último, -gcc-toolchain, son seguros para agregar a la lista blanca.

Se necesitan los siguientes indicadores para crear enlaces Go para el motor de juego Godot sin CGO_LDFLAGS_ALLOW en macOS:

-Wl,-undefined,dynamic_lookup

Más CFLAGS de zchee / libhyperkit :

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

v8worker necesita -stdlib=libstdc++ en Mac OS X.

CL 103156 OK para Go 1.9.5

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

No pude verlo en la lista, ¿podría libtool también estar en la lista blanca?

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

@PassKit -I es un cflag (que está en la lista) no un ldflag, ¿por qué lo pone en ldflags?

Reapertura para recopilar más solicitudes de lista blanca.

Desde # 24703

CFLAGS: -fno-plt

En este punto, creo que está bien decidir que solo actualizaremos las ramas de la versión 1.9 y 1.10 si algún paquete popular no se puede compilar y de alguna manera aún no se ha informado. No creo que debamos seguir portando todas las opciones aleatorias. Podemos agregarlos a la propina por 1,11. Ya sea que los rastreemos en este número o en otro lugar, no me importa.

sgtm

@AlexRouSg mi problema estaba relacionado con esta biblioteca, que recomendó incluir "-I" en la lista blanca como ldflag, que estoy usando actualmente como solución. https://github.com/miekg/pkcs11/issues/63

Perdón por llegar tarde, pero sería genial si estos estuvieran en la lista blanca en 1.9.5 o 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

y

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

Gracias por adelantado.

@therecipe Podemos agregarlos a 1.11. Pero para 1.9.5 o 1.10.2: ¿qué paquetes los necesitan?

@ianlancetaylor Todos son necesarios para los diferentes objetivos de https://github.com/therecipe/qt
Está bien si no los incluyes todos en la lista blanca a la vez, pero avísame de cuál debería ocuparme.

Supongo que es su propio paquete Qt, que sé que es lo suficientemente antiguo como para estar bien establecido; No estoy completamente seguro de si lo es (alguien más tendrá que decirlo).

Habiendo dicho eso:

• ¿No están algunos de los LDFLAGS ya incluidos en la lista blanca sin el prefijo -Wl, ?
• ¿Tiene -e algún efecto en Go?
• ¿No estaba -F ya en la lista blanca? Esa resulta ser la opción a la que me refería anteriormente .
• (Para @therecipe) ¿Por qué estás protegiendo un -D con un -Wp ? ¿Hay alguna razón para tener una macro definida pero solo en el preprocesador? No sé qué tipo de vudú hace Qt aquí ... ¿O es esta una lista recomendada de opciones proporcionada por el propio Qt?
• (Para @ianlancetaylor) Puedo entender que no tengo que respaldar nuevas opciones a 1.9 (soy ambivalente sobre el tema porque no tengo métricas de uso de la versión Go), pero ¿por qué no 1.10 hasta que se publique 1.12?
• Independientemente de la respuesta a lo anterior, me pregunto si vale la pena hacer backporting de las opciones ARM ABI enumeradas allí ...

@andlabs Solo porque tenemos que parar en algún momento, ¿por qué no parar ahora? Pero estoy de acuerdo con continuar con los parches de respaldo si parece lo suficientemente útil.

@andlabs Sí, todos esos son indicadores recomendados. No agregué manualmente uno solo de ellos.
-Wp,-D_FORTIFY_SOURCE=2 era del iirc objetivo del pez vela, no sé por qué lo hicieron.

@therecipe en ese caso, ¿dónde hacen Qt y Sailfish esas sugerencias (es decir, hay una página web o una herramienta CLI que se las proporcione)? Tengo curiosidad ahora.

Mientras tanto, aunque el equipo de Go se ocupa de esa lista, todavía me pregunto cuántas de sus advertencias LDFLAGS desaparecen si elimina los prefijos -Wl, ; prueba eso y verás? Lo mismo para el prefijo -Wp, en el CFLAGS . No sé si esto tendrá efectos adversos en la construcción, pero no debería ser así en un mundo ideal porque para eso es LDFLAGS ... (También tendrás que cambiar las comas por espacios. Estos -Wx, opciones

@andlabs Sí, una de las herramientas de compilación de Qt qmake consume *.pro , *.spec (mkspec), *.conf y muchos otros formatos para generar Makefiles regulares. Solo le doy algunos archivos ficticios *.pro y extraigo las banderas de los Makefiles. De esa manera, realmente no tengo que resolver las dependencias yo mismo, el proceso de compilación puede funcionar más fácilmente con bibliotecas de terceros, no tengo que administrar manualmente las banderas c o ld y los objetivos no probados o las versiones más nuevas / antiguas de Qt funcionan fuera de la caja la mayor parte del tiempo. De vez en cuando tengo que poner en la lista negra algunas banderas que causan problemas, pero eso es muy raro.

Traté de encontrar el pez vela mkspec que atrae -Wp,-D_FORTIFY_SOURCE=2 , pero probablemente esté enterrado en algún lugar del mersdk más o menos. Pero aquí está la lista oficial de objetivos para los que TQtC mantiene soporte: https://github.com/qt/qtbase/tree/5.11/mkspecs y hay muchos objetivos no oficiales mantenidos por partes independientes. Es por eso que realmente no quiero meterme manualmente con las banderas.

Mientras tanto, puedo incluirlos en la lista blanca en la herramienta de compilación utilizada por el enlace (que envuelve go ), pero el usuario habitual de Go que solo quiere usar go build ... tarde o temprano planteará un problema. . (al menos para los destinos de escritorio)

-matemáticas-rápidas

El controlador de cliente oficial de SAP HANA (la biblioteca compartida basada en cgo) viene con #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN que da como resultado go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath . Consulte también la documentación de SAP en https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca5629083869069e5.html?q=golang%20driver para obtener más detalles.

@cbgo ver # 23672

El código que pasa un indicador y un par de argumentos al vinculador ahora debe usar un indicador -Wl en lugar de dos: use #cgo LDFLAGS: -Wl, -rpath, $ ORIGIN, no #cgo LDFLAGS: -Wl, -rpath -Wl, $ ORIGEN.

@AlexRouSg muchas gracias. Debería haberlo leído con más atención :-)

@PassKit ¿

@ zcm211 Si estás hablando de https://github.com/miekg/pkcs11 , eliminaron la bandera del enlazador -I... en feb. Si está utilizando un paquete que lo usa, debe establecer la variable de entorno CGO_LDFLAGS_ALLOW="-I.*"

darwin 64-bit, go1.10.2, pensé que los archivos .o estaban en la lista blanca para LDFLAG, pero obtengo:
~jaten @ jatens-MacBook-Pro ~ / go / src / github.com / go-interpreter / chezgo (maestro) $ make runcd chez_scheme_9.5.1 / c;








debido al preámbulo de cgo en 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 Según https://go-review.googlesource.com/c/go/+/94676 lo son. ¿Quizás probar una ruta completa en lugar de una relativa?

Buen comentario @AlexRouSg , la expresión regular de aceptación tiene errores como señala;
~re ( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) ), // entradas directas del enlazador: xo o libfoo.so (pero no -foo.o o @ foo.o)~
src / cmd / go / internal / work / security.go # 121 debería permitir que los archivos .o comiencen con . para admitir rutas relativas.

Después de todo, no puedo predecir el GOPATH de los usuarios, o qué tan anidada estará la ubicación de ese archivo, por lo que establecer una ruta absoluta no es práctico.

¿Está el archivo .o en el directorio de origen? Si es así, consultar el directorio de origen es para lo que se proporcionó ${SRCDIR} . (Olvidé específicamente por qué se introdujo esto, pero no fue por este problema).

@andlabs Incluso si hay soluciones alternativas, las rutas relativas deberían poder vincularse, y eso es claramente un error.

Lo es, excepto IIRC, no hay garantía de que el enlace sea relativo al directorio de origen (podría muy bien estar en $WORK , y luego su ruta relativa se rompe nuevamente) ... Una vez más, lo he olvidado la historia; alguien más tendrá que explicarlo.

gtk4 usa -mfpmath = sse

@ianlancetaylor En lugar de tener listas blancas separadas para cflags y ldflags, ¿debería haber solo una lista? A gcc / llvm no parece importarle que mezcle ldflags en cflags y viceversa. Y parece que a veces los desarrolladores de C hacen eso, lo que causa problemas como # 25493 o https://github.com/golang/go/issues/23749#issuecomment -379969818

Ah, veo que ya tenemos un ticket, así que permítanme mencionar "-D_THREAD_SAFE" de protobuf como se documenta en # 25493

El cambio https://golang.org/cl/115415 menciona este problema: cmd/go: accept more safe CFLAGS/LDFLAGS

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

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

Hola chicos,
¿Por qué se resuelve este problema cuando todavía no podemos compilar bimg con la última versión de Go a fecha de 9/4/2018?
Consulte el problema: https://github.com/h2non/bimg/issues/230
No podemos construir nada que importe bimg desde Go 1.10 y el problema aún persiste en Go 1.11
El mensaje de error que recibimos es este:

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

¿Algún consejo?

EDITAR:
Creé un nuevo problema: https://github.com/golang/go/issues/27496

Creo que esta lista blanca es responsable de lo siguiente: https://github.com/alexflint/gallium/issues/63

@alexflint Este problema está cerrado, cree uno nuevo