23737 сообщает, что флаги, сгенерированные pkg-config -libs , проверяются по белому списку компилятора и CGO_CFLAGS_ALLOW , тогда как вместо этого они должны проверяться по белому списку компоновщика и CGO_LDFLAGS_ALLOW . Чтобы это исправить, существует CL: https://golang.org/cl/92755.

Белый список компоновщика должен принимать файлы .a поскольку он уже принимает файлы .o , .so и т. Д. Чтобы это исправить, существует CL: https://golang.org/cl/92855. Это № 23739.

Комментарии к # 23672 перечисляют эти параметры компилятора:

-fno-rtti
-fpermissive

и эти параметры компоновщика:

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

23742 предлагает добавить параметр компилятора -fmodules . Компилятор clang поддерживает ряд параметров -fmodules , но неясно, безопасны ли они все. В частности, -fmodules-cache-path и -fmodules-user-build-path , по-видимому, позволяют указать путь, который clang будет использовать для чтения модулей, что, возможно, могло бы изменить режим компиляции различными способами.

23743 предлагает добавить опцию компоновщика -Wl,--no-as-needed . Для этого есть CL: https://golang.org/cl/92795.

23744 предлагает добавить следующие параметры компилятора:

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

Существует множество параметров компилятора и компоновщика, которые можно использовать как с одинарным, так и с двойным тире. Мы также должны быть небрежны в отношении белых списков.

Для ортогональности: я забываю, уже покрыта опция добавления каталога в путь поиска -framework . Я также забыл, что это за вариант. (Типичный вариант использования, который я могу придумать, - это /Library/Frameworks , где Apple размещает фреймворки для конкретных приложений и по умолчанию не просматривается.)

Также безопасно ли использовать -as-needed с cgo? В этом сообщении в блоге (который является первым результатом, который я могу найти для «gcc as-required») говорится, что это позиционный аргумент, но я не уверен, что cgo гарантирует что-либо о том, где ваши флаги помещаются в результирующих командных строках.

@andlabs Это нормально писать

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

В любом случае, тема этой проблемы должна заключаться в том, безопасно ли использовать параметры из go get .

Когда используешь:

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

компиляция завершается ошибкой со следующим сообщением:

invalid pkg-config package name: --static

При просмотре кода (для версии 1.9.4) выясняется, что нет никаких переменных среды, которые можно было бы использовать для внесения в белый список аргументов pkg-config.

Вывод @rgburke pkg-config проходит через те же переменные FLAGS_ALLOW что и другие выходные данные.

Однако оказывается, что pkg-config -libs проверяет CGO_CFLAGS_ALLOW когда ему следует проверить CGO_LDFLAGS_ALLOW .

Мы связываем большое количество библиотек C статически в проект с закрытым исходным кодом. До сих пор мы делали следующее:

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

Конечно, сейчас это запрещено. Обходной путь:

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

Однако некоторые из этих каталогов также содержат динамические библиотеки, что сбивает компоновщик с толку. Другой вариант - добавить '/' в список разрешенных «имен» в https://go-review.googlesource.com/c/go/+/92855. В частности, изменение в строке 91:

re(`[a-zA-Z0-9_\/].*\.(o|obj|dll|dylib|so|a)`), // direct linker inputs: x.o or libfoo.so (but not -foo.o or @foo.o)

последний вариант решает нашу проблему, но я не могу говорить о его влиянии на безопасность.

@mirtchovski для этого есть патч (проблема в том, что .a не был включен в белый список, но другие форматы объектных файлов были)

.a теперь занесен в белый список (после этого патча), поэтому libsomething.a будет работать, но /path/to/libsomething.a не будет работать.

@ianlancetaylor @rgburke На самом деле я столкнулся с той же проблемой с --static которая привела меня к # 23737. --static отклоняется, поскольку оно не является допустимым именем пакета _ перед_ попыткой выполнить pkg-config , здесь https://github.com/golang/go/blob/104445e3140f4468839db49a25cb0182f7923174/src/ cmd / go / internal / work / exec.go # L939 -L940.

Наше быстрое внутреннее исправление заключалось в том, чтобы указать PKG_CONFIG на сценарий, который просто выполнял pkg-config --static "$@" .

@jeddenlea - Большое спасибо! Я пытался найти обходной путь, но не подумал об этом.

Мы достигаем этого с помощью -msse и -msse4.2 .

Я столкнулся с этой проблемой с "$ {SRCDIR} /file.o" в cgo LDFLAGS.

Я хотел бы поспорить, что мы должны разрешить использование простых имен файлов, которые вводятся компоновщиком
файлы в LDFLAGS
(как минимум * .a, * .o и * .so).

В отличие от .a и .so, которые теоретически могут обрабатываться с помощью "-L $ {SRCDIR}"
-lname ", добавив
дополнительные объектные файлы для команды компоновщика не могут быть исправлены таким образом.

