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:
> KAI C++ without all of its bugs and with all those nice template
> features of g++ would be the most suitable compiler for me ;-).
:-)
>> [1] 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;
> ??? We discussed merging of the both is not possible anymore ???
It sure is possible. That's precisely the way I build GCC snapshots
every week. There's even the uberbaum (sp?) pseudo CVS repo that is
precisely a merge of GCC and src.
I don't mean that it's trivial to set this up when building actual
releases of binutils and GCC, with their different release schedules.
In general, it works, but in certain cases it may fail. The soft-link
approach works best, but it won't work if you use GCC >=2.96 as the
bootstrap compiler.
>> [2] installing binutils first, then GCC, with the same prefix,
>> works;
> yep.
> Q: Is it ensured gcc will then _always_ use these binutils and no others?
Yep
> Q: can this behaviour then be overwritten with -B options?
Yep
>> [3] installing binutils first, then configuring GCC with a
>> different prefix, but pointing at the assembler and linker --with-as
>> and --with-ld works;
> THIS was not clear to me. Aha!
> explicit --with-as etc. is a MUST for binutils in different PATH?
PATH plays almost no role in searching for as and ld. This is
explained somewhere in the FAQ.
> Q: Is it ensured gcc will then _always_ use these binutils and no others?
Yep
> Q: can this behaviour then be overwritten with -B options?
Nope.
>> [4] installing binutils first, then creating links to
>> them in the tree in which GCC is going to be installed works too.
> does this mean:
> mkdir /opt/gcc-2.95.3
> mkdir /opt/gcc-2.95.3/bin
> ln -s /opt/binutils-2.10.1/bin/as /opt/gcc-2.95.3/bin/as
Creating the links in the bin directory may work, but that's not what
I do, so I can't vow for its correctness. The approach that works for
me is to create the links within .../lib/gcc-lib/<target>/<version>,
as described in the FAQ.
> Q: Is it ensured gcc will then _always_ use these binutils and no others?
Yep
> Q: can this behaviour then be overwritten with -B options?
Yep
> Q: can this behaviour changed after build?
You can always change the links, if you don't want to keep using -B.
> OK, this here is cited from Jeffrey A. Law:
> (Wed, 27 Sep 2000 on gcc-patches@gcc.gnu.org)
> "I do not encourage an explicit path to the assembler. Never have, never
> will. There are better ways to solve that problem."
> which made me think it was a deprecated approach.
It's not deprecated. I consider it a last resort.
>> 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.
> see Q:s above
See A:s above :-D
>> 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.
> really? I must read the docs more carefully. -B option never occured
> in the installation instructions, or did it?
Probably not. It's not the kind of thing we want to confuse new users
with. It's best to say: install both binutils and GCC with the same
prefix, and it will work. If you feel adventurous, you may want to
experiment with these other alternatives: [snipped].
>> It's just a matter of choosing the most appropriate for you, and doing it
>> right.
> yeah, doing it right. like described in the docs ...
Yep.
> say: I want a gcc with a distinct binutils in one prefix directory
> creating binaries that link _only_ against runtime libs of this
> prefix directory, and fail to run when another version of gcc is installed
This is a totally different problem. Shared libraries come with their
own set of system-dependent oddities. When you link a program with a
certain shared library, there's no guarantee that the same library
will be used at run-time. You have to provide this guarantee
yourself, by setting environment variables at link or run-time, or
passing additional flags to the linker so that it knows where to find
the library.
> "for gcc-2.95.3 the use of binutils-2.10.1 is recommended.
Except that binutils 2.11 is expected to be released in the near
future. And then, someone will complain that the docs are
out-of-date. Or, 1-2 years from now, someone will come asking whether
this ancient release of binutils is really necessary with GCC.
> hpux users please use recent cvs snapshots of binutils"
This kind of statement should always be accompanied by a date, so that
one can tell, two years from now, that they might no longer need a
recent CVS snapshot :-)
> If this statement is correct, could someone please merge it into
> the page mentioned.
Please post a patch for the web page to gcc-patches@gcc.gnu.org. See
http://gcc.gnu.org/cvs.html (particularly the last section) for details.
--
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