| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > 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 |
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. Инициализируемых глобальных данных (даже с внутреннем связыванием - быть не должно ) - как вариант решается что-то типа:
4. Во внешнем интерфейсе использовать только POD данные, оптимальный вариант void*, т.к. проблемы могут возникать в т.ч. из-за aligment-a т.е. внешний интерфейс построен на а-ля хандлах (указателях на реальные объеты). 4.1 Если требуються структуры (для передачи параметров)- юзать #pragma pack [с условной компиляцией] и возмжно юзать типы типа ;)) int16? int32 etc... 4.2 Возможно отдельный трабл - динамическое управление памятью - тогда пишешь для своих клааосв примесь, которая определяет операции new/delete нужных разновидностей, в терминах ::alloc/::malloc, а для std::* пишешь свой аллокатор под ту же фигню P.S. это чисто теоретические рассуждения, но думаю истины в них не менне 1% |
| Автор: slava72 17.7.2006, 16:09 |
| с учетом вышесказанного (также как и оно - глубокое ИМХО) - код долже быть разбит на 3 части: 1. Чисто сишный интерфейс доступа (с учетом вырвнивания, etc) 2. чисто сишный интерфейс доступа к стандартным библиотекам: printf, malloc, etс... 3. собственно библиотека - реализует п.1 и использует _только_ п.2 |