STARTFILE*PREFIX*SPEC question

[Steve Ellcey]

I have a question about the various STARTFILE macros.  I ran into a
problem where the compiler I was building would not work when I ran it
with an absolute path name (like /tmp/foo/bin/gcc) and tried to use a
shared libgcc (-shared-libgcc).  It would not find libgcc_s.so in this
case.  If I ran it with a relative path name (cd /tmp/foo; bin/gcc) it
worked fine.

I tracked this down to my use of STARTFILE_PREFIX_SPEC and a change in
gcc.c where

	if (*cross_compile == '0')

became

	if (*cross_compile == '0' && *startfile_prefix_spec == 0)

in the main program in gcc.c.  This caused a lot of directories to not
get added to startfile_prefixes which in turn caused me to not find
libgcc_s.sl during my link.  I am not sure why setting
startfile_prefix_spec affects the path used for finding libgcc, but it
does.

Now, I think STARTFILE_PREFIX_SPEC is being phased out because it is not
described in any of the doc files and only one other platform
(rs6000/linux64.h) defines it.  Is this correct?  Is this old (no longer
documented) or new (not yet documented)?

I tried to get rid of this and replace it with MD_STARTFILE_PREFIX but
ran into a problem, how do I make the location that I search for my
startfile (specified without a path in STARTFILE_SPEC) work with
MULTILIB stuff?  I see STANDARD_STARTFILE_PREFIX, MD_STARTFILE_PREFIX,
and MD_STARTFILE_PREFIX_1 but these are prefixes and not specs so how do
I make them vary based on the flags passed in to gcc?  I have a 32-bit
crt0 and a 64-bit crt0 in different directories and I have to pick one
or the other based on flags to gcc.  I am using the system crt files
(HP-UX IPF), not anything built with GCC.  I think I could work around
this by putting the directories I need in LIB_SPEC but that seems a bit
counter-intuitive.  Am I just missing something about how to set up
the various STARTFILE macros?

Steve Ellcey
sje@cup.hp.com