Обходной путь - установить CGO_LDFLAGS_ALLOW, но это очень громоздко.
Другой
альтернатива - переименовать мой file.o в file.syso, однако для моего конкретного
случай, я не могу использовать
этот параметр, потому что я включаю только этот файл. o когда указан конкретный тег сборки
включены (
тег build применяется к файлу, содержащему преамбулу #cgo LDFLAGS) и
выхода нет
для установки произвольного тега сборки в именах файлов syso.

Если мы проигнорируем предыдущие развернутые версии Go, мы могли бы включить
новый
"#cgo LDLIBS", который разработан специально для добавления дополнительных файлов в компоновщик.
командная строка.
Тогда у нас может быть более строгое правило для LDLIBS (только имена файлов, без тире
разрешено в префиксе.)

Мы достигли этого с помощью --std=c99

-std = c ++ 11

Я думаю -std =должен быть в белом списке?

Вероятно, в белом списке: -fopenmp

Ошибка при сборке пакета bimg с использованием Go v1.10rc2,

23:24 ~/go-test
master ms 130 % go get -v github.com/h2non/bimg
github.com/h2non/bimg (download)
github.com/h2non/bimg
go build github.com/h2non/bimg: invalid flag in pkg-config --cflags: -fopenmp

Я не могу внести в белый список -isystem поскольку аргумент рядом с ним (который является путем) будет отклонен

Нам также нужно было использовать этот обходной путь: https://github.com/golang/go/issues/23749#issuecomment -364239496

Ранее у нас было:

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

и перешли на:

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

.../path/to/thing находится вне ${SRCDIR} .

Добавление этого комментария так что этот вопрос включает в себя пример с libthing.a ссылки , который нуждается в SRCDIR расширения решить.

на OSX, с недавно выпущенным go1.9.4 с его ограничениями флага cgo, я конкретно указывал компоновщику, на какой архив .a ссылаться: (здесь https://github.com/gijit/gi/blob/master/vendor/ github.com/glycerine/golua/lua/lua.go#L10)

~~~

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

~~~

при попытке построить:

~сделать сборкуgo build -ldflags "-X main.LastGitCommitHash = 30259813c10c0f6b63768b4f35358828e2e29f0b -X main.BuildTimeStamp = 2018-02-09T22: 49: 48 + 0700 -X main.GitBranch = master -X main.NearestGit.6Tagers = v0 = go_version_go1.9.4_darwin / amd64 "-o gigo build github.com/gijit/gi/vendor/github.com/glycerine/golua/lua: недопустимый флаг в #cgo LDFLAGS: /Users/jaten/go/src/github.com/gijit/gi/vendor/github. com / глицерин / golua / lua /../../../ LuaJIT / LuaJIT / src / libluajit.amake [2]: * [build] Ошибка 1make [1]: [установить] Ошибка 2make: ** [install] Ошибка 2jaten @ jatens-MacBook-Pro ~ / go / src / github.com / gijit / gi (мастер) $~
Я пробовал обходной путь -L -l,
~~~

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

~~~
но тогда компоновщик думает, что он может использовать другую библиотеку с тем же именем в другом месте, и я получаю ошибку времени выполнения, а не времени компоновки.

~~~
во время выполнения ...
dyld: сбой при привязке ленивого символа: символ не найден: _luajit_ctypeid
Ссылка на: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Ожидается в: /usr/local/lib/libluajit-5.1.2.dylib

dyld: Символ не найден: _luajit_ctypeid
Ссылка на: /var/folders/6s/zdc0hvvx7kqcglg5yqm3kl4r0000gn/T/go-build615587282/github.com/gijit/gi/pkg/compiler/_test/compiler.test
Ожидается в: /usr/local/lib/libluajit-5.1.2.dylib

SIGTRAP: ловушка трассировки
ПК = 0x7fff66ff4075 m = 0 sigcode = 1
сигнал прибыл во время выполнения cgo
~~~
/usr/local/lib/libluajit-5.1.2.dylib не является необходимой библиотекой, хотя она была динамически скомпонована; скорее это должен быть тот, который указан в $ {SRCDIR} /../../../ LuaJIT / LuaJIT / src / libluajit.a.

Так что все еще ищем обходной путь.

Обновление: похоже, что добавление этого в мои make-файлы помогает.
~экспорт CGO_LDFLAGS_ALLOW = "$ {GOPATH} /src/github.com/gijit/gi/vendor/github.com/glycerine/golua/lua/../../../LuaJIT/LuaJIT/src/libluajit.a ";~

Обновление: К счастью, Ян указал, что подойдет более короткая версия регулярного выражения:
~экспорт CGO_LDFLAGS_ALLOW = ". *. a";~

Для чего нужен -Wl, -framework? Если это фреймворк Apple, у него есть аргумент, поэтому вы, вероятно, захотите -Wl, -framework, foo. Но если это фреймворк Apple, то -framework (без -Wl,) тоже работает.

С 1.10rc2 golang.org/x/net/internal/socket больше не собирается для Solaris.

$ GOOS=solaris go build golang.org/x/net/ipv4
# golang.org/x/net/internal/socket
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:24:3: //go:cgo_import_dynamic libc___xnet_getsockopt __xnet_getsockopt "libsocket.so" only allowed in cgo-generated code
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:25:3: //go:cgo_import_dynamic libc_setsockopt setsockopt "libsocket.so" only allowed in cgo-generated code
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:26:3: //go:cgo_import_dynamic libc___xnet_recvmsg __xnet_recvmsg "libsocket.so" only allowed in cgo-generated code
ext/src/golang.org/x/net/internal/socket/sys_solaris.go:27:3: //go:cgo_import_dynamic libc___xnet_sendmsg __xnet_sendmsg "libsocket.so" only allowed in cgo-generated code

(Здесь не происходит никакого cgo, поскольку это кросс-билд, но я думаю, это не имеет значения.)

Я не могу создать ссылку на статический файл библиотеки, указав к нему полный путь:

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

Я не вижу обходного пути для этого :(

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

@ianlancetaylor , спасибо!

это подойдет для меня, но говорить всем другим людям, которые используют мой проект, чтобы они сделали CGO_LDFLAGS_ALLOW='.*\.a$' для Go 1.9.4, кажется немного изворотливым.

надеюсь, что в будущем будет лучшее (готовое к использованию) решение.

@piotrnar Да, цель этой проблемы - собрать все изменения, которые нам нужно внести в белый список. Конечно, мы добавим файлы .a в белый список.

не могли бы вы добавить еще -fstack-protector ?

Благодарность :)

Добавьте в белый список -static-libstdc++ пожалуйста.

Пакет github.com/flynn/hid не может быть собран с 1.9.4 из-за передачи -fconstant-cfstrings через LDFLAGS на darwin.

Добавьте эти флаги компоновщика в белый список
-Wl, -Bstatic
-Wl, -Bdynamic
-Wl, - стартовая группа
-Wl, - конечная группа

Честно говоря: на данный момент черный список плохих вариантов мне кажется более полезным, чем такой обширный белый список.

В дальнейшем черный список будет означать, что если будет введена какая-то новая потенциально небезопасная опция компилятора, все выпуски Go станут уязвимыми для этой опции. В той степени, в которой мы вообще можем защитить от такого рода атак, я думаю, что это должен быть белый список.

были введены некоторые новые потенциально небезопасные параметры компилятора

Я по-прежнему считаю, что черный список предпочтительнее. Потому что это обоюдоострое. Если какая-либо новая опция компилятора не может быть использована до тех пор, пока она не будет добавлена ​​в белый список, это, по-видимому, потребует новой версии Go каждый раз, когда какой-либо новый компилятор C добавляет флаг ...

@glycerine Вот почему мы предоставляем переменные среды в качестве аварийного выхода. Вы всегда можете использовать переменные среды, пока не будет обновлен белый список.

Проблема в том, что переменные env не работают для проектов, которые устанавливаются исключительно через команду «go get».

Другой подход: разрешить верхнему уровню с именем go project устанавливать переменные среды.

Затем основной устанавливаемый проект «go build» может занести в белый список необходимые ему флаги, например, используя регулярное выражение ALLOW, при этом не позволяя зависимым проектам выполнять произвольные действия.

@glycerine Я не уверен, что понимаю, как это сработает. Но я предлагаю вам открыть отдельный вопрос для этого предложения, а не обсуждать его по этому вопросу, который предназначен для сбора вариантов, которые необходимо внести в белый список.

На данный момент мы решили внедрить белый список. Это может измениться в будущем, но этот вопрос не место для его обсуждения (не стесняйтесь подавать новый). Мы пытаемся собрать варианты, которые должны быть здесь внесены в белый список, и не более того.

Спасибо.

недопустимый флаг в #cgo CFLAGS: -pipe

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

Привет, пожалуйста, добавьте эти флаги в белый список, -Wl, - enable-new-dtags

Невозможно собрать здесьcipe / qt

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

Было бы здорово добавить .*\.a к разрешенным флагам.
См. Https://github.com/golang/go/issues/23807

--mms-bitfields также кажется обязательным.

Разве не разумно предположить, что каждая опция компилятора (и компоновщика и т. Д.) Существует по какой-то причине, и белый список должен охватывать все из них, кроме тех, которые специально считаются опасными? Очевидно, их сотни, и вести белый список будет неинтересно, но если выбран именно такой путь ...

Разве не разумно предположить, что каждая опция компилятора (и компоновщика и т. Д.) Существует по какой-то причине, и белый список должен охватывать все из них, кроме тех, которые специально считаются опасными? Очевидно, их сотни, и вести белый список будет неинтересно, но если выбран именно такой путь ...

Это, вероятно, обсуждалось внутри компании, но я нашел вещь удивительной для выпуска патча: я ожидал, что вызывающие нарушение флаги будут сначала внесены в черный список, чтобы закрыть дыру в плагине компилятора, и система белых списков, включенная для 1.10, список которых можно было бы создать. вверх во время RC. Дополнительные переменные env не совсем практичны для интеграции в некоторые системы сборки, и я заметил, что это приводит к тому, что люди просто возвращаются к 1.9.3 и, таким образом, становятся полностью незащищенными, что, как я считаю, совершенно контрпродуктивно.

В какой момент белый список, полный подстановочных знаков и регулярных выражений, становится скрытым черным списком?

gomobile использует флаги -fobjc-arc -fmodules -fblocks:

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

https://github.com/augustoroman/v8 использует -pthread:

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

-flto

Не могли бы вы поместить отсортированный по алфавиту список «одобренных» в начало этой проблемы для обзора до выхода следующего обновления? Тот, кто отправляет CL, тоже может это оценить.

Прямо сейчас (тем более, что эта проблема существует) меня больше беспокоит то, что ускользает от трещин: какие флаги сборки люди удалили из своих проектов, предварительно не посоветовавшись с нами, что дает им ошибочное убеждение, что cgo (и, как следствие, Go) сломаны и глючит, и у него есть регрессии, и его разработчики не знают, что делают. : S (Или, что еще хуже, очевидно , неправильно строите мой пакет, потому что вам не хватает зависимости xyz!)

В некоторых ссылках «упоминается эта проблема» перечислено больше флагов, занесенных в черный список, которых пока нет в этой проблеме. Я также ручаюсь за наличие главного списка вверху, особенно для предотвращения дублирования. Люди все еще сталкиваются с проблемой статического архива ...

Это заставляет меня задаться вопросом, могут ли сами gcc и clang предоставить или даже должны предоставить опцию --no-unsafe-options которая а) сделает за нас грязную работу б) будет устойчивой к будущим изменениям и в) не может быть отключена другим вариант (как только он там, он там, точка). Или go get - первая и единственная ситуация, в которой требуется подобная фильтрация?

