Re: AIX status

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

>>>>> Ulrich Drepper writes:

Ulrich> How it should work is that by default *all* platforms are second tier.
Ulrich> If somebody steps up and takes timely responsibilities for an arch/OS
Ulrich> combination, fine, it can be promoted.  This should happen once a
Ulrich> certain track record is established.  You see that this works for
Ulrich> Linux (almost all archs) and also Solaris.

	Please note that I tried discussing AIX pthread support back in
the beginning of May and sent a patch, but received no response.  I then
inquired again during June, but received no response. 

Ulrich> David's attitude is not helping here at all.  He simply demands that
Ulrich> AIX is handled by those who are working on other architectures (one of
Ulrich> the arguments is, btw, that you, Mark, made a working AIX port a
Ulrich> release criteria for gcc).  This is plainly wrong.  People working on
Ulrich> the code have no obligation at all for non-existing ports.  If
Ulrich> somebody has an interest in seeing a port done s/he has to do it
Ulrich> her/himself or pay somebody to do it.

Ulrich> This is not what happens here.  Far too many people have to work on
Ulrich> the AIX stuff even though it's not in their interest.  At this point
Ulrich> it is also important to notice systems which disrupt the source code
Ulrich> base too much.  Sharing as much code as possible is good, but if a
Ulrich> system is simply too different separate files must be used.  The
Ulrich> libstdc++ directory structure was designed to allow exactly this (it's
Ulrich> largely based on what we do in glibc).  I.e., simply have the new port
Ulrich> create a new file instead of polluting existing code with tons of
Ulrich> #ifdefs and similar bestialities.

	AIX is fully supported in libstdc++-v2; v3 should not be a step
backwards.  In that sense, it is not a completely new, non-existent port
at all, so that is misleading.

	From the beginning, all that I have been asking for is a flexible
framework for portability and a discussion of a design for acceptable
patches given the AIX requirements.  Without that, the port developer is
being asked to waste his or her time stumbling around in the dark creating
patches which are sure to be rejected.  The maintainer needs to take the
lead on the overall design framework given his or her broader view and
discuss an approach with the developer.  Then the developer can step in
with one or more proposed implementation within that framework, as I have
done for AIX pthread support in acinclude.m4.  One cannot do this work
alone without the guidance of the maintainers.  One should not have to pay
the maintainers for them to be engaged in the discussion.

	I have not proposed one set of #ifdef's to the libstdc++ sources
as a solution.  I have explained what symbols and macros I have needed to
provide in the interim as a means to explore solutions.  So far all of the
patch proposals have been limited to acinclude.m4, os_defines.h, and
mknumeric_limits (which already has a special case for CYGWIN), so I only
am affecting parts of libstdc++ intended to handle system dependencies and
not poluting anything.  Another misleading statement and inaccurate
portrayal of me.

	There are AIX patches for libtool actively being developed in the
community, so that complaint is a red herring as well.

	If libstdc++-v3 is intended to be a portable C++ library for GCC,
then it needs to be designed that way from the beginning.  This means that
the libstdc++ maintainers need to be willing to engage the port
maintainers from the beginning and incorporate portability features and
requests.  If the library is not intended to be portable, then it should
not be proposed as a general replacement for v2.

	Placing all of the blame on me and AIX and Mark and the GCC
Steering Committee is incorrect.  As before, I will ignore your baiting
personal attacks and questioning of my motives.

David