sid cgen cpus broken by absence of pic libiberty

[Jim Blandy <jimb@redhat.com>]

I think the SID build is broken for CGEN-based processors.

The libcgencpu.la library, built in sid/component/cgen-cpu, depends on
libiberty.  There are some occasional uses of xmalloc in tracedis.cxx,
but libcgencpu.la also uses files from libopcodes, which use the
"safe-ctype.h" character classification functions.  Fine.

Unfortunately, libiberty no longer builds PIC versions of its .o
files.  It used to, but there was long and highly confusing discussion
about how to fix things in December, which resulted in many large
patches, all of which were eventually reverted.  See the binutils
mailing list.  I can't find the discussion of why H.J. Lu reverted the
hard work he'd done getting libiberty to use libtool, but it sure
looked like a testing nightmare (AIX and an HP-UX x IA64 build were
both brought up as problematic cases).

And if there are no PIC libiberty objects, then libcgencpu.la
certainly can't use libiberty.

Since worthies much worthier than I have struggled with making
libiberty produce PIC object files and failed, I'm inclined to work on
making the opcodes stuff and sid no longer depend on libiberty.  It's
going to involve cringe-inducing patch hunks like this:

*************** cgen_parse_keyword (CGEN_CPU_DESC cd ATT
*** 216,222 ****
    /* Allow letters, digits, and any special characters.  */
    while (((p - start) < (int) sizeof (buf))
  	 && *p
! 	 && (ISALNUM (*p)
  	     || *p == '_'
  	     || strchr (keyword_table->nonalpha_chars, *p)))
      ++p;
--- 216,224 ----
    /* Allow letters, digits, and any special characters.  */
    while (((p - start) < (int) sizeof (buf))
  	 && *p
! 	 && (('a' <= *p && *p <= 'z')
!              || ('A' <= *p && *p <= 'Z')
!              || ('0' <= *p && *p <= '9')
  	     || *p == '_'
  	     || strchr (keyword_table->nonalpha_chars, *p)))
      ++p;

Does that sound reasonable (well, reasonable with a clothespin on the
nose) to folks?