Если мы настаиваем на белом списке, то я не знаю, зачем нужна задержка в ожидании ввода.

Компиляторы документируют свои флаги. Как кто-то сказал выше, у каждого флага есть причина.

Выборка путем ожидания ввода данных пользователем об использовании будет недостаточно репрезентативной, ненадежной и приведет к болезненным результатам для всех нас, кто в будущем обнаружит необходимость в флаге, который не был реализован или не выбран сейчас.

Более того, получить белый список с помощью этой процедуры в псевдокоде кажется несложным:

Перечислите все компиляторы C / C ++ и версии каждого поддерживаемого компилятора;
Для каждой версии компилятора перечислите все флаги, доступные в их документации;
Для каждого флага решите поместить его в белый или (невидимый) черный список.

Добавьте код белого списка для всех флагов в накопленном белом списке.

Я все еще думаю, что это безумие (граничащее с сокращением до абсурда) по сравнению с занесением в черный список одного (или двух) уязвимых флагов. Но если серьезно, если мы будем настаивать на белом списке, приведенный выше алгоритм верен, исключает догадки и может быть выполнен без промедления. Возможно, единственное, что потребуется от пользователя, - это установить диапазон поддерживаемых компиляторов / версий.

Здесь важны только те варианты, которые разумно поместить в строку #cgo CFLAGS или #cgo LDFLAGS в файле .go, либо разумно выводить из вызова pkg-config --cflags или pkg-config --libs . Это небольшая часть от общего числа опций компилятора.

