Как скомпилировать gcc dll

Большинство оставшихся параметров используются для указания вариантов библиотеки времени выполнения, как описано в рецепте 1.23.

Мне было интересно, как мне скомпилировать DLL с помощью gcc? Ну, я использую порт gcc для Windows. Как только я скомпилирую .dll, содержащую мои классы и функции, как мне связать ее с моей программой? Как использовать классы и функции в DLL? Может ли функция вызова DLL из связывающейся с ней программы? Если я сделаю класс < . >объект; в DLL, то когда DLL загружается программой, будет ли объект доступен для программы? Заранее спасибо, мне действительно нужно знать, как работать с DLL в C++, прежде чем я смогу продолжить этот проект.

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

Я думал, что схема объясняет это. программа, использующая DLL, передает фрагмент кода в DLL, которая анализирует код, и если в указанном коде обнаружены вызовы функций, то вызываются соответствующие функции в DLL. например, если бы я передал "a = sqrt(100)", то функция синтаксического анализатора DLL нашла бы вызов функции sqrt(), а внутри DLL была бы соответствующая функция sqrt(), которая вычисляла бы квадратный корень из аргумента передается ему, а затем он берет возвращаемое значение из этой функции и помещает его в переменную a. точно так же, как и любая другая программа, но если соответствующий обработчик для функции sqrt() не найден в DLL (был бы список изначально поддерживаемых функций), тогда она вызовет аналогичную функцию, которая будет находиться в программе с использованием DLL, чтобы увидеть, есть ли какие-либо пользовательские функции с таким именем.

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

Эта статья покажет вам основы создания библиотек DLL с помощью MinGW, а затем связывания с ними в ваших приложениях. Создаваемый здесь код можно будет использовать и в MSVC, поэтому вы или ваши конечные пользователи сможете использовать несколько компиляторов.

Основы DLL

DLL — это тип общей библиотеки, используемой в Microsoft Windows и OS/2, содержащей функции, которые можно повторно использовать в любом приложении, которое хочет их использовать (на самом деле библиотеки DLL могут содержать гораздо больше, чем просто функции, но эта статья о создании библиотек функций). Если у вас есть библиотека foo.dll, которая содержит функцию DoWork() , DLL должна экспортировать эту функцию, чтобы ее можно было использовать в приложениях. Аналогично, если приложение bar.exe хочет использовать функцию DoWork() , он должен импортировать эту функцию из foo.dll (также можно написать код, который загружает DLL, как только приложение запустилось, вызывает функции из этой DLL, а затем выгружает DLL, когда она больше не нужна — так обычно работают системы плагинов/аддонов). Экспорт и импорт функций довольно прост и требует небольшого количества кода, сопровождаемого правильной командной строкой компоновщика.

Негибкий и неэлегантный способ

Сначала мы создадим DLL, экспортирующую только очень простую функцию, которая складывает два целых числа и возвращает результат. Обратите внимание на атрибут « __declspec(dllexport) » в приведенном ниже коде — это ключ к экспорту функций из DLL, и каждая функция, которую вы хотите экспортировать из DLL, должна быть помечена этим атрибутом (любые внутренние функции, которые не составляют часть вашего API следует оставить как есть). Также обратите внимание на « __cdecl » перед именем функции, который объявляет соглашение о вызовах для функции (см. статью в Википедии о соглашениях о вызовах x86, если вы с ними не знакомы). Соглашение о вызовах по умолчанию для функций C в MinGW — cdecl, но рекомендуется всегда явно указывать соглашение о вызовах на случай, если какой-то другой компилятор использует другое значение по умолчанию — если это произойдет, ваше приложение, скорее всего, будет работать некорректно. или сбой в результате вызова одной из этих функций. Обратите внимание, что этот первый пример намеренно негибкий и неэлегантный, чтобы точно показать, что происходит за кулисами. В следующем разделе мы будем скрывать эти детали с помощью определений препроцессора.

Чтобы скомпилировать это, просто необходимо передать опцию «-shared» в обычную командную строку компоновщика:

Никаких ошибок не должно быть сообщено, и теперь у вас должна быть пригодная для использования библиотека DLL. В этом примере я разделил этапы компиляции и компоновки, хотя для такого небольшого проекта это можно было бы сделать просто с помощью « gcc -o add_basic.dll -s -shared add_basic.c -Wl, --subsystem,windows ». «-Wl,--subsystem,windows» на самом деле не является необходимым, но просто общепринято, что библиотеки DLL имеют подсистему графического интерфейса Windows, указанную в их PE-заголовке. Также обратите внимание, что переключатель «-s» используется для удаления символов из DLL — вы, вероятно, захотите сделать это только для выпускных сборок.

Теперь вы можете создать приложение, использующее эту библиотеку DLL. Все, что необходимо для использования функции Add(a, b), — это объявить функцию с атрибутом «__declspec(dllimport)» перед ее использованием (обратите внимание, что это dllimport для клиентского приложения, в отличие от dllexport, используемого в нашей DLL).

Теперь вы можете скомпилировать и связать это приложение, просто сославшись на нашу DLL в командной строке компоновщика.

Параметр «-L» указывает дополнительную папку, в которой компоновщик должен искать библиотеку DLL. В этом случае мы хотим, чтобы компоновщик выполнял поиск в текущем каталоге, поэтому мы можем просто использовать точку, но для настоящей DLL, которую мы развернули в системе, мы будем использовать полный путь к ее каталогу. Параметр «-l» указывает DLL, из которой мы хотим импортировать функции — это должно быть имя файла DLL без расширения файла. Опять же, для такого небольшого проекта приложение можно было бы скомпилировать и слинковать, выполнив команду gcc -o addtest_basic.exe -s addtest_basic.c -L. -ladd_basic ”

Гибкий и элегантный способ

Обратите внимание, что мы определили «ADDAPI» как «__declspec(dllexport)», если определено «ADD_EXPORTS», или «__declspec(dllimport)» в противном случае. Именно это позволяет нам использовать один и тот же заголовок для приложений и DLL. Также обратите внимание, что мы определили «ADDCALL» как «__cdecl», что позволяет легко переопределить соглашение о вызовах, которое мы используем для нашего API. Теперь в любом месте нашего кода, где нам нужно экспортировать функцию из нашей DLL, мы указываем «ADDAPI» вместо атрибута «__declspec(dllexport)» и «ADDCALL» вместо указания, т. е. «__cdecl». Принято называть эти определения препроцессора «[имя библиотеки]_EXPORTS», «[имя библиотеки]API» и «[имя библиотеки]». ЗВОНИТЕ», поэтому рекомендуется придерживаться этого правила, чтобы ваш код был удобочитаемым для вас и других.

Помните, что этот код нельзя переносить, так как в нем используются атрибуты Microsoft. Здесь это нормально, потому что это руководство по созданию Windows DLL, но если вам нужна межплатформенная совместимость, то ADDAPI и ADDCALL можно определить условно. Обычно это делается так:

Код для DLL теперь может включать только что созданный заголовок, и единственное изменение, которое нам нужно сделать, это включить «ADDCALL» перед именем функции (здесь необходимо указать соглашение о вызовах, чтобы предотвратить возможные конфликты между объявление и определение функции).

Чтобы скомпилировать эту DLL, необходимо определить «ADD_EXPORTS» при компиляции объектного кода, чтобы обеспечить правильное определение «ADDAPI» в заголовке.Проще всего это сделать, передав «-D ADD_EXPORTS» в командной строке:

Для компиляции приложения не требуется никаких изменений в используемой нами командной строке:

Этот процесс сборки используется во многих реальных библиотеках. Если неясно, что происходит с определениями препроцессора, передайте «-save-temps» в командной строке gcc на этапе компиляции и просмотрите файлы с расширением «.i» — вы заметите, что в конечном итоге сгенерированный код как в элегантных, так и в неэлегантных примерах почти одинаково.

Экспорт и импорт переменных

В дополнение к функциям также можно экспортировать и импортировать переменные. Эти переменные должны быть объявлены как «extern __declspec(dllexport)» или «extern __declspec(dllimport)», в зависимости от того, строим ли мы DLL или клиентское приложение с использованием этих переменных. Как и в случае с функциями, мы можем использовать определения нашего препроцессора и просто выделить переменные «extern ADDAPI». Для переменных не следует указывать соглашение о вызовах.

