Добрый день. Бьюсь уже неделю, не могу заставить работать тестовую внешнюю компоненту с ИТС.- "AddInNative"
По идеологическим соображениям отказался от использования MSVC и решил собрать компоненту с помощью MinGW (gcc).
Первое с чем я столкнулся это отсутствие возможности сгенерить Makefile из CMakeLists.txt. Т.к. разработчики предусмотрели сборку только либо с помощью msvc, либо с помощью gcc (linux only). Когда я вручную доработал cmakelists.txt файл , то в последствии пришлось еще править и исходники компоненты, т.к. началась "свистопляска" с дефайнами в хедерах. Это я тоже победил. Компонента собралась но потащила с собой эти файлы:
libgcc_s_dw2-1.dll
libstdc++-6.dll
libwinpthread-1.dll
В итоге пришло осознание того, что 1С умеет работать только со standalone файлами плагинов и не видит эти .dll даже если они лежат в той же папке откуда грузится компонента. Т.е. нужно было все это компилировать статически в один файл. К сожалению "заставить" стандартную сборку MinGW залинковать статически библиотеки не удалось. Скачал в итоге сборку TDM-GCC, снова пришлось под неё править исходники компоненты, т.к. эта сборка не знает ничего о некоторых чисто msvcr функциях. Все-таки dll собралась статически. Но при вызове ПодключитьВнешнююКомпоненту() грохает клиент с исключением.
В связи с чем прошу поделиться вас своим опытом по сборке и линковке внешних компонентов, которые имеют зависимости от других .dll и собираются не только с помощью msvc, у которого синтаксис С++ может радикально отличаться от gcc.
(1)
Приветствую Вас, коллеги! Уже месяц потратил на этот пример Native API, и тоже не нашел решения. Я добавил во все методы компоненты отладочный код, который выводит записи в лог-файл и вот что я получил:
2023-04-25 19:43:17 DLLMain()
2023-04-25 19:43:17 GetClassNames() - begin
2023-04-25 19:43:17 GetClassNames() - end: will retun CAddInNative
2023-04-25 19:43:17 DLLMain()
2023-04-25 19:43:17 DLLMain()
2023-04-25 19:43:17 GetClassObject("CAddInNative", &(0000000000000000)) - begin
2023-04-25 19:43:17 GetClassObject(): entered statement if(!*pInterface) {}
2023-04-25 19:43:17 CAddInNative::CAddInNative() - begin
2023-04-25 19:43:17 CAddInNative::CAddInNative() - end
2023-04-25 19:43:17 GetClassObject() - end: will return 00000000517c4070
2023-04-25 19:43:17 SetPlatformCapabilities(1) - begin
2023-04-25 19:43:17 SetPlatformCapabilities() - end: will return 3
2023-04-25 19:43:17 CAddInNative::~CAddInNative()
И все, на этом 1С падает. Остальные методы она не вызывает, или не может вызвать.
Потом, на всякий случай, доработал SetPlatformCapabilities() чтобы он возвращал 1, бесполезно, то же самое.
Остается подозрение, что MinGW в неправильном порядке строит таблицу методов интерфейсов. Обратите внимание, ни один метод ни одного интерфейса не был вызван.
Я использовал 64- и 32-разрядные MinGW:
winlibs-x86_64-posix-seh-gcc-12.2.0-llvm-15.0.7-mingw-w64ucrt-10.0.0-r4
winlibs-i686-posix-dwarf-gcc-12.2.0-mingw-w64ucrt-10.0.0-r4
Еще бы дизассемблером уметь пользоваться. А вообще лучше будет получить ответ от разработчиков 1С, есть ли такой форум?
Подружить 1С с MinGW будет сложно или невозможно. Я думал может хоть есть какой пример внешней компоненты на чистом Си. Но нет, зачем-то 1С потребовалось использовать классы.