Re: Building binutils/gcc/glibc -

[Paul Eggert <eggert at CS dot UCLA dot EDU>]

[This is no longer relevant to libc-alpha, so I'm removing it from the
CC: list.]

"Zack Weinberg" <zack@codesourcery.com> writes:
> "Joseph S. Myers" <jsm@polyomino.org.uk> writes:
> > Zack Weinberg wrote:
> >> Nope - as noted downthread, the "portable alternatives" are not
> >> supported by some systems we support.

The potential problems I saw mentioned downthread were "sort -u" and
"diff -C3", but as mentioned in
<http://gcc.gnu.org/ml/gcc-bugs/2002-02/msg00542.html> the former
usage dates back to the 1970s and the latter is equivalent to "diff
-c", which also goes back that far.  The "diff -c" usage doesn't
really matter, since this diff is run only by the GCC releaser, so
it's only "sort -u" that's at issue as far as I know.

The "sort -u" issue is academic once GCC upgrades to libtool 1.5 or
later, as it solved the problem in a different way.  I can understand
GCC not wanting to upgrade libtool versions, though, and anyway the
reliability of "sort -u" is worth worrying about for other reasons, so
perhaps it's worth pursuing -- but see below.

> > What systems
> 
> Dan alleges some BSD, and I remember HPUX 10 was mentioned last time
> this came up.

This didn't come up in that thread, but googling revealed there is
indeed a bug in 4.3BSD "sort -u" on large inputs; see my former
colleague Corey Satten's 1992 report in
<http://staff.washington.edu/corey/sortbug>.
Perhaps this is what Dan was thinking about.

I couldn't find any reports about sort -u problems on HP-UX 10, but
perhaps I didn't try hard enough.

However, GCC already uses "sort -u" in several other places, which is
evidence that "sort -u" is safe to use now despite that long-ago bug.
If this evidence doesn't suffice, replacing all instances of "sort -u"
with "sort | uniq" will do the trick for ports to 4.3BSD.