Вы также сильно недооцениваете, сколько опций gcc и clang вообще есть. Я сомневаюсь, что все они задокументированы, даже в исходном коде - я не удивлюсь, если некоторые из них будут сгенерированы во время выполнения! Также могут быть параметры, которые зависят от трех целей ... (Вот почему я говорю, что разработчикам gcc и clang необходимо поддерживать канонический список безопасных флагов.)

Однако я ничего не могу сказать о задержке установки отдельных флагов.

@anacrolix В # 23672 вы предложили внести в белый список -Wl,-framework . Но -framework обычно принимает вариант. Вы можете показать точный вариант использования? Спасибо.

Вы также сильно недооцениваете, сколько опций gcc и clang вообще есть

@andlabs Ян - разработчик gcc. Я уверен, что он хорошо осведомлен.

Изменение https://golang.org/cl/93836 упоминает эту проблему: cmd/go: add options to security whitelist

Я отправил CL, который, как мне кажется, охватывает все вышеперечисленные варианты: https://golang.org/cl/93836.

Пожалуйста, дайте мне знать, если вы обнаружите какие-либо проблемы с ним или если вы знаете какие-либо варианты, которые люди используют, которые он не покрывает. Спасибо.

С точки зрения привязок LLVM Go следующие параметры компоновщика должны быть в белом списке.

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

Параметры компоновщика генерируются командой llvm-config --ldflags и они находятся в выводе.

ссылка: https://reviews.llvm.org/D43070

@magical Я отвечал на @glycerine там = P

@ianlancetaylor также приносит свои извинения, если я заставляю вас чувствовать себя поспешно с этим

@andlabs А, прости