Здесь мы добавили две экспортированные переменные в наш заголовочный файл, foo и bar.

Код библиотеки DLL теперь включает присвоение значений нашим экспортируемым переменным:

Приложение было изменено таким образом, что теперь оно добавляет импортированные переменные foo и bar вместе, выводя результат:

Если вы измените значения foo и bar, перекомпилируете DLL и снова запустите приложение, вы увидите, что переменные действительно импортированы из DLL.

Импорт библиотек

Хотя обычно можно связать DLL, просто имея DLL в вашей системе и добавив некоторые параметры командной строки компоновщика, это не всегда желательно. В этом случае вместо этого следует использовать библиотеку импорта. Библиотека импорта не содержит кода, но содержит всю необходимую информацию, необходимую вашему приложению для поиска функций, экспортируемых DLL. При создании библиотек для использования третьими лицами я бы рекомендовал всегда создавать библиотеку импорта и распространять ее вместе с вашими файлами DLL и заголовочными файлами, поскольку вашим пользователям может потребоваться создавать свои приложения с использованием библиотек импорта.< /p>

Если вы изменили имена функций, которые экспортирует DLL (см. «Предупреждение об экспорте функций stdcall» ниже), библиотека импорта — единственный вариант. Это относится к API Windows, где вы должны связать свои приложения с помощью библиотек импорта, т. е. передать «-lgdi32 -luser32» и т. д. в командной строке компоновщика при компиляции программ с графическим интерфейсом Windows.

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

Если вы не изменили ни одно из имен функций, экспортируемых DLL, то создание библиотеки импорта — это просто случай передачи дополнительного параметра «-Wl,--out-implib,lib[имя библиотеки ].a ” в командную строку компоновщика.

Принято использовать имя библиотеки в имени библиотеки импорта. Обязательно, чтобы имя файла начиналось с «lib» и заканчивалось расширением «.a», чтобы его можно было использовать (на самом деле есть несколько поддерживаемых соглашений об именах, которые вы можете использовать, которые описаны в руководстве, но все остальное не подходит). не работает).

Сборка приложения такая же, как и раньше, но вместо того, чтобы передавать каталог, содержащий DLL, компоновщику, вместо этого вы передаете каталог, содержащий библиотеку импорта (на самом деле мы все еще делаем все из текущего каталога, но это, вероятно, не было бы случаем для реального приложения). Чтобы связать DLL, вы передаете имя библиотеки импорта без префикса lib и расширения файла.

Обычно библиотеки DLL помещаются в папку с именем «bin», а библиотеки импорта — в папку с именем «lib», например, «C:\Program Files\Add\bin\» и «C:\Program Files\Add\». библиотека\ ".

Предупреждение об экспорте функций стандартного вызова

Одна вещь, о которой вы должны помнить при объявлении функций «__stdcall», заключается в том, что MinGW и MSVC экспортируют свои функции с немного разными именами (декорациями функций). Для нашего примера с добавлением выше MSVC экспортирует функцию «Add(int a, int b)» с именем «_Add@8» (подчеркивание, имя функции, знак at, размер аргументов в байтах), тогда как MinGW экспортирует ее. как «Add@8» (то же, что и MSVC, но без подчеркивания). Поэтому, если вы хотите иметь бинарную совместимость между сборками MinGW и MSVC вашей DLL, необходимо изменить имена экспортируемых функций. Это немного сложнее, чем я собираюсь охватить в этой статье, но я написал статью Advanced MinGW DLL Topics, в которой объясняется, как это сделать, а также некоторые подводные камни, на которые следует обратить внимание.

Добавление информации о версии и комментариев к вашей DLL

Если вы просмотрите свойства DLL с помощью проводника Windows и перейдете на вкладку «Подробности», вы, скорее всего, увидите информацию о DLL, такую ​​как версия, автор, авторские права и описание библиотеки.Это приятное прикосновение к DLL (особенно полезно, когда вы хотите знать, какая версия DLL установлена ​​на вашем ПК), и это довольно просто добавить в вашу DLL. Все, что вам нужно сделать, это создать ресурс версии, например следующий:

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

