Как упоминалось в комментариях, если DLL тесно связаны, это может иметь смысл просто объединить их в одну DLL.
Однако, если требуется еще две библиотеки DLL, одно из них - разделить один из проектов, которые в настоящее время строят DLL на две части - проект статической библиотеки, который также создает библиотеку импорта и файл экспорта из модуля файл определения и второй проект, который создает DLL.
Эти два проекта затем записывают конструкцию другой DLL.
Например, выбирая для разделения Fortran DLL, так как я больше знакомы с системой проекта:
Создание файла определения модуля, с тем же базовым именем, будет использоваться для Fortran DLL , который перечисляет в своем разделе экспорта все символы, которые экспортирует библиотека Fortran.
Создайте проект статической библиотеки Fortran с именем, отличным от имени конечной библиотеки Fortran DLL, которая настроена на сбор всех источников Fortran. В свойствах проекта в качестве шага пользовательской сборки добавьте дополнительный вызов библиотекаря по линиям lib /DEF:xxx.def /OUT:xxx.dll /MACHINE:x86 (где xxx - это базовое имя, которое будет использоваться для файлов конфигурации Fortran DLL), в качестве подходящих суффиксов пути, в зависимости от ситуации, измените машину вариант по мере необходимости). Построение этого проекта статической библиотеки Fortran теперь создаст две библиотеки: одну с объектным кодом (названным в честь проекта), а также библиотеку импорта (названную в честь DLL) и файл экспорта (также названный в честь DLL).
[Обратите внимание, что при таком подходе библиотека импорта фактически не зависит от объектного кода, генерируемого при Fortran исходных файлов компилируются - использование на стадии сборки пользовательской статического проекта библиотеки просто удобство. Если у вас еще нет файла определения модуля для библиотеки Fortran, альтернативный подход заключается в том, чтобы вместо этого предоставлять отдельные файлы объектов при вызове библиотекаря на этапе пользовательской сборки и позволить библиотекарю определять экспорт из любых директив в исходные файлы. Тем не менее, я предпочитаю файлы определения модуля в директивах источника.]
Создание проекта C++, который содержит все C++ источников и строит ++ DLL C. Этот проект должен зависеть от проекта статической библиотеки Fortran и ссылки на библиотеку импорта, сгенерированную проектом статической библиотеки Fortran.
Создайте проект Fortran DLL с тем же базовым именем, что и библиотека Fortran, которая содержит фиктивный исходный файл Fortran, в котором есть только комментарии (это просто, чтобы избежать сбоев системы сборки). Этот DLL-проект должен зависеть от проекта C++ DLL и ссылки на библиотеку импорта, сгенерированную проектом C++. В свойствах проекта в разделе Linker> Input> Additional Dependencies также добавьте в статическую библиотеку (а не библиотеку импорта!) И экспортируйте файл, сгенерированный проектом статической библиотеки Fortran.
Другие прямые клиенты библиотеки Fortran DLL должны ссылаться на библиотеку импорта, созданную на этапе пользовательской сборки проекта статической библиотеки Fortran.
Возможны варианты этого подхода.
Пульты и доводчики - в этом нет ничего плохого, и это понятно. То, что вы этого не понимаете, не означает, что это не ясно. – SergeyA
Какой компилятор Fortran? Какова ваша конкретная структура проекта? Я не понимаю, как возникает циклическая зависимость - обычно источник из каждого языка компилируется в одну или несколько статических библиотек, и компоновщик просто потребляет эти библиотеки. – IanH
Мой главный «продукт» - это C++ DLL, которая связывает статический файл FORTRAN lib. Я использую компилятор Intel Fortran, и циклическая зависимость просто потому, что C++ вызывает FORTRAN, а FORTRAN вызывает C++. – Kyudos