@ianlancetaylor С этой CL я все еще не могу собрать golang.org/x/net/internal/socket для Solaris. Из ошибки мне не очевидно, какие флаги мне нужно запрашивать.

$ ./bin/go version
go version devel +09dc376990 Tue Feb 13 20:58:04 2018 -0800 darwin/amd64
$ GOOS=solaris ./bin/go get -u golang.org/x/net/ipv4
# golang.org/x/net/internal/socket
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:24:3: //go:cgo_import_dynamic libc___xnet_getsockopt __xnet_getsockopt "libsocket.so" only allowed in cgo-generated code
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:25:3: //go:cgo_import_dynamic libc_setsockopt setsockopt "libsocket.so" only allowed in cgo-generated code
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:26:3: //go:cgo_import_dynamic libc___xnet_recvmsg __xnet_recvmsg "libsocket.so" only allowed in cgo-generated code
../../ext/src/golang.org/x/net/internal/socket/sys_solaris.go:27:3: //go:cgo_import_dynamic libc___xnet_sendmsg __xnet_sendmsg "libsocket.so" only allowed in cgo-generated code

@calmh Да. Я думаю, нам придется исправить это, изменив golang.org/x/net. Он уже опирается на многие внутренние детали, и я думаю, что нам нужно изменить то, как он это делает.

@calmh Сможете ли вы протестировать https://golang.org/cl/94015 на реальной системе Solaris?

Изменение https://golang.org/cl/94015 упоминает эту проблему: internal/socket: rework Solaris reliance on syscall package

@rsc @ianlancetaylor @anacrolix Я выяснил, откуда -Wl,-framework : он исходит из файла pkg-config для GLib, который является зависимостью GTK +. В частности, он включает ссылку CoreFoundation для целей интернационализации.

Конкретные ссылки: https://gitlab.gnome.org/GNOME/glib/blob/master/glib-2.0.pc.in#L14, где @INTLLIBS@ получает -Wl,-framework -Wl,CoreFoundation из https: // gitlab .gnome.org / GNOME / glib / blob / master / m4macros / glib-gettext.m4 # L143

В других файлах pkg-config есть и другие экземпляры -Wl,-framework ; некоторые из них являются частью самих проектов (как указано выше), а некоторые внедряются Homebrew. В моей системе сейчас я вижу, что libcdio и SDL используют -Wl,-framework,FrameworkName . (Это означает, что да, и -Wl,-framework -Wl,FrameworkName и -Wl,-framework,FrameworkName находятся в файлах pkg-config. Иди разберись.)

Изменение https://golang.org/cl/94018 упоминает эту проблему: cmd/compile: permit go:cgo_import_dynamic anywhere

@calmh Попробуйте другой подход на https://golang.org/cl/94018.

@andlabs Спасибо, добавил в CL 93836.

Я статически связываю SDL, и pgkconfig содержит -Wl,--no-undefined а также определения препроцессора.

Мне нужно, чтобы вы добавили флаги под белым списком, чтобы они могли компилировать проекты, использующие пакет cgoemitter.

go build github.com/supermock/cgoemitter-demo/x: недопустимый флаг в #cgo LDFLAGS: -Wl, -unresolved-symbols = ignore-all

заранее большое спасибо

Снова обновите CL.

Я добавил страницу вики для описания этой проблемы на https://golang.org/wiki/InvalidFlag , и я обновляю CL, чтобы сообщение об ошибке указывало людям на вики.

Изменение https://golang.org/cl/94158 упоминает эту проблему: doc: add note about invalid flag errors to 1.10 release notes

invalid flag in #cgo LDFLAGS: -O3

Изменение https://golang.org/cl/94655 упоминает эту проблему: [release-branch.go1.10] doc: add note about invalid flag errors to 1.10 release notes

Изменение https://golang.org/cl/94675 упоминает эту проблему: [release-branch.go1.10] cmd/compile: permit go:cgo_import_dynamic anywhere

Изменение https://golang.org/cl/94676 упоминает эту проблему: [release-branch.go1.10] cmd/go: add options to security whitelist

Также возникает эта проблема, если можно добавить следующее

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

@ bgk - ​​Патч, который был применен, обращается к этому. Если обновление до 1.10 сейчас невозможно, я бы посоветовал подождать, чтобы увидеть, произойдет ли 1.9.5.

Следует ли в 1.10 устранить проблему invalid pkg-config package name: --static ? Я только что скинул последнюю версию с homebrew и все еще вижу:

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

@ ptoomey3 См. № 23875

Повторное открытие для 1.9.5.

Я буду избегать проблемы XY и лучше объясню полностью, что я делаю. Я создаю расширение postgresql вместе с -buildmode=c-shared .

В документации по созданию расширений C для postgresql описан способ создания общего объекта:

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

Итак, я добавил #cgo LDFLAGS: -shared в свой исходный код. Он работал до недавнего времени (go1.10), когда он прекратил сборку с:

invalid flag in #cgo LDFLAGS: -shared

