Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > GNU toolchain > прикрутить объектный файл к проекту


Автор: _hunter 14.7.2006, 17:26
Добрый день.

Подскажите, можно ли объектный файл (собрвнный gcc в MinGW .o) каким-то образом прикрутить к проекту так, чтобы можно было использовать его функции (передаваемые/принимаемые параметры я знаю)?

С уважением... 

Автор: Daevaorn 14.7.2006, 17:40
_hunter,
В чем проблема то?
Написать заголовочный файл(если нет) и прилиноковать это объектный файл 

Автор: _hunter 14.7.2006, 17:47
проблема, например, в стадии "прилинковать" -- это как/что делать? 

Автор: Daevaorn 14.7.2006, 17:51
Добавить в список объектных файлов в командной строке/мейкфайле и собрать приложение. Или я чего-то не понимаю в вопросе? 

Автор: _hunter 14.7.2006, 18:01
я в студии (IDE) работаю... 
приписал в опция компилятора ffmpeg.o -- сказал "unknown character '0x1'" и так далее...
 

Автор: Daevaorn 14.7.2006, 19:32
_hunter, хм...
Если там только функции тогда так:
1. они должны быть скомпилированы в объектный файл как функции на языке С (extern "C"{/*...*/})
2. полученный объектный файл переименовываешь в ffmpeg.obj
3. добавляешь к проекту этот файл (либо в свойствах линкера, либо просто как файл в Solution Explorer )
 

Автор: bsa 14.7.2006, 21:07
А разве gcc делает объектные файлы совместимые с MSVC? 

Автор: Daevaorn 14.7.2006, 21:15
Цитата(bsa @  14.7.2006,  22:07 Найти цитируемый пост)
А разве gcc делает объектные файлы совместимые с MSVC?  

Mingw - да. но совместимость вроде частичная - только С. 

Автор: _hunter 17.7.2006, 11:05
Daevaorn, если где-нить в коде не прописать extern "C" int Test(); получаю ошибку "Test': identifier not found, even with argument-dependent lookup", а если прописать -- при вызове Test получаю "Unhandled exception at 0x00000000 in Client.exe: 0xC0000005: Access violation reading location 0x00000000."
 

Автор: slava72 17.7.2006, 15:54
Общие вопросы к скрещивапнию раздельно компилируемых библиотек под разную фигню

1. Все используемые совметно функи (и только они) должны быть объявлены в блоке
extern "C" { ...}

2. Не стоит иметь глобальных переменных

3. Инициализируемых глобальных данных (даже с внутреннем связыванием - быть не должно ) - как вариант решается что-то типа:

Код

extern "C" int* [namespace::]GetLastError() {
  static error = 0;
  return &error;
}


4. Во внешнем интерфейсе использовать только POD данные, оптимальный вариант void*,
т.к. проблемы могут возникать в т.ч. из-за aligment-a

т.е. внешний интерфейс построен на а-ля хандлах (указателях на реальные объеты).

4.1 Если требуються структуры (для передачи параметров)- юзать #pragma pack [с условной компиляцией]
и возмжно юзать типы типа ;)) int16? int32 etc...

4.2 Возможно отдельный трабл - динамическое управление памятью - тогда пишешь
для своих клааосв примесь, которая определяет операции new/delete нужных разновидностей, в терминах ::alloc/::malloc, а для std::* пишешь свой аллокатор под ту же фигню

P.S. это чисто теоретические рассуждения, но думаю истины в них не менне 1%  smile 
 

Автор: slava72 17.7.2006, 16:09
с учетом вышесказанного (также как и оно - глубокое ИМХО) - код долже быть разбит на 3 части:

1. Чисто сишный интерфейс доступа (с учетом вырвнивания, etc) 

2. чисто сишный интерфейс доступа к стандартным библиотекам:

printf, malloc, etс...


3. собственно библиотека - реализует п.1 и использует _только_ п.2


 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)