When I build a cross compiler, say from x86_64-unknown-linux-gnu to
i386-apple-darwin8.4.1, and have a directory in my PATH with "i386-
apple-darwin8.4.1-as" and "i386-apple-darwin8.4.1-ld", it appears
that the target-prefixed "ld" is found by collect2, but not the
target-prefixed "as" by the driver.
[EMAIL PROTECTED]:/tmp$ type i386-apple-darwin8.4.1-as
i386-apple-darwin8.4.1-as is /opt/odcctools/bin/i386-apple-
darwin8.4.1-as
[EMAIL PROTECTED]:/tmp$ type i386-apple-darwin8.4.1-ld
i386-apple-darwin8.4.1-ld is /opt/odcctools/bin/i386-apple-
darwin8.4.1-ld
[EMAIL PROTECTED]:/tmp$
[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -v -c test.c
Using built-in specs.
Target: i386-apple-darwin8.4.1
Configured with: ../gcc/configure --prefix=/opt/gcc-darwin --
target=i386-apple-darwin8.4.1 --with-sysroot=/MacOSX10.4u.sdk --
disable-libgomp --disable-libssp --disable-libgcc-math
Thread model: posix
gcc version 4.2.0 20060202 (experimental)
...
as -arch i386 -force_cpusubtype_ALL -o test.o /tmp/ccqadIjw.s
Assembler messages:
Fatal error: invalid listing option `r'
[EMAIL PROTECTED]:/tmp$
My expectation here was that since this is a cross-compiler built
with --target=i386-apple-darwin8.4.1, the driver would look for the
assembler as "i386-apple-darwin8.4.1-as" if it wasn't found in any of
the normal tool directories in $prefix/libexec/gcc or $prefix/
$target, etc. This does not seem to be the case, and a Linux ELF
assembler doesn't do me a lot of good. Note that I did not use --with-
ld/--with-as explicitly during configuration, so I expect directories
and paths to be searched at runtime.
However, what I find confusing is that collect2 implements the
algorithm as I expected it to:
[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -S test.c
[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-as -arch i386 -
force_cpusubtype_ALL -o test.o test.s
[EMAIL PROTECTED]:/tmp$ i386-apple-darwin8.4.1-gcc -o test test.o -Wl,-v
collect2 version 4.2.0 20060202 (experimental) (i686 Darwin)
/opt/odcctools/bin/i386-apple-darwin8.4.1-ld -dynamic -arch i386 -
weak_reference_mismatches non-weak -o test -lcrt1.o -L/opt/gcc-
darwin/lib/gcc/i386-apple-darwin8.4.1/4.2.0 -L/opt/gcc-darwin/lib/
gcc/i386-apple-darwin8.4.1/4.2.0/../../../../i386-apple-darwin8.4.1/
lib -L/MacOSX10.4u.sdk/usr/lib test.o -v -lgcc -lSystem
Apple Computer, Inc. version odcctools-590.18od10
[EMAIL PROTECTED]:/tmp$
This seems to be because collect2.c has:
#ifdef CROSS_COMPILE
/* If we look for a program in the compiler directories, we just use
the short name, since these directories are already system-
specific.
But it we look for a program in the system directories, we need to
qualify the program name with the target machine. */
const char *const full_ld_suffix =
concat(target_machine, "-", ld_suffix, NULL);
Now, my question is, why does collect2 implement its target tool
search by prefixing the target name, but the driver itself doesn't
when invoking the assembler? Should I file a bug to align all the
code that searches for target tools?
As an aside, the cross compiler successfully builds and links target
libraries because it uses:
[EMAIL PROTECTED]:~/gcc-build$ cat gcc/as
#!/bin/sh
exec /opt/odcctools/bin/i386-apple-darwin8.4.1-as "$@"
[EMAIL PROTECTED]:~/gcc-build$ cat gcc/collect-ld
#!/bin/sh
exec /opt/odcctools/bin/i386-apple-darwin8.4.1-ld "$@"
[EMAIL PROTECTED]:~/gcc-build$
I guess I'm asking for the driver to have parity with gcc's build
system, which prepends the target name for these tools
Shantonu