Просто схватил go 1.10, наткнулся на это:

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

Это флаг компоновщика gcc для принудительного статического связывания чего-либо после этой опции в строке ссылки.

@spackard Для записи, этот параметр означает не это. Вы думаете о -Bstatic . Параметр -static указывает компоновщику не искать какие-либо разделяемые библиотеки, чтобы удовлетворить любые параметры -l . -static не является позиционным вариантом; не имеет значения, где он отображается в командной строке.

@ianlancetaylor Вы правы насчет позиции. Это то, как мы заставляем статическое связывание в любом случае. Для записи, добавление его в CGO_LDFLAGS_ALLOW действительно работает.

У меня такая же проблема

invalid flag in #cgo CFLAGS: -m32

Мы достигли этого с помощью -O3, -static-libgcc и -static-libstdc ++

-O3:

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

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

cgo CFLAGS: -O3

недопустимый флаг в #cgo LDFLAGS: -O3

-статический-libgcc:

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

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

недопустимый флаг в #cgo LDFLAGS: -static-libgcc

-статическая-libstdc ++:

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

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

недопустимый флаг в #cgo LDFLAGS: -static-libstdc ++

использование жестко запрограммированных статических белых списков - плохая идея, возможно, нам следует использовать файл конфигурации с некоторыми настройками по умолчанию, такими как

$ GOROOT / bin / cgo.cfg
[белые списки]
блаблабла
...

так что мы можем сделать некоторые настройки

@kruglinski Вы можете настроить, используя переменную среды CGO_CFLAGS_ALLOW и друзей.

@ianlancetaylor

Извините, я просто пропустил это, :-) Полезно знать, многие думают!

24124 сообщает о следующей опции компоновщика:

-Wl,-z,relro

Параметр компоновщика -Wl,--subsystem,windows и параметр компилятора -mwindows отсутствуют.

Я пытаюсь заставить gomobile / gobind генерировать автономные привязки. Некоторые из этих работ включают преобразование переменных окружения CGO_ * FLAGS в директивы #cgo, в результате чего обнаружено еще несколько флагов:

`` ''
-isysroot(iOS)
-mios-simulator-version-min =(iOS)
-miphoneos-version-min =(iOS)

-цель(для android)
--sroot(для android)
-gcc-toolchain(для android)
`` ''

Я считаю, что все, кроме последнего, -gcc-toolchain, можно безопасно добавить в белый список.

Следующие флаги необходимы для создания привязок Go для игрового движка Godot без CGO_LDFLAGS_ALLOW в macOS:

-Wl,-undefined,dynamic_lookup

Еще CFLAGS от zchee / libhyperkit :

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

v8worker требуется -stdlib=libstdc++ в Mac OS X.

CL 103156 подходит для Go 1.9.5

Изменение https://golang.org/cl/103135 упоминает эту проблему: [release-branch.go1.9] cmd/go: add options to security whitelist

Я не видел его в списке, может ли libtool также быть внесен в белый список

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

@PassKit -I - это cflag (который находится в списке), а не ldflag, почему вы помещаете его в ldflags?

Повторное открытие для сбора дополнительных запросов в белый список.

С № 24703

CFLAGS: -fno-plt

На данный момент я думаю, что это нормально, если мы будем обновлять ветки выпуска 1.9 и 1.10 только в том случае, если какой-то популярный пакет не будет создан, и об этом почему-то еще не сообщалось. Я не думаю, что нам нужно постоянно копировать каждый случайный вариант. Мы можем просто добавить их в чаевые по версии 1.11. Отслеживаем ли мы их в этом выпуске или где-то еще, меня не волнует.

SGTM

@AlexRouSg Моя проблема была связана с этой библиотекой, которая рекомендовала добавить «-I» в белый список в качестве ldflag, который я сейчас использую в качестве обходного пути. https://github.com/miekg/pkcs11/issues/63

Извините за опоздание, но было бы здорово, если бы они были внесены в белый список в 1.9.5 или 1.10.2.

CXXFLAGS: -F/Users/user/Qt/5.10.1/clang_64/lib
CFLAGS: --sysroot=/Users/user/android-ndk-r14b/sysroot
CFLAGS: -mfloat-abi=softfp
CFLAGS: -fno-builtin-memmove
CFLAGS: -mthumb
CFLAGS: -fobjc-nonfragile-abi
CFLAGS: -fobjc-legacy-dispatch
CFLAGS: -fno-keep-inline-dllexport
CXXFLAGS: -mthreads
CFLAGS: -Wp,-D_FORTIFY_SOURCE=2
CFLAGS: --param=ssp-buffer-size=4
CFLAGS: -mfloat-abi=hard
CFLAGS: -fvisibility-inlines-hidden
CFLAGS: -mfpmath=sse
CFLAGS: -fasynchronous-unwind-tables
CFLAGS: -feliminate-unused-debug-types
CFLAGS: -marm
CFLAGS: -mabi=aapcs-linux
CFLAGS: -mthumb-interwork

а также