Идея состоит в том, чтобы скомпилировать сценарий ресурсов с помощью windres.exe, а затем передать его компоновщику при связывании библиотеки DLL. Например, если ваш ресурсный скрипт называется «resource.rc»:

Это все, что нужно сделать, чтобы добавить информацию о версии в DLL. Стоит потратить время на то, чтобы сделать это для любых DLL, которые вы выпускаете, так как это полезно и придает вашему приложению профессиональный вид.

Собираем все вместе

Используя информацию из этой статьи, вы теперь сможете собрать все воедино и создать библиотеки DLL с помощью MinGW, а также исполняемые файлы, использующие функции, экспортированные из библиотек DLL. Чтобы помочь вам, я создал небольшой проект, который создает DLL со следующими функциями:

• Экспортировано “ int Add(int a, int b); ”, используя соглашение о вызовах cdecl.
• Экспортированные переменные «foo» и «bar».
• Ресурс информации о версии, встроенный в библиотеку DLL.

Кроме того, будет создан исполняемый файл, который выводит результат сложения, используя экспортированную функцию и экспортированные переменные. Проект можно собрать с помощью утилиты mingw32-make.

Вы можете загрузить пример DLL MinGW с GitHub, чтобы создать пример DLL и приложения из этой статьи. Вы можете либо клонировать репозиторий с помощью git, либо загрузить пример выпуска MinGW DLL. Вы можете использовать его для любых целей, которые посчитаете нужными (полные условия использования см. в «License.txt»). Используя файлы проекта, вы можете легко создать пример из этой статьи и использовать его в качестве основы для своих собственных библиотек DLL и приложений.

Что нужно знать

Еще один момент, о котором следует помнить, это то, что если вы передаете структуры в функцию, экспортированную из библиотеки DLL, или возвращаете структуру из этой функции, вы не сможете позже изменить определение этой структуры. Внесение таких изменений, скорее всего, приведет к сбою старых приложений или к непредусмотренному поведению, поскольку расположение памяти структуры изменилось с момента компиляции приложения. Невозможно изменить определение структуры, не нарушая обратной совместимости, но это тоже не элегантно. Например, в Windows API часто бывает, что структуры имеют член (на первый взгляд бессмысленный), который указывает размер структуры, новые элементы добавляются в конце определения структуры и передаются в функции по адресу, а не по значению (для пример структуры OPENFILENAME). Это те вещи, которые позволяют Windows API изменяться между выпусками Windows, не нарушая обратной совместимости (я знаю, что люди могут сказать, что каждая версия Windows вызывает много проблем с обратной совместимостью, но факт в том, что хорошо написанное приложение, созданное для Windows 95 имеет хорошие шансы работать на последних версиях Windows, что, на мой взгляд, весьма впечатляет).

Похожие страницы

Дополнительные темы по созданию библиотек DLL с помощью MinGW, включая классы JNI, P/Invoke и C++.
Как создать полнофункциональное приложение Windows с графическим интерфейсом с помощью компилятора MinGW.
Как создавать приложения OpenGL для Windows с помощью библиотек freeglut или GLUT для Win32 и компилятора MinGW.

©2001–2018 Transmission Zero. Все права защищены. Конфиденциальность и файлы cookie.

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

создать dll для windows с помощью gcc

создать dll для windows с помощью gcc

‎02.03.2006 11:19

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

Я написал программу на C под Linux и хочу превратить ее в dll с помощью gcc, чтобы использовать ее в labview под Windows.

Кто-нибудь уже делал подобное? так какой волшебный вариант передать gcc, чтобы сделать это правильно?

Рольфк

‎03-03-2006 09:54

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

Я написал программу на C под Linux и хочу превратить ее в dll с помощью gcc, чтобы использовать ее в labview под Windows.

Кто-нибудь уже делал подобное? так какой волшебный вариант передать gcc, чтобы сделать это правильно?

‎03-03-2006 10:15

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

Приветствую,
Я не использовал MinGW для создания dll, но вы должны быть в состоянии создать dll. Ниже приведен небольшой пример из документации MinGW.

