Why does cross gcc invoke native 'as'?

I am in the process of building the ps2 (playstation 2) toolchain for OSX using an existing script which worked fine for Linux/Windows in the past but has always been troublesome on OSX.

The problem I am facing right now is that I get to a point where cross gcc is apparently invoking the native 'as' instead of the existing cross 'as':

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/ -开发者_JAVA百科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: I don't understand 'G' flag! make[3]: * [__exp10.o] Error 1 make[3]: * Waiting for unfinished jobs.... FATAL:/usr/bin/../libexec/gcc/darwin/x86_64/as: I don't understand 'G' flag! make[3]: * [__adjust.o] Error 1 make[2]: [all-recursive] Error 1 make[1]: [all-recursive] Error 1 make: * [all-target-newlib] Error 2

The thing to notice here (sorry not very readable) is that ee-gcc is invoking 'as' from /usr/bin/../libexec/gcc/darwin/x86_64/as i.e the system native one instead of ee-as. How can this be ?

Checking the output of 'ee-gcc -print-search-dirs' I can see that ee-as is indeed in one of the specified paths and I checked that it is executable.

Might be hard to say anything about this without access to all data but maybe someone has an idea what I can look for - I don't understand how ee-gcc resolves its assembler to be the native one. How does the assembler binary selection work ?

UPDATE Thanks for the input but i'm afraid the whole thing is more broken than initially anticipated. Now gcc (llvm-gcc-4.2) is segfaulting while processing libgcc2.c

/Users/gilligan/Development/ps2dev/ps2toolchain/build/gcc-3.2.2/build-ee-stage1/gcc/xgcc -B/Users/gilligan/Development/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. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o In file included from ../../gcc/libgcc2.c:44: ../../gcc/libgcc2.h:242: internal error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[2]: * [libgcc/./_muldi3.o] Error 1 make[1]: [libgcc.a] Error 2 make: ** [all-gcc] Error 2

I started to google for related bug reports/patches but so far no dice. Guess i'm about to give in. Thanks again for the input.

---

Assembler path resolving is AFAIK in machine spec

 gcc -dumpspecs

and look to *invoke_as: section

You can override specs with -specs= option.