libiberty configure fails on svr4/svr5 native

[Robert Lipe <robertl at dgii dot com>]

Depending upon the compiler used to bootstrap on SVR[45]/x86 hosts, you
might get mysterious linker failures during the gcc/stage2 build.  I'll
spare the exact failure modes unless they're important.

libiberty's configure script generates programs to test memcpy and
memset that optimize down to this:

int main()
{
        memcpy();
        return 0;
}


When the SCO, nee USL/USG/Univel/Novell, tools are handed this, they
emit a cryptic error:

UX:acomp: ERROR: "x.c", line 3: no actual for asm formal: z


This makes configure think that there is no memcpy.  Of course, there is
a memcpy but it actually wants to see arguments.  This makes configure
think there is no memcpy so it tries to provide one.  This makes the
native tools even less happy becuase it now knows we're trying to
override the highly optimized mem* brothers with C versions.  To make
matters worse, it seems to stick something in the .o when this happens
(possibly to trigger magic in the linker?) which will then fail to
resolve when gcc becomes the compiler talking to these sometime during
the the stage2 build.  To further confuse the issues, it only adds this
symbol when compiling this file with -g which, of course, the default
configure process provides.  If you _configure_ (but not necessarily
build) with gcc instead of the native cc, all is fine.

$ /udk/usr/ccs/bin/cc  -g -c  -I /play/egcs/include /play/egcs/libiberty/memc>
UX:acomp: WARNING: "/play/egcs/libiberty/memcpy.c", line 25: Function illegally defined in hosted mode: memcpy
(robertl) rjlhome:/play/tmp/x/libiberty
$ nm memcpy.o | grep abbr
[8]     |         0|       0|NOTY |GLOB |0    |UNDEF  |__abbr_table_1.0
(robertl) rjlhome:/play/tmp/x/libiberty
$ /udk/usr/ccs/bin/cc   -c  -I /play/egcs/include /play/egcs/libiberty/memcpy>
UX:acomp: WARNING: "/play/egcs/libiberty/memcpy.c", line 25: Function illegally defined in hosted mode: memcpy
(robertl) rjlhome:/play/tmp/x/libiberty
$ nm memcpy.o | grep abbr


What we have here is a case of too many pieces of software trying to
outsmart each other and the user loses.

I can think of a couple of ways to correct this.  None of them are
particularly pleasant.

1) Provide CFLAGS='nothing' in config/all_affected_targets. (Too many 
   targets and we don't know exactly what they are.)
2) Make configure pass arguments to these functions before testing.  
   (Requires changes to autoconf.)
3) Special case offending targets in libiberty/configure.in.  (See #1)
4) Document a workaround like hand-editing libiberty/Makefile between the
   configure and the make.  (Yuck.)


What's the best way to handle this?

RJL