Джастин

Как создать dll

Вот пример. Вырежьте и вставьте следующее в файл с именем dllfct.h: Вырежьте и вставьте следующее в файл с именем dllfct.c: Вырежьте и вставьте следующее в файл с именем hello.c: Чтобы создать dll и исполняемый файл, который ее использует, попробуйте следующее:

‎07.03.2006 09:32

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

Рольфк

‎07.03.2006 11:17

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

мы также пробовали ключевое слово '__attribute ((dllexport))__', но оно больше не работало.

Я думаю, что стандартный атрибут gcc больше похож на атрибут (экспорт). В конце концов, среды gcc обычно используют общие библиотеки, а не библиотеки DLL. Но опять же, не каждый компилятор gcc сможет просто создать правильные исполняемые файлы Win32. Как уже объяснялось, в цепочке инструментов должно быть довольно много инструментов для намеченной цели.
Например, компилятор/компоновщик должен поддерживать формат библиотеки COFF, чтобы создать допустимый исполняемый файл Win32, если только у вас нет своего собственного формата Win32-совместимого загрузчика, который подключается и понимает формат вашей библиотеки. Также declspec() — это специальное расширение Microsoft, не поддерживаемое готовым gcc. И у gcc нет намерений добавлять что-либо, что они считают нестандартным, и большинство расширений Microsoft нестандартны.

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

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

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

Мне удалось скомпилировать следующий пример в dll и использовать его в узле функций библиотеки вызовов Labview;

Я скомпилировал это с 32-битной версией msys2. Я думаю, вы также можете использовать 64-битную версию, если укажете другой компилятор. Чтобы скомпилировать, я запустил:

Флаг -static-libgcc не позволяет labview жаловаться на libgcc_s_dw2-1.dll.

Надеюсь, это кому-нибудь поможет.

Рольфк

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

написал:

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

LabVIEW использует Windows API LoadLibrary(), чтобы попытаться загрузить DLL в память. LoadLibrary() довольно лаконична с точки зрения обработки ошибок. Это либо удается, либо нет, и на самом деле он не возвращает гораздо более подробную информацию о причине сбоя. GetLastError() можно вызвать, чтобы получить дополнительную информацию, но возвращаемые коды ошибок на самом деле не задокументированы и различаются в разных версиях Windows, поэтому немного сложно использовать это для чего-то большего, чем просто индикация ошибок.

Чтобы выдавать более содержательные сообщения об ошибках, связанных с отказавшими зависимостями, в LabVIEW потребуется реализовать собственный фиктивный синтаксический анализатор PE-файлов, чтобы попытаться определить все зависимости, а затем попытаться определить их местонахождение для правил поиска, которые могут различаться в разных версиях Windows и в зависимости от ограничения безопасности, наложенные в текущем сеансе Windows ИТ-отделом или аналогичным органом.

Надеюсь, вы понимаете, что это довольно бесполезное и затратное занятие.

Мне удалось скомпилировать следующий пример в dll и использовать его в узле функций библиотеки вызовов Labview;

aMultb.c:

aMultb.h:

Я скомпилировал это с 32-битной версией msys2. Я думаю, вы также можете использовать 64-битную версию, если укажете другой компилятор. Для компиляции я выполнил:

Флаг -static-libgcc не позволяет labview жаловаться на libgcc_s_dw2-1.dll.

Надеюсь, это кому-нибудь поможет.

Моему последнему сообщению исполнилось 12 лет. Это почти бесконечный период времени в компьютерных терминах. Положение дел с GCC, безусловно, изменилось за это время, и последние версии GCC поддерживают многие Microsoftisms, хотя может быть сложно найти правильный параметр командной строки для передачи в GCC для включения такой функции.

Тем не менее, компиляция кода — это первый шаг. Связывание его с окончательным исполняемым файлом — это совершенно другое дело, и хотя GCC также поддерживает множество различных вариантов и целей, в настоящее время вам обычно требуется дополнительная поддержка с точки зрения целевых скриптов компоновщика.Определенные дистрибутивы GCC, такие как MSys или MingW, поставляются с правильными сценариями поддержки, которые преобразуют параметры командной строки в форму, чтобы компилятор и компоновщик GCC выдавали правильные форматы.

