Я нахожусь в процессе создания цепочки инструментов ps2 (playstation 2) для OSX, используя существующий скрипт, который в прошлом отлично работал для Linux/Windows, но всегда вызывал проблемы в OSX.
Проблема, с которой я сталкиваюсь прямо сейчас, заключается в том, что я дохожу до точки, где перекрестный gcc, по-видимому, вызывает собственный «как» вместо существующего перекрестного «как»:
ee-gcc -B/Users/gilligan/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/ -isystem /Users/gilligan/ps2toolchain/build/newlib-1.10.0/build-ee/ee /newlib/targ-include -isystem /Users/gilligan/ps2toolchain/build/newlib-1.10.0/newlib/libc/include -DPACKAGE=\"newlib\" -DVERSION=\"1.10.0\" -I. -I../../../../../newlib/libc/stdlib -O2 -DMALLOC_ALIGNMENT=16 -DMISSING_SYSCALL_NAMES -I../../targ-include -I../../. ./../../newlib/libc/../libc/include -fno-builtin -G0 -g -c ../../../../../newlib/libc/stdlib/__adjust .c ee-gcc -B/Users/gilligan/ps2toolchain/build/newlib-1.10.0/build-ee/ee/newlib/ -isystem /Users/gilligan/ps2toolchain/build/newlib-1.10.0/build-ee /ee/newlib/targ-include -isystem /Users/gilligan/ps2toolchain/build/newlib-1.10.0/newlib/libc/include -DPACKAGE=\"newlib\" -DVERSION=\"1.10.0\" -I . -I../../../../../newlib/libc/stdlib -O2 -DMALLOC_ALIGNMENT=16 -DMISSING_SYSCALL_NAMES -I../../targ-include -I../../. ./../../newlib/libc/../libc/include -fno-builtin -G0 -g -c ../../../../../newlib/libc/stdlib/__exp10 .c FATAL:/usr/bin/../libexec/gcc/darwin/x86_64/as: я не понимаю флаг 'G'! make[3]: * [__exp10.o] Ошибка 1 make[3]: * Ожидание незавершенных заданий.... FATAL:/usr/bin/../libexec/gcc/darwin/ x86_64/as: Я не понимаю флаг 'G'! make[3]: * [__adjust.o] Ошибка 1 make[2]: [all-recursive] Ошибка 1 make[1]: [all- рекурсивный] Ошибка 1 make: * [all-target-newlib] Ошибка 2
Здесь следует отметить (извините, не очень разборчиво), что ee-gcc вызывает 'as' из /usr/bin/../libexec/gcc/darwin/x86_64/as< /strong> т.е. системный родной вместо ee-as. Как это может быть ?
Проверяя вывод 'ee-gcc -print-search-dirs', я вижу, что ee-as действительно находится по одному из указанных путей, и я проверил, что он является исполняемым.
Без доступа ко всем данным сложно что-то сказать по этому поводу, но, может быть, у кого-то есть идеи, что мне искать - я не понимаю, как ee-gcc разрешает свой ассемблер как нативный. Как работает выбор двоичного кода на ассемблере?
ОБНОВЛЕНИЕ Спасибо за вклад, но я боюсь, что все это более сломано, чем предполагалось изначально. Теперь gcc (llvm-gcc-4.2) segfaulting при обработке libgcc2.c
/Users/gilligan/Разработка/ps2dev/ps2toolchain/build/gcc-3.2.2/build-ee-stage1/gcc/xgcc -B/Users/gilligan/Разработка/ps2dev/ps2toolchain/build/gcc-3.2.2/build -ee-stage1/gcc/ -B/usr/local/ps2dev/ee//ee/bin/ -B/usr/local/ps2dev/ee//ee/lib/ -isystem /usr/local/ps2dev/ee/ /ee/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -G 0 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -Я. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o In файл, включенный из ../../gcc/libgcc2.c:44: ../../gcc/libgcc2.h:242: внутренняя ошибка: Ошибка сегментации: 11 Пожалуйста, отправьте полный отчет об ошибке с предварительно обработанным исходным кодом, если это необходимо . См. инструкции. make[2]: * [libgcc/./_muldi3.o] Ошибка 1 make[1]: [libgcc.a] Ошибка 2 make: ** [all- gcc] Ошибка 2
Я начал искать в Google соответствующие отчеты об ошибках/исправления, но до сих пор ничего не решил. Думаю, я собираюсь сдаться. Еще раз спасибо за вклад.
AS=ee-as make? - person j4x schedule 02.02.2012