merge-with-binutils documentation is wrong/incomplete

[Markus Werle]

Alexandre Oliva wrote:

> On Mar 20, 2001, Markus Werle <markus@lufmech.rwth-aachen.de> wrote:
>
> > And - of course - the second option is wrong, too.
> > No one ever tested this before. I am really fed up with this bullshit.
> > Of course one has to link the stuff in subdirectories like
> > ./binutils-2.10.1/include/*
> > to the gcc tree, but files differ/conflict, files are already there.
>
> You shouldn't have to.  But the preprocessor in development snapshots
> and in gcc 2.96 that ships with Red Hat Linux 7 does pathname
> canonicalization, which breaks the way these includes used to work.
> Indeed, you need to create links in the include tree too, these days :-(

I think the only possible way to a gcc/binutils is still;

build binutils without gcc or with old-gcc
build gcc using those binutils
build binutils with new gcc

What makes me unhappy about this approach is the unnecesary duplications.

Johnny Normaluser cannot figure out a way through this version jungle.
This was OK for cvs snapshots (indeed no one expects clarity before
concept convergence).
But for a release, this chaos must vanish and one must be able to build
gcc/binutils at the same time like in the good old cygnus tree days.

So again:
a) Please tell me which version of binutils will not conflict with
gcc-2.95.3
    and how I can reach my goal: a working, rather stable version of
gcc/binutils.
    (btw.: what is the stage of the ELF c++-compiler on hpux-11.0?)

b) Please remove misleading documentation!!! Nothing worse than that.
   Better have no docs than those found on the webpage, really.
   It is too expensive to follow such a rubbish all the time.
   How do You want me to convince my colleagues/enterprise
   to use free software? I never found a gnu package where the docs were
   permanently outdated/wrong to such an extent like for gcc (except KDE
maybe)

   This leads to (preventable) disappointments again and again.

   And it injures the free software community, because all of it heavily
   depends on gcc. It is not funny at all to see 9 of 10 gcc-build-attempts
fail due
   to improper documentation or announcements that apply only to some
special
   versions on special platforms.

c) release gcc-2.95.3-with-binutils.tar.bz, soon.


Many thanks,


Markus


P.S.:
Apropos chaos: A funny idea to
* announce gcc-3.0
* have version number 3.1 on the cvs snapshots
* release gcc-2.95.3.

Let me summarize: The docs talk about A, the programmers do C,
the release is version B, but announced was D. Guess how I feel.

Or see the hpux stuff: configuring for hppa2.0w-hp-hpux11.00 does NOT
lead to a 64 bit compiler, which is in contradiction to hp's cc naming
convention:
The "w" stands for 64bit in the cc man page. Happy insider, sad newcomer.

quote from cc manpage:
Examples
                                         +DA1.1
                                         +DA867
                                         +DA2.0
                                         +DA2.0W
                                         +DAportable

                             The first two examples generate code for the
                             PA-RISC 1.1 architecture. The third example
                             generates 32-bit code for the PA-RISC 2.0
                             architecture. The fourth example generates 64-

                             bit code for the PA-RISC 2.0 architecture