И если вы установите libgcc_s_dw2-1.dll в своей системе Windows, я не вижу причин, по которым DLL, скомпилированная для зависимости от этой библиотеки времени выполнения, не сможет загрузиться в LabVIEW.

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

LabVIEW использует Windows API LoadLibrary(), чтобы попытаться загрузить DLL в память. LoadLibrary() довольно лаконична с точки зрения обработки ошибок. Это либо удается, либо нет, и на самом деле он не возвращает гораздо более подробную информацию о причине сбоя. GetLastError() можно вызвать для получения дополнительной информации, но возвращаемые коды ошибок на самом деле не задокументированы и различаются в разных версиях Windows, поэтому немного сложно использовать это для чего-то большего, чем просто индикация ошибки

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

Моему последнему сообщению исполнилось 12 лет. Это почти бесконечный период времени в компьютерных терминах. Положение дел с GCC, безусловно, изменилось за это время, и последние версии GCC поддерживают многие Microsoftismes, хотя может быть сложно найти правильный параметр командной строки для передачи GCC для включения такой функции.

Тем не менее, компиляция кода — это первый шаг. Связывание его с окончательным исполняемым файлом — это совершенно другое дело, и хотя GCC также поддерживает множество различных вариантов и целей, в настоящее время вам обычно требуется дополнительная поддержка с точки зрения целевых скриптов компоновщика. Определенные дистрибутивы GCC, такие как MSys или MingW, поставляются с правильными сценариями поддержки, которые преобразуют параметры командной строки в форму, чтобы заставить компилятор и компоновщик GCC выдавать правильные форматы.

И если вы получите libgcc_s_dw2-1 .dll, установленной в вашей системе Windows, я не вижу причин, по которым DLL, скомпилированная для зависимости от этой библиотеки времени выполнения, не сможет загрузиться в LabVIEW.

Я ответил на этот пост, несмотря на то, что ему уже 12 лет, потому что он до сих пор является первым хитом (по крайней мере, для меня) в Google.

Смысл был не в том, чтобы сказать: "Я могу скомпилировать эту тривиальную функцию с помощью gcc в Windows". То, что я опубликовал, было шагами, которые я использовал для компиляции и связывания функции с dll, которую я мог (и действительно) успешно использовать с узлом функций библиотеки вызовов labview.

Рольфк

‎09-02-2018, 01:38 — отредактировано ‎09-02-2018, 02:01

• Отметить как новое
• Добавить в закладки
• Подписаться
• Отключить звук
• Отправить сообщение другу

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

Я не уверен, что согласен здесь. Если вы введете «код ошибки LoadLibrary» в Google, вы получите дюжину или более рекомендаций по конкретным кодам ошибок, каждая из которых дает вам несколько десятков тысяч или более совпадений с часто очень неясными и даже совершенно неправильными решениями, включая множество поддельные сайты, пытающиеся очернить вас своим приложением для решения проблем с DLL, которое затем сообщает вам целую кучу проблем на вашем компьютере, которые они рады решить для вас, когда вы загружаете их оплаченное «настоящее» приложение, которое в лучшем случае не делает ничего, кроме показывает вам очищенное состояние вашей машины после длительного периода предположительной очистки вашей машины и, в не очень лучшем случае, содержит какую-то другую полезную нагрузку в виде вируса, рекламного ПО, трояна или какой-либо другой махинации.

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

LabVIEW не является средой для отладки проблем с зависимостями DLL и других проблем с DLL. Вполне допустимо предположить, что когда вы хотите использовать DLL в LabVIEW, эта DLL уже полностью отлажена и правильно установлена ​​в системе. Правильная установка — это не копирование ее куда-то на ваш компьютер и ожидание, что она будет работать, а установка DLL и ВСЕХ ее зависимостей в соответствии с правилами, которые Windows налагает на DLL. Если вы разработали DLL, вы несете ответственность за отладку DLL и создание такого установщика, а также тестирование установщика на различных компьютерах с помощью ваших собственных тестовых приложений и инструментов, таких как обходчик зависимостей DLL и Sysinternal Process Explorer.

