Чем нынче модно редактировать & конпелять dll-ку для софтины, работающей под wine?

vs code

Интересует нормальный IDE

Любой, который умеет в нужную тебе систему сборки (make/ninja/cmake/meson)

и тулчейн

https://mxe.cc/ либо посмотри mingw у себя в репах, но MXE значительно удобнее за счет большого числа пакетов и gcc 10.2 c поддержкой потоков и filesystem

хз насколько vs code можно называть IDE в целом и нормальной плюсовой IDE в частности, но вот. Мне на потыкать хватало более чем.

Для нормальной нормальности нужно докинуть плагин, инструкция по настройке - https://code.visualstudio.com/docs/languages/cpp

Geany с плагином Project Manager. Существует под Linux и винду.

IDE не нужны, для всего есть консоль и vim

Lazarus, Netbeans IDE.

насчёт редактировать не скажу, IDE не пользую, а конпелять именно под wine можно посредством winegcc. Оно позволяет даже использовать вперемешку линуксячьи либы и вендовые dll.

mingw вроде использовали на работе, хотя он своеобразный. Насчёт IDE не знаю, моя IDE выбора сейчас - VSCode, но я не сишник вовсе. Наш сишник использует QtCreator ЕМНИП.

пока не понадобится дебагер и не зае 10050 сочетаний клавиш в голове держать

у gdb есть TUI

ты прекрасно пониманшь насколько неудобно пользоваться всем этим добром. я пользуюсь vim для правки конфигов на хосте и сервере, но разработку на нем вести боль. не давай вредные советы человеку, пусть поставит vscode с кучей плагинов и тем, а не сидит месяц свой идеальный .vimrc пишет

мне и с дефолтным .vimrc норм

winegcc

Идея хорошая, но чёт у меня в мою DLL-ку не линкуется другая DDL-ка (а именно lua53.dll, идущая в составе той прилаги, к которой я свою DLL-ку прикручиваю). И хрен найдёшь как правильно. Единственная ссылка на инструкцию (найденная здесь, в нижнем каменте) – битая. Эти рецепты тоже не работают.

LoadLibrary – не вариант сразу по нескольким причинам: моя DLL будет как раз из lua вызываться, как бы не вышло что я к другому экземпляру DLL буду обращаться; include windows.h выплёвывает кучу синтаксических ошибок (даже если завернуть в extern «C»); и вообще LoadLibrary это в данном случае дикий костыль.

По найденным инструкциям:

«winedump spec lua35.dll» – генерит простыню, в которой все строки stub. Хз, может так и надо. Кстати, если ему подсунуть параметр -I, то grep будет ругаться на некорректные параметры на каждую функцию: «character class syntax is [[:space:]], not [:space:]».

Затем «winebuild –def -E lua53.spec -o lua53.def» – генерирует соответствующую кучу записей в EXPORTS, но все PRIVATE. Опять же хз, может так и надо.

А затем что делать – я вообще хз. Как должна выглядеть командная строка линковки моей DLL? Там вообще winegcc должен вызываться или снова winebuild? (Что это за дичь про .spec, .def и т.п. – я уж и гуглить боюсь. Развели бардак… А ведь когда-то писал под венду…)

Вот архивчег с минимальным примером: http://dimgel.me/drop/windows-dll-link-failed.zip

Памажите люди добрыя?

Переименовал lua53.dll,def в liblua53, параметры линковки winegcc прописал «-L./lib -llua53» – и собралось. Но собралась линуксявая hello.dll.so (ELF), и виндузявая lua её не цепляет. :(

У меня в Makefile для моей libusb-wine такое:

PROJ = libusb0
WINEGCC = winegcc
WINEBUILD = winebuild
LDFLAGS =

$(PROJ).dll.so $(PROJ).dll.fake: $(PROJ).spec $(OBJS)
        $(WINEGCC) -o $@ -B$(WINEBUILD) -fasynchronous-unwind-tables -shared $(PROJ).spec $(OBJS) $(LDFLAGS)

Файл libusb0.spec выглядит примерно так:

@ cdecl usb_open                       (ptr)
@ cdecl usb_close                      (ptr)
@ cdecl usb_get_string                 (ptr long long str long)
@ cdecl usb_get_string_simple          (ptr long str long)
@ cdecl usb_get_descriptor_by_endpoint (ptr long long long ptr long)
...

Т.е. там функции экспортируемые перечислены с параметрами.

libusb0.dll.fake при установке переименовать в libusb0.dll

Чтобы линковать именно с вендовыми dll, надо иметь соответствующий .a Его можно получить натравив на dll gendef, получится .def со списком экспортов, а потом на .def и .dll надо натравить dlltool типа

dlltool -d libxyz.def -D libxyz.dll -l libxyz.a

Но если собирается именно под wine - то можно линковать же с линуксячьими системными .so

Решилось втыканием полноценного MinGW – сначала на винду в виртуалке, потом на генту (не без геморроя, но гораздо проще, чем я боялся, начитавшись на форумах страшных простыней). Плюс нашёл-таки нормальное чтиво (с продолжением и github-репой).

Может ещё попробую как-нибудь вернуться на winegcc, но пока что с меня экспериментов хватит.

Чтобы линковать именно с вендовыми dll, надо иметь соответствующий .a

Кстати по приведённым мною ссылкам (а может и по другим каким-нибудь) чел пишет, .a нужен для MSVC, а GCC-шный линкер (т.е. MinGW) умеет всё что ему нужно прямо из DLL-файла выковыривать (как собственно и оказалось; так что все ранее нагугленные пляски вокруг генерации .spec и .def файлов – полностью мимо).

winegcc он только для wine. MinGW, конечно, гораздо более универсальная штука.

Это понятно. Но man winegcc пишет «MinGW Compatible», так что может оно и в wingw-шной манере юзаеццо. Опять же, поскольку это gcc, ему тоже .a по идее должен быть без надобности.

GCC-шный линкер (т.е. MinGW) умеет всё что ему нужно прямо из DLL-файла выковыривать

Это если в DLL экспортируются по нормальным именам, а не по ordinal, например. Тогда да, может.

Трындец винда говно корявое. Напомнило: «If there are two different ways of doing something, PSD will do both, in different places. It will then make up three more ways no sane human would think of, and do those too.»

Используй Code::Blocks со встроенным mingw из под wine.

Code::Blocks не нужен: у меня в генте родимый QtCreator, а теперь ещё и нативный MinGW.

Vscode, mingw

OK.JPG

:)

Я тут нарисовал прекрасный makefile, который DLL-ку компиляет под винду, а юнит-тесты собирает системным виндузячьим gcc. Под wine такое не запилишь.

mingw32-make.exe

А запускать собранные тесты – тоже под wine? И нахрена козе баян, спрашивается?

разве у wine нет нативного gcc?

https://linux.die.net/man/1/winegcc

Ты сам спрашивал под вайн.