AIX status

[David Edelsohn <dje at watson dot ibm dot com>]

	I have been investigating the AIX errors a little farther and
wanted to present the status in case anyone recognizes what is going
wrong. 

	I investigated the fill_n() undefined symbol.  local-inst.cc has
an implementation of the function with "unsigned int" as the second
argument.  localename.cc references the function with "unsigned long" as
the second argument.

	Because libtool builds the shared library with the linker flag
allowing errors, a shared library is generated, but it is not completely
correct and usable.  The AIX linker creates a dangling reference with the
assumption that some later runtime linking step will satisfy it.  Many of
the testsuite programs produce an executable when linked against the
shared library, but the resulting executable crashes in static
constructors when referencing the missing symbol.  When the testsuite
programs are linked statically, the linker generates the error that would
have occurred when creating the shared library if libtool had not allowed
errors. 

	Some testsuite programs which happen not to reference the missing
symbols do run correctly, but the missing symbols are the cause of most of
the AIX testsuite failures.

	The very last lines of locale-inst.cc are:

  template 
    locale::facet** 
    fill_n<locale::facet**, unsigned int, locale::facet*>
    (locale::facet**, unsigned int, locale::facet* const &);

Adding

  template 
    locale::facet** 
    fill_n<locale::facet**, unsigned int, locale::facet*>
    (locale::facet**, unsigned long, locale::facet* const &);

probably would solve one of the missing symbols.  However, I do not yet
understand why localename.cc expects that signature, who is suppose to
provide it, and why it is not being provided.

	Brilliant insights gratefully accepted.

Thanks, David