Если вы не разрабатывали DLL самостоятельно, первоначальный разработчик должен был создать такой установщик, а если он этого не сделал, то это не вина LabVIEW, когда эта DLL не может быть загружена.Ошибка LoadLibrary(), и состояние дел вокруг этой функции таково, что перенастроенный код ошибки сильно различается между версиями Windows, включая иногда даже вводящие в заблуждение подсказки.

Майкрософт без каких-либо причин не удалила упоминания конкретных кодов ошибок со страницы MSDN для этой функции!

В текущей документации указано:

Если функция завершается ошибкой, возвращается значение NULL. Чтобы получить расширенную информацию об ошибке, вызовите GetLastError.

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

Если загрузка библиотеки DLL в узле библиотеки вызовов LabVIEW не удалась, это означает, что библиотека DLL повреждена или она или одна из ее зависимостей неправильно установлена ​​на компьютере! На данный момент LabVIEW не может сообщить вам больше, чем то, что Windows отказалась загружать DLL.

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

код и данные

библиотека импорта

Код и данные — это те части, которые вы пишете: функции, переменные и т. д. Все они объединяются вместе, как если бы вы создавали один большой объектный файл, и помещаются в dll. Они вообще не помещаются в ваш .exe.

Экспорт содержит список функций и переменных, которые dll делает доступными для других программ. Думайте об этом как о списке «глобальных» символов, остальные скрыты. Обычно вы создаете этот список вручную с помощью текстового редактора, но это можно сделать автоматически из списка функций в вашем коде. Программа dlltool создает раздел экспорта dll из вашего текстового файла экспортированных символов.

Библиотека импорта представляет собой обычную UNIX-подобную библиотеку .a, но она содержит только крошечную часть информации, необходимой для того, чтобы сообщить ОС, как ваша программа взаимодействует с ("импортирует") dll. Эта информация связана с вашим .exe . Это также генерируется dlltool .

Создание библиотек DLL

Давайте рассмотрим простой пример создания dll. В этом примере мы будем использовать один файл myprog.c для программы ( myprog.exe ) и один файл mydll.c для содержимого dll ( mydll.dll ).

К счастью, с последними версиями gcc и binutils процесс сборки dll теперь довольно прост. Допустим, вы хотите создать эту минимальную функцию в mydll.c:

Сначала скомпилируйте mydll.c в объектный код:

Затем сообщите gcc, что он создает общую библиотеку:

Вот оно! Чтобы закончить пример, теперь вы можете связать dll с помощью простой программы:

Затем свяжите свою dll с помощью команды, например:

Однако, если вы создаете dll в качестве библиотеки экспорта, вам, вероятно, потребуется использовать полный синтаксис:

Имя вашей библиотеки — $ с префиксом cyg для DLL и lib для библиотеки импорта. Библиотеки Cygwin используют префикс cyg, чтобы отличить их от собственных библиотек DLL MinGW для Windows. Дополнительные сведения см. на веб-сайте MinGW. $ — это все ваши объектные файлы, объединенные в статические библиотеки или отдельные объектные файлы, а $ — это импортные библиотеки, с которыми вам нужно связать, например, '-lpng -lz -L/usr/local/special -lmyspeciallib' .

Связывание с DLL

Если у вас уже есть DLL, вам нужно создать библиотеку импорта, совместимую с Cygwin. Если у вас есть исходный код для компиляции DLL, см. раздел «Создание DLL» для получения подробной информации о сборке gcc для вас. Если у вас нет исходного кода или поставляемой рабочей библиотеки импорта, вы можете получить большую часть пути, создав файл .def с помощью этих команд (вам может потребоваться сделать это в bash, чтобы цитирование работало правильно):

Обратите внимание, что это будет работать, только если DLL не удалена. В противном случае вы получите сообщение об ошибке: «Нет символов в foo.dll».

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

Читайте также:

  
• Как отключить звук AirPods на ноутбуке
  
• Как убрать черное пятно на экране ноутбука
  
• Установка ИБП в стойку
  
• Контроллеры PCI ATA не найдены victoria
  
• Как получить ЭЦП в Ощадбанке