Есть программа, которая может работать как с плагином, так и без него. Плагин реализован в виде .dll файла.
Будет ли использоваться плагин или нет решается на этапе компиляции. Компилятор mingw.

Плагин экспортирует ряд функций, которые вызывает основная программа. Сами функции плагина используют методы из основной программы, т.е. основная программа компилится как -shared и экспортирует ряд своих функций. Таким образом получается полное связывание: dll <-> exe
К dll линкуется exe, к exe линкуется dll.

У линковщика gcc есть ключ --out-implib=main.a, который позволяет помимо сборки .exe файла экспортировать библиотеку, которую можно прилинковать к плагину (dll). 

Т.к. получается замкнутый круг мне необходимо, чтобы линковщик не создавал .exe файла, а только экспортировал main.a файл, который я бы прилинковал к dll, а после этого собрал бы уже exe файл с прилинкованной dll.a библиотекой после сборки плагина.

Сборка .exe файла идет таким образом:



Если убрать '-o"main.exe"', то все-равно создается файл "a.exe", мне нужен только main.a файл на данном этапе

Это сообщение отредактировал(а) SABROG - 26.1.2008, 19:53

SABROG, учитывая, что из себя представляет import library, боюсь, что такое невозможно. Необходимо провести декомпозицию и избавится от цикличной зависимости.

Могу я в очередной раз поинтересоваться, как Ваш пост относится к специфике данного раздела?

Часть названия ветки "Кроссплатформенное программирование". 
У меня кроссплатформенный проект, который отлично собирается под nix'ами и в винде через MSVC.
Я хочу сделать возможным собирать проект через mingw. Работа закончена на 70%.

Насчет "невозможности" я не соглашусь, проект как-раз так и работал, собран он был лишь в msvc. Сейчас я пытаюсь понять как мне написать makefile для mingw, чтобы в правильной последовательности и без "хаков" заставить проект собираться...

Цикличной зависимости не возникает, скорее всего потому, что сначала грузится main.exe, который в свою очередь подгружает статически слинкованную dllку, та в свою очередь пытается подгрузить снова main.exe, но ОС находит ее уже загруженной в память, поэтому цикл на этом прерывается.

Это сообщение отредактировал(а) SABROG - 26.1.2008, 23:19

Можно глянуть на hello world солюшн с циклической связью? (приаттачьте)
Возможно, так будет проще помочь Вам.


Можно попробовать удалять .exe после сборки, но я что-то сомневаюсь, что это будет работать(в плане makefile будет работать правильно, но, боюсь, не будет работать последующая линковка или сам бинарник).

Ну с нуля писать hello world накладно, но я нашел наглядный пример - http://www.codeguru.com/cpp/w-p/dll/article.php/c3649/

Вроде как начало проясняться, plugin.dll статически линкует exe файл, exe файл динамически подгружает plugin.dll. Только сейчас косяк возник со статической линковкой exe файла:



В exe файле этот экспортируемый класс объявлен так:



Это сообщение отредактировал(а) SABROG - 27.1.2008, 00:09

.
В этом принципиальная разница, т.к. в случае, если оперировать GetProcAddress циклической зависимости не будет. Вам же требуется связывание, так сказать, на этапе компиляции. Вы утверждаете, что проделывали такое на c MSVC, вот я и прошу привести мне пример т.к. мне немного не верится, что такое возможно...

M Любитель

SABROG, читаем что обсуждается в C/C++: КП :)

 

Ладно, похоже придется дальше самому ковыряться. Тему можно удалить.

Написал именно в этом разделе, потому, что нужен совет специалистов, которые работали как с MSVC так и с компилятором GCC.

SABROG, на мой взгляд, то что ты пытаешься сделать сродни двум хэдерам с перекрёстной зависимостью, но без forward declarations.

Такое вот по какой причине обычно вылезает ?



В .def файле и в .a файле четко вижу наличие __imp___ZTV17FollowerReference. FollowerReference - класс.

Нужно добавить ключик --enable-runtime-pseudo-relocs.

Добавлял уже, не помогает никак вообще, выводит тоже самое.

Попробывал метод без подключения .a, а просто переименовал main.exe -> libmain.dll и линкер его подцепил точно также как и .a и с теми же ошибками.

Странно, обнаружил, что -export-all-symbols у меня, по какой-то причине, не включен по-умолчанию. После включения либа (main.a) разжирела на 8 мегов, исчезли проблемы с другими импортами, а вот именно с этим остались...
---------

Углубился в тему. Немного разобравшись, понял где происходит косяк, но не понял как это исправить. 
Значит смысл такой, есть .exe файл в котором определен класс, этот .exe файл динамически загружает plugin.dll, а он в свою очередь статически слинкован с exe файлом. Так вот благодаря тому, что в хидерах описано определние класса из плагина создается экземпляр объекта через оператор new. Методы этого объекта находятся в exe файле. Не могу понять, почему MSVC все это хавает, а gcc не хочет:



Это сообщение отредактировал(а) SABROG - 27.1.2008, 19:31

SABROG, смотри, вот hello world пример(возможно, что неправильный):



Что я делаю неправильно? 

Забыл декорацию __declspec(dllexport) ?

Взял пример, на который выкладывал ссылку выше, и переделал его немного. Все собирается, но при вызове программы выдает "main.exe не является приложением Win32". Исходники тут http://filebeam.com/746ddc0026e738bcda9f20e2356edffe

------
Так, с main.exe я разобрался, ошибка была потому, что я его собирал с флагом -shared.

Это сообщение отредактировал(а) SABROG - 28.1.2008, 18:41

Не совсем, но не суть . Да, проблема интересная и, как не странно, решения в интернете я не нашёл, а искал долго(очень долго - самому скоро понадобится). В общем, сейчас есть задачи поважнее, но, как только, так сразу займусь этой проблемой.