64 bit compilers for x86-64, ppc, etc.

[Alan Modra]

On Tue, Apr 23, 2002 at 11:01:44AM +0200, Bo Thorsen wrote:
> It would be really great if this was all that was needed. I discussed
> something like this with Jan Hubicka about a month ago, and this was what
> he replied:
> 
> (quote)
> I think it is not the case.  I believe gcc.c has hardcoded it's
> own algorithm for finding the startup files. (see --print-file feautre)
> and that feature does overwrite whatever we do on the binutils side :(
> (end quote)

Well, yes, if you use %s in the gcc specs file, then gcc will search
for the startup files in the library search path.  eg. for
--prefix=/usr/local --target=powerpc64-linux --host=powerpc-linux
gcc looks in
 /usr/local/lib/gcc-lib/powerpc64-linux/3.1/
 /usr/lib/gcc/powerpc64-linux/3.1/
 /usr/local/powerpc64-linux/lib/powerpc64-linux/3.1/
 /usr/local/powerpc64-linux/lib/

and if the file is found, then the absolute path is given to the
linker.  Uh, oh, but you won't search in /lib64 or /usr/lib64,
and the linker doesn't use its search path to look for plain
files (as distinct from archives or shared libs).  _And_ if you
specify "/usr/lib64/crtn.o%s" in a specs file, then gcc doesn't
go looking in its library search path.  ie. it's the same as
writing "/usr/lib64/crtn.o".  That's a pain, because it would
be nice to have toolchain trees installed somewhere other than
the default "just work".

It seems to me that we really do need some tweaks to use
MD_STARTFILE_PREFIX and MD_STARTFILE_PREFIX1 for cross-compilers
like I do in
ftp://ftp.linuxppc64.org/pub/people/amodra/gcc-3.1/gcc-20020421-ppc64.diff.gz
(not the latest diff - I was trying to just use -Y in that one)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre