Russian Qt Forum
Ноябрь 01, 2024, 01:45 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Как корректно собрать dll под cygwin-ом?  (Прочитано 7670 раз)
hnorgist
Гость
« : Июнь 07, 2010, 07:20 »

Файл libsample.c
Код
C
int libsample_func(int a, int b) {
return a + b;
}
 
Собираю:
Код:
$ gcc -shared -o libsample.dll libsample.c
И собранная библиотека работает если работать с ней из другого сишного файла.
Но мне нужно её обернуть в python, а питоновский процесс виснет на открытии этой dll-ки:
Код
Python
import ctypes
ctypes.CDLL("libsample.dll")
А если эту же библиотеку собрать в Visual Studio, то она нормально оборачивается в python.


Дурные мысли на тему:
Быть может коряво собираю? Пытаюсь собрать с использованием dlltool по примеру в его же мануале
Код:
$ gcc -c libsample.c
$ dlltool -z libsample.def libsample.o --export-all-symbols
$ dlltool -e libsample_exports.o -l libsample.lib libsample.o
$ gcc libsample.o libsample_exports.o -o libsample.dll
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16'
collect2: ld returned 1 exit status
Оно и понятно, нету main-а. Может пропущен парамертр -shared в последней строчке? Но с ним собирается библиотека, которая так же не работает в питоне.


Offtopic:
Вопрос вызван тем, что пытаюсь собрать библиотеку libmpq на винде и обернуть ее в питон. Стандартным способом ./configure && make && make install не собирается. Точнее собирается, но только статическая библиотека, а на этапе make вылезает: libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries. А если пытаюсь собрать вручную(gcc -shared), то питон так же виснет.
« Последнее редактирование: Июнь 07, 2010, 07:31 от hnorgist » Записан
kuzulis
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2812


Просмотр профиля
« Ответ #1 : Июнь 07, 2010, 08:56 »

http://www.prog.org.ru/topic_8259_0.html
Записан

ArchLinux x86_64 / Win10 64 bit
hnorgist
Гость
« Ответ #2 : Июнь 07, 2010, 09:58 »

Прочитал, прочитал и упоминаемые 41, 42 главы "Фундамантального труда Шлее" - там только общие знания.

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

Разные компиляторы по-разному кодируют в объектном коде имена функций, классов и т.д. Более того, могут отличаться и смещения полей внутри класса. По этому попытка подключить dll, собранный в другом компиляторе, скорее всего, увенчается успехом лишь в том случае, если все ф-ции отмечены как extern "C" и смещения структур выравнены принудительно. Для классов это, разумеется, не подходит.

Как ни трудно понять, при самостоятельной разработке библиотеки эта проблема вряд ли возникнет. А вот если мы имеем чужой dll и закрытый код... Тем, кто попал в такую ситуацию, остается только посочувствовать.

Действительно, проверил пример не на виндовском на сигвиновском питоне - работает. Но все-таки хотелось бы уточнить: то есть нет простого варианта заставить работать сигвиновские/mingw-шные библиотеки? А есть тяжелый вариант?

Хотелось бы получше понять природу проблемы и заставить работать хоть простейшую библиотеку(подправить пару смещений?).
Я так понимаю тут проблема уже на этапе загрузки библиотеки, а это мне не понятно - неужели нет универсальной точки входа и кода загрузки библиотеки? Пусть бы на этапе вызова функций возвращалось непонятно что..
« Последнее редактирование: Июнь 07, 2010, 10:01 от hnorgist » Записан
MoPDoBoPoT
Гость
« Ответ #3 : Июнь 07, 2010, 11:48 »

Вся загвоздка в декорировании имен (name decoration) и в соглашении вызова функций (calling convention). Для полноты картины ознакомся с "Написание и использование DLL в различных средах".
Записан
hnorgist
Гость
« Ответ #4 : Июнь 08, 2010, 00:49 »

Спасибо, то что надо
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.423 секунд. Запросов: 22.