This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-2.95.3 build failure with 2 different binutils
On Mar 22, 2001, Markus Werle <markus@lufmech.rwth-aachen.de> wrote:
> I would prefer improving the ergonomy of the docs instead of
> increasing the number of RTFM messages.
Sure! Don't let me hold you :-)
> It is a back and forth. What's "en vogue" today? It is a bazaar, right?
The idea is that you can use whatever you find more suitable for your
needs. Building both GCC and binutils in a single tree (such that
GCC uses the same binutils that's going to be installed along with it)
works; installing binutils first, then GCC, with the same prefix,
works; installing binutils first, then configuring GCC with a
different prefix, but pointing at the assembler and linker --with-as
and --with-ld works; installing binutils first, then creating links to
them in the tree in which GCC is going to be installed works too.
Choose whatever works best for you.
> How to get GCC to find the right as and ld was subject to changes
> for several times.
Nope. The only change was the introduction of --with-as and --with-ld
a few years ago, to ease the life of those who couldn't figure out how
to get GCC to find them otherwise.
> Once upon a time it was fine to configure --with-as=/path/to/as
It still is.
> In summer 2000 I learned from some hpux
> gcc developers that this method was deprecated on this platform
> and same prefix was preferred
In fact, I prefer the soft-links, so that I can install binutils and
GCC separately and still get them to work together. --with-as and
--with-ld won't always let you easily replace the assembler and linker
as freely. In particular, it isn't possible to change assembler and
linker using command line arguments such as -B.../, whereas not using
--with-as nor --with-ld will.
> It is even worse: It is not clear from the docs, whether
> configure --with-as=/path/to/as ensures the use of this as
> even when others occur first in PATH.
It does. Please contribute changes to make this clear in places where
you find it is not.
> I think the procedure of choosing the right binutils has not
> converged yet. The existence of 3 different approaches which "may"
> work is a strong hint on that.
All of the 4 approaches work. It's just a matter of choosing the most
appropriate for you, and doing it right. I hope it never converges to
a single one, because then you won't have the choice of having the one
most appropriate for your set-up.
> The configuration procedure should require the explicit definiton of
> which binutils to be used:
> ../gcc/configure --with-as-stage1=/usr/ccs/bin/as \
> --with-as-stage2=/opt/FREE-SOFTWARE/bintils-2.10.1/bin/as
I'm sorry, but I find requiring these flags a stupid idea. Besides,
it goes against the GNU Coding Standards, that say configure shouldn't
*require* any flags at all.
> IMHO the info about which binutils should be used with gcc-2.95.3
> should not reside in FAQ, but in the docs directly, e.g. like this:
> - binutils-X.XX (on hpux we recommend latest cvs ...)
Except that we don't recommend binutils on all platforms. Are you
volunteering to maintain this information in per-platform sections?
I find the FAQ much more appropriate for this kind of info, for the
very reason that the FAQ is easier to update.
> I ask again and again and again:
> which version of binutils is recommended for gcc-2.95.3?
> [ ] a cvs snapshot fro <date>
> [ ] binutils version __________
In general, it's expected that the latest release of GCC will work
with the latest release of binutils. However, it may be that GCC or
binutils don't support the platform on which you want to build. IIRC,
it's HP-UX 11, which GCC 2.95.* doesn't support. GCC 3.0 hopefully
will.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me