Добрый день.

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

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

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

проблема, например, в стадии "прилинковать" -- это как/что делать? 

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

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

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

А разве gcc делает объектные файлы совместимые с MSVC? 

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

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."
 

Общие вопросы к скрещивапнию раздельно компилируемых библиотек под разную фигню

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%   
 

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

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

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

printf, malloc, etс...


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