LDFLAGS: -headerpad_max_install_names
LDFLAGS: -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
LDFLAGS: -Wl,-rpath,@executable_path/Frameworks
LDFLAGS: --sysroot=/Users/user/android-ndk-r14b/platforms/android-16/arch-arm/
LDFLAGS: -Wl,-rpath-link=/Users/user/Qt/5.10.1/android_armv7/lib
LDFLAGS: -Wl,--allow-shlib-undefined
LDFLAGS: -Wl,-e,_qt_main_wrapper
LDFLAGS: -Wl,-O1
LDFLAGS: -Wl,-rpath-link,/opt/Qt/5.10.0/gcc_64/lib
LDFLAGS: -Wl,-s
LDFLAGS: -Wl,-subsystem,console
LDFLAGS: -mthreads
LDFLAGS: -rdynamic
LDFLAGS: -mfloat-abi=hard

Заранее спасибо.

@therecipe Мы можем добавить их в 1.11. Но для 1.9.5 или 1.10.2: для каких пакетов они нужны?

@ianlancetaylor Все это необходимо для разных целей https://github.com/therecipe/qt
Ничего страшного, если вы не будете заносить их в белый список сразу, но, пожалуйста, дайте мне знать, о каком из них мне нужно будет позаботиться самому.

Я собираюсь предположить, что это их собственный пакет Qt, который, как я знаю, достаточно стар, чтобы быть хорошо установленным; Я не полностью уверен , если это (кто - то еще нужно будет говорить).

Что, как говорится:

• Разве некоторые из LDFLAGS уже не внесены в белый список без префикса -Wl, ?
• -e влияет на Go?
• Разве -F уже не было в белом списке? Оказывается, это вариант, о котором я говорил выше .
• (К @therecipe) Почему вы охраняете -D с помощью -Wp ? Есть ли причина определять макрос, но только в препроцессоре? Я не знаю, что здесь делает voodoo Qt ... Или это рекомендуемый список опций, предоставляемых самой Qt?
• (Обращается к @ianlancetaylor) Я могу понять, что не выполняю резервное копирование новых параметров в 1.9 (я неоднозначно отношусь к этому вопросу, потому что у меня нет показателей использования версии Go), но почему не 1.10, пока не будет выпущена 1.12?
• Независимо от ответа на вышесказанное, мне интересно, стоит ли делать резервную копию перечисленных там параметров ARM ABI ...

@andlabs Только потому, что нам нужно когда-нибудь остановиться, так почему бы не остановиться сейчас? Но я в порядке, если продолжу делать бэкпорт патчей, если это кажется достаточно полезным.

@andlabs Да, это все рекомендуемые флаги. Я сам не добавлял ни одного из них вручную.
-Wp,-D_FORTIFY_SOURCE=2 было от цели iirc парусной рыбы, я не знаю, почему они это сделали.

@therecipe в этом случае, где Qt и Sailfish делают эти предложения (то есть есть ли веб-страница или инструмент командной строки, который дает их вам)? Мне сейчас любопытно.

Тем временем, пока команда Go обращается к этому списку, мне все еще интересно, сколько из ваших предупреждений LDFLAGS исчезнет, ​​если вы удалите префиксы -Wl, ; попробуй и увидишь? То же самое для префикса -Wp, в одном CFLAGS . Я не знаю, окажет ли это неблагоприятное влияние на сборку, но в идеальном мире этого не должно быть, потому что для этого нужен LDFLAGS ... (Вам также придется заменить запятые на пробелы. Эти -Wx, основном сообщают gcc и clang отправлять аргументы непосредственно компоновщику (или ассемблеру или препроцессору) вместо того, чтобы обрабатывать их сами; если я правильно угадаю, идея заключается в параметрах, специфичных для ОС, которые еще не предоставлены gcc и лязгает прямо, но точно не знаю ...)

@andlabs Да, один из инструментов сборки Qt qmake потребляет *.pro , *.spec (mkspec), *.conf и множество других форматов для создания обычных файлов Makefile. Я просто скармливаю ему несколько фиктивных файлов *.pro и извлекаю флаги из файлов Makefile. Таким образом, мне действительно не нужно самостоятельно разрешать зависимости, процесс сборки может работать проще со сторонними библиотеками, мне не нужно вручную управлять флагами c или ld и непроверенными целями или более новыми / старыми версиями Qt. в большинстве случаев прямо из коробки. Иногда мне приходится заносить в черный список некоторые флаги, которые вызывают проблемы, но это очень редко.

Я попытался найти парусник mkspec, который тянет за собой -Wp,-D_FORTIFY_SOURCE=2 , но он, вероятно, похоронен где-то в mersdk или около того. Но вот официальный список целей, для которых TQtC поддерживает: https://github.com/qt/qtbase/tree/5.11/mkspecs, и есть много неофициальных, поддерживаемых независимыми сторонами. Вот почему я действительно не хочу возиться с флагами вручную.

