Переход компилятора C(++) - пожалуйста, уберите DJGPP

Я работаю над написанием ядра, и со мной над проектом работает несколько друзей. Мы использовали DJGPP для компиляции проекта некоторое время, но у нас возникли некоторые проблемы кросс-платформенной совместимости при компиляции таким образом, из-за которых мой основной Partnet в проекте не смог скомпилироваться в Windows XP. (У GCC DJGPP есть проблемы со списками аргументов длиннее 127 в Windows XP, но нет проблем с теми же списками аргументов в Vista. Итак, на этот раз Vista работает лучше, чем XP в чем-то. o.O)

Во всяком случае, вместо того, чтобы пытаться придумать какой-нибудь грязный хак, чтобы компилировать эту чертову штуку с помощью DJGPP, мы решили, что хотим полностью отказаться от DJGPP и работать с другой версией GCC для Windows. Проблема в том, что MinGW (насколько мне известно) не позволяет нам использовать синтаксис NASM для ассемблерных частей кода, и было бы немного сложно преобразовать все это в синтаксис AT&T на данном этапе. Возможно, конечно, так как это довольно рано в проекте, но боль.

Итак, теперь вы знаете, в чем дело. Мой вопрос таков: какой дистрибутив компилятора GCC для Windows позволит нам наиболее легко перенести этот проект на себя? В идеале мы ищем что-то, что может выполнять синтаксис ассемблера NASM, не зависеть от внешних dll (здесь это ядро, у него не будет доступа к ним) и будет стабильно работать на нескольких версиях в Windows. Каковы ваши рекомендации о том, как лучше всего это сделать, и какую версию GCC для Windows вы рекомендуете?

Обратите внимание, что если нам понадобится преобразовать проект в синтаксис AT&T, это нормально, я просто не хотел бы этого делать. На самом деле мы используем NASM для сборки его ассемблерных битов, и это создает действительный файл .o, но MinGW по какой-то причине не может связать его. Я думаю, что биты встроенной сборки (возможно, 5 строк) уже являются синтаксисом AT&T, как того требует GCC.

Спасибо!


person Nicholas Flynt    schedule 02.11.2008    source источник


Ответы (3)


Вероятно, вы передаете nasm неправильный тип объекта с опцией -f.

Бьюсь об заклад, вы передаете -f coff.

Вам нужно будет передать -f win32.

person Joshua    schedule 02.11.2008
comment
При передаче -f Win32 (как и раньше) я все еще получаю следующую ошибку от GCC MinGW: сборка/start.o: файл не распознан: формат файла не распознан - person Nicholas Flynt; 03.11.2008
comment
или, в более общем смысле: используйте file(1), чтобы проверить, какой файл создает nasm и какой тип файла создает gcc, а затем меняйте параметры до тех пор, пока они не совпадут. Если вы не можете указать правильные параметры, используйте objcopy - person Martin v. Löwis; 03.11.2008
comment
странный. У меня есть проект MinGW/NASM, и -f win32 — это то, как я сам создаю компонент nasm. - person Joshua; 03.11.2008
comment
Я обнаружил настоящую проблему. Это были не файлы .o, на самом деле это был мой скрипт компоновщика. Я ищу ответ на это. - person Nicholas Flynt; 03.11.2008
comment
Нашел. Изменение типа вывода, используемого сценарием компоновщика, на что-то, что было согласовано со всеми, было ключом. Этот ответ определенно указал в правильном направлении. Огромное спасибо! - person Nicholas Flynt; 08.12.2008

Создайте кросс-компилятор.

http://wiki.osdev.org/GCC_Cross-Compiler

Это то, что я сделал при переходе с DJGPP для разработки на хосте Windows. Я рекомендую метод Cygwin, так как он немного более стабилен, чем MSYS.

Сделав это, настройте NASM для создания elf32 объектных файлов, и все готово.

person Unsigned    schedule 19.10.2011

Вы используете NASM, скомпилированный для DOS или для Windows? Не смотрел, но возможно что разница есть. Кроме того, если ваш NASM слишком стар, он может не сгенерировать что-то, что может понять MinGW.

Быстрый поиск в Google нашел руководство по компиляции x264 под MinGW, где одним из шагов является компиляция NASM на MinGW.

В противном случае вы можете попробовать (как было предложено в комментарии к другому ответу) с помощью objcopy.

person CesarB    schedule 02.11.2008