Да, если вы сделаете динамическую ссылку и создадите интерфейс в стиле c. lib.exe создаст библиотеки импорта, совместимые с цепочкой инструментов gcc.
Это решит ваши проблемы со ссылками. Однако это только начало проблемы.
Большими проблемами будут такие вещи, как исключения и распределение памяти.
- Вы должны убедиться, что исключения не переходят из кода VC ++ в код gcc, нет гарантий совместимости.
- Каждый объект из библиотеки VC ++ должен жить в куче, потому что:
- Не смешивайте gcc new / delete с чем-либо из VC ++, произойдут плохие вещи. Это относится и к построению объектов в стеке. Однако, если вы создадите интерфейс, такой как create_some_obj () / delete_some_obj (), вы не будете использовать gcc new для создания объектов VC ++. Может быть, сделать небольшой объект-обработчик, который обрабатывает строительство и разрушение. Таким образом вы сохраняете RAII, но все еще используете c-интерфейс для истинного интерфейса.
- Соглашение о вызовах должно быть правильным. В VC ++ есть cdecl и stdcall. Если gcc попытается вызвать импортированную функцию с неправильным типом вызова, произойдут плохие вещи.
Суть в том, чтобы сохранить простой интерфейс, совместимый с ANSI C, и с вами все будет в порядке. Тот факт, что сумасшедший C ++ остается позади, это нормально, пока он содержится.
Да, и убедитесь, что весь код повторно вводится, иначе вы рискуете открыть еще один can-o-worms.