Я могу внести их в белый список в инструменте сборки, используемом привязкой (который обертывает go ), но обычный пользователь Go, который просто хочет использовать go build ... , рано или поздно поднимет проблему .. . (по крайней мере, для настольных компьютеров)

-ffast-math

Официальный клиентский драйвер SAP HANA (разделяемая библиотека на основе cgo) поставляется с #cgo LDFLAGS: -Wl,-rpath -Wl,\$ORIGIN что приводит к go build SAP/go-hdb/driver: invalid flag in #cgo LDFLAGS: -Wl,-rpath . Также см. Документацию SAP по адресу https://help.sap.com/viewer/0eec0d68141541d1b07893a39944924e/2.0.03/en-US/fba20e31f75c4f7ca5629083869069e5.html?q=golang%20driver .

@cbgo см. # 23672

Код, который передает пару флага и аргумента компоновщику, теперь должен использовать один флаг -Wl вместо двух: используйте #cgo LDFLAGS: -Wl, -rpath, $ ORIGIN, а не #cgo LDFLAGS: -Wl, -rpath -Wl, $ ИСТОЧНИК.

@AlexRouSg большое спасибо. Я должен был прочитать это более внимательно :-)

@PassKit Вы решили эту проблему？

@ zcm211 Если вы говорите о https://github.com/miekg/pkcs11, они удалили флаг компоновщика -I... в feb. Если вы используете пакет, который его использует, вам необходимо установить переменную окружения CGO_LDFLAGS_ALLOW="-I.*"

darwin 64-bit, go1.10.2, я думал, что файлы .o внесены в белый список для LDFLAG, но получаю:
~jaten @ jatens-MacBook-Pro ~ / go / src / github.com / go-интерпретатор / chezgo (мастер) $ make runcd chez_scheme_9.5.1 / c;








из-за преамбулы cgo в https://github.com/go-interpreter/chezgo/blob/master/embed.go#L10
~~~

cgo LDFLAGS: -liconv -lm -lncurses -L / usr / local / lib ./chez_scheme_9.5.1/boot/a6osx/kernel.o

~~~

@glycerine Согласно https://go-review.googlesource.com/c/go/+/94676 они есть. Может, попробовать полный путь вместо относительного?

Хорошая уловка @AlexRouSg , регулярное выражение accept содержит ошибки, как вы указываете;
~re ( [a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so) ), // прямые входы компоновщика: xo или libfoo.so (но не -foo.o или @ foo.o)~
src / cmd / go / internal / work / security.go # 121 должен разрешить .o files начинаться с . для поддержки относительных путей.

В конце концов, я не могу предсказать GOPATH пользователей или то, насколько вложенным станет расположение этого файла, поэтому установка абсолютного пути нецелесообразна.

Находится ли файл .o в исходном каталоге? Если да, то ссылка на исходный каталог - это то, для чего был предоставлен ${SRCDIR} . (Я специально забываю, почему это было введено, но это было не из-за этой проблемы.)

@andlabs Даже если есть klunky обходные пути, относительные пути должны быть связаны, и это явно ошибка.

Это так, за исключением IIRC, нет гарантии, что ссылка будет относительной к исходному каталогу (она вполне может быть в $WORK , а затем ваш относительный путь снова прервется) ... Опять же, я забыл история; кому-то еще нужно будет объяснить.

gtk4 использует -mfpmath = sse

@ianlancetaylor Должен ли быть только один список вместо отдельных белых списков для cflags и ldflags? gcc / llvm, похоже, не заботится о том, чтобы вы смешивали ldflags с cflags и наоборот. И кажется, что иногда разработчики C делают это, вызывая такие проблемы, как # 25493 или https://github.com/golang/go/issues/23749#issuecomment -379969818

А, я вижу, у нас уже есть билет, поэтому позвольте мне упомянуть "-D_THREAD_SAFE" из protobuf, как описано в # 25493

Изменение https://golang.org/cl/115415 упоминает эту проблему: cmd/go: accept more safe CFLAGS/LDFLAGS

Изменение https://golang.org/cl/115435 упоминает эту проблему: [release-branch.go1.10] cmd/go: accept more safe CFLAGS/LDFLAGS

Изменение https://golang.org/cl/115436 упоминает эту проблему: [release-branch.go1.9] cmd/go: accept more safe CFLAGS/LDFLAGS

Эй, ребята,
Почему эта проблема закрыта, если мы по-прежнему не можем собрать bimg с последней версией Go по состоянию на 4 сентября 2018 г.?
См. Проблему: https://github.com/h2non/bimg/issues/230
Мы не можем создать ничего, что импортирует bimg начиная с Go 1.10, и проблема все еще сохраняется в Go 1.11.
Мы получаем следующее сообщение об ошибке:

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

Какой-нибудь совет?

РЕДАКТИРОВАТЬ:
Я создал новую проблему: https://github.com/golang/go/issues/27496

Я считаю, что этот белый список отвечает за следующее: https://github.com/alexflint/gallium/issues/63

@alexflint Эта проблема закрыта, создайте новую