Библиотеки ссылок, скомпилированные различными компиляторами - PullRequest
1 голос
/ 14 сентября 2009

Я хотел бы спросить более подробно об ответе, который я недавно получил здесь (3-й): Основы скомпилированных языков

Если я напишу на C и MinGW и укажу ссылку на библиотеку C ++, скомпилированную VC - будет ли она работать? Как я знаю заранее?

Другими словами, если я могу без предупреждения создать .exe, который ссылается на этот C ++ .dll, и я могу запустить (просто запустить, больше не тестировать) этот .exe, значит ли это работал? Неужели в какой-то момент дамп памяти?

Чтобы быть полностью уверенным, нужно ли мне самостоятельно перекомпилировать исходные коды библиотеки и ссылку на нее?

Я понимаю, что иногда может быть проблема со связыванием кода C ++ и C, но как узнать, когда он работает и работает?

PS: Да, я видел Использовать скомпилированные библиотеки ... Я просто подумал, что мой вопрос немного отличается.

Ответы [ 2 ]

5 голосов
/ 14 сентября 2009

Да, вы можете конвертировать скомпилированные библиотеки MSVC для MinGW без перекомпиляции.
Вам нужно только пару инструментов и DLL. Проверьте здесь .

Что касается смешивания C и C ++ - если вас не беспокоит размер вашего бинарного файла, просто используйте компилятор c ++ для ваших проектов c. Таким образом, вы не будете беспокоиться о возможных проблемах с библиотеками, на которые вы ссылаетесь.

1 голос
/ 14 сентября 2009

Если я напишу на C и MinGW и укажу ссылку на библиотеку C ++, скомпилированную VC - будет ли она работать?

Это зависит от компиляторов (и я не знаю MinGW) и от конкретной библиотеки C ++.

Причины, по которым он может не связываться или может аварийно завершить работу при ссылке:

  1. Библиотека C ++ экспортирует классы и методы C ++, используя "искаженные" имена , но искажение имени в MinGW на C ++ может (я не знаю) отличаться от VC (и не существует) когда вы пишете код на C вместо C ++)

  2. Код VC не использует ту же библиотеку времени выполнения C, что и MinGW, которая будет кусать вас, если API таков, что память выделяется в куче кодом VC, а затем предполагается, что она освобождается Код MinGW.

  3. Код VC не совместим двоично с кодом MinGW (не использует те же соглашения о передаче параметров, не реализует исключения аналогичным образом)

С другой стороны, некоторые причины, по которым это может работать:

  1. Библиотека C ++ написана с интерфейсом в стиле C, разработчиками, которые намеревались вызывать ее из другого компилятора

  2. То же, что и 1.

  3. Создатели компилятора MinGW сделали его двоично-совместимым с VC

Откуда я знаю заранее?

Я не знаю. Если вы публикуете имена функций, экспортируемых из DLL, и / или заголовочный файл, который объявляет свой открытый / экспортированный API, это даст мне (или кому-то еще) очень сильный намек на то, экспортирует ли он (возможно, несовместим) C ++ в стиле или экспорт (более вероятно, совместимый) функций в стиле C.

В противном случае у вас есть двухэтапный вопрос:

  1. Что требуется (например, C вместо C ++, например, не предполагая, что они используют одну и ту же кучу, например, определяя соглашение о передаче параметров) для кода MinGW для вызова кода VC?

  2. Была ли ваша библиотека VC написана с учетом этого?

Кто-то, кто использовал оба компилятора, мог бы, вероятно, ответить на первый вопрос (я не использовал MinGW). Я не знаю, кто мог ответить на второй; кто написал эту библиотеку VC?

...