Re: [PATCH] PR other/32154

[Richard Sandiford <richard at codesourcery dot com>]

Adam Nemet <anemet@caviumnetworks.com> writes:
> Richard Sandiford <richard@codesourcery.com> writes:
>> Rask Ingemann Lambertsen <rask@sygehus.dk> writes:
>>>    Mipsisa64-unknown-elf doesn't try to link in any startup code or anything
>>> by default and thus doesn't fail. This hasn't changed and c,c++,objc and
>>> fortran still configures and builds.
>>
>> Right.  I'd very much like to keep it that way; as far as I'm concerned,
>> no gcc configury should depend on libgloss for this target.
>
> There is a unrelated failure I'm seeing with mipsisa64-elf with a
> combined tree.  strcasestr is detected missing in libgfortran because
> it seems that the link tests for this target don't even link to
> newlib.  Richard, your above comments seem to suggest that this is
> intentional.  Can you confirm, please?

Right.  The model used in libstdc++ is that this sort of link test
does not need to work for newlib targets; if we can't link a trivial
program, --with-newlib causes tests for C library functons to fall
back to known-good values.

The reason mips*-elf targets work the way they do is that the targets
support simulators and many different board types.  Each simulator and
board type needs a different "gloss" (which might be supplied by the
user, rather than taken from libgloss), and a program linked for one
system will usually not run on another.  Also, not all "glosses" provide
the same facilities.  For example, some have full file I/O support (real
or via semi-hosting), but others don't.

So, by design, mips*-elf does not link to a specific system by default.
The user should have to say specifically what target they are using.
I believe other configurations like powerpc-*-eabi work the same way
(as opposed to powerpc-*-eabisim, which as the name suggests,
links for the gdb simulator by default).

Richard