[PATCH] PR other/32154

[Rask Ingemann Lambertsen]

On Sat, Jun 23, 2007 at 09:18:12AM +0100, Richard Sandiford wrote:

> 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.

   It doesn't work that way (any more). If your linker exits with a non-zero
exit code linking a trivial program, then libstdc++ fails to configure. It
was like this four years ago also, see bug 12019.

   For mipsisa64-elf, the linker only warns that _start wasn't found and
exits 0, so configure seems to work. That could be a bug or pure fluke; I
don't know. I would not have been surpriced had the linker errored out
because e.g. _exit wasn't found.

> 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.

   The patch does not change what is linked in by default, it only sets up
search paths to be used during the build process, so that target libraries
can be built. I suppose this (the patch + --with-newlib) isn't much
different from using --with-(build-)sysroot if you have a pre-built newlib.

   Just to ensure that we are on the same page: The patch is for the top
level configure.ac.

-- 
Rask Ingemann Lambertsen