LINUX.ORG.RU

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

 , ,


0

2

Всем привет. Сабж. Интересует нормальный IDE (vim не предлагать) и тулчейн, чтобы сидеть либо на онтопике, либо также внутри wine. Кодировка сорцов – cp1251.

★★★

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

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

и тулчейн

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

SR_team ★★★★★ ()
Последнее исправление: SR_team (всего исправлений: 1)

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

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

Ford_Focus ★★★★★ ()
Последнее исправление: Ford_Focus (всего исправлений: 2)
Ответ на: комментарий от Stanson

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

den73 ★★★★★ ()
Ответ на: комментарий от Harald

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

tz4678 ★★ ()
Ответ на: комментарий от Stanson

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

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

dimgel ★★★ ()
Ответ на: комментарий от dimgel

У меня в 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

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

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

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

dimgel ★★★ ()
Ответ на: комментарий от Stanson

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

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

dimgel ★★★ ()
Ответ на: комментарий от Stanson

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

dimgel ★★★ ()
Ответ на: комментарий от dimgel

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

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

Stanson ★★★★★ ()