Ошибка:
x86_64-w64-mingw32-gcc blackwhitelist.o dnsredir.o fakepackets.o goodbyedpi.o service.o ttltrack.o utils/getline.o utils/repl_str.o goodbyedpi-rc.o -fstack-protector -Wl,-O1,-pie,--dynamicbase,--nxcompat,--sort-common,--as-needed -Wl,--disable-auto-image-base -Wl,--high-entropy-va -Wl,--pic-executable,-e,mainCRTStartup -L../WinDivert-2.2.0-D/x64 -lWinDivert -lws2_32 -l:libssp.a -s -o goodbyedpi.exe
/usr/lib/mingw64-toolchain/lib/gcc/x86_64-w64-mingw32/14/../../../../x86_64-w64-mingw32/bin/ld: cannot find -l:libssp.a: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:56: goodbyedpi.exe] Error 1
Контекст ошибки:
Настроила я себе походный телефончик для беспроводного доступа: интернет принимает по вайфаю, блютузу через туннель, и 5G от йоты. Публичные сети игнорирует, скрытые SSID находит, простые пароли сам подбирает, а сложные - слушает эфир и, если повезёт, отправляет серверу с P100 на анализы. Пакеты пересылает, обфусцирует, себя как хоп не выдаёт, под ситуацию подстраивается - всё работает стабильно, без нареканий.
Места на карте памяти ещё предостаточно, веб-сервер наполняю нужными в современном быту файлами. Захотелось добавить и GoodbyeDPI на крайний случай, если придётся с маздайного устройства в сеть мирную выходить, потеряв телефон.
Релизы готовые скачивать не хочу и не буду: не то чтобы авторов не уважала, просто софт - дело пикантное, тем более такой как тут. Скачанный блоб не лучше неизвестного исполнимого файла.
Формирование релизов не автоматизировано, единственный способ проверки - сравнение с артефактами от build.yml, что неудобно. У меня свои списки хостов и скрипты, так что достаточно лишь собрать исполняемый goodbyedpi.exe под x86_64 (можно и под x86, чем чёрт не шутит), и дело сделано.
Но вот незадача, при компиляции вылетает ошибка вышеуказанная, и ничего не работает.
На телефоне стоит Gentoo свежая ~arm64 на 23.0 профиле без musl, со всех сторон обновлённая, ssp USE-флаг поднят. С ним и sys-devel/gcc, и sys-libs/glibc собраны. Компилирую с использованием dev-util/mingw64-toolchain, у которого внутри gcc v14.1.0. Ядро разве что старовато, но оно от Андройда, и не влияет здесь ни на что.
Что было сделано:
Смена на -lssp тоже не помогает: разница лишь в том, что компилятор cannot find -lssp молвит.
Проблема чинится убиранием libssp с корнем из Makefile, то бишь примерно вот так:
diff --git a/src/Makefile b/src/Makefile
index 015490e..2038e86 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -7,9 +7,7 @@ WINDIVERTLIBS = ../../binary
MINGWLIB = /usr/x86_64-w64-mingw32/lib/
TARGET = goodbyedpi.exe
-# Linking SSP does not work for some reason, the executable doesn't start.
-#LIBS = -L$(WINDIVERTLIBS) -Wl,-Bstatic -lssp -Wl,-Bdynamic -lWinDivert -lws2_32
-LIBS = -L$(WINDIVERTLIBS) -lWinDivert -lws2_32 -l:libssp.a
+LIBS = -L$(WINDIVERTLIBS) -lWinDivert -lws2_32
CC = $(CPREFIX)gcc
CCWINDRES = $(CPREFIX)windres
@@ -25,7 +23,7 @@ CFLAGS = -std=c99 -pie -fPIE -pipe -I$(WINDIVERTHEADERS) -L$(WINDIVERTLIBS) \
-Wstringop-overflow=4 \
-Wformat-signedness -Wstrict-overflow=2 -Wcast-align=strict \
-Wfloat-equal -Wcast-align -Wsign-conversion \
- #-fstack-protector-strong
+ -fstack-protector-strong
LDFLAGS = -fstack-protector -Wl,-O1,-pie,--dynamicbase,--nxcompat,--sort-common,--as-needed \
-Wl,--disable-auto-image-base
После такой заплатки программка собирается как надо и работает исправно, без сучка и задоринки. Применять её при каждой пересборке проблемы не составляет, но хочется ведь по стариковской привычке разобраться, в чём же здесь закавыка и как её решить раз и навсегда.
Применить такой финт ушами по умолчанию, как я поняла из комментария в этом самом Makefile, вариантом не является: скомпилироваться-то программка скомпилируется, но опосля запуститься откажется по причине отсутствия внешней libssp, которой по умолчанию, как и всего остального уважаемым людям необходимого, в маздае нет.
Думаю я, что можно как-то определять наличие libssp перед компиляцией, например, по наличию отсутствия --disable-libssp флага сборки компилятора, но нет никакой уверенности, что будет такое решение надёжным, или правильным самым.
Поэтому и спрашиваю здесь, может, кто разбирается лучше: нужен ли тут вообще stack-protector, и можно ли как-то грамотно проблему эту обойти? Заранее спасибо!