This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: egcs 1.0.1 i586-linux native test failures


Jeffrey A. Law writes:
>   In message <34F5B9B8.9876B649@shellus.com> you write:
>   > I think that Robert Brown brings up an important issue here.  I do
>   > find it rather inconvenient that binutils is not included with egcs,
>   > especially because on my system, I am unable to install either binutils
>   > or egcs in "a standard place" such as /usr/include or /usr/local/include.
> So configure them with the same --prefix option and believe it or not, it'll
> "just work" (famous last words)
You're right.  This does work.  In fact, that's what I've been doing. 
Although, of course, to make things work correctly, binutils must be compiled
and installed before gcc/g++ & libraries.

> 
>   > Would it be possible to include the latest binutils as a part of egcs,
>   > or is there some reason of which I'm unaware for not doing this?
> Long term I suspect binutils will be available from the egcs cvs server
> in some form or another.
> 
> The problem with including it is size and "where do you stop". Ie some
> folks could then validly claim we should include the debugger, then cross
> libraries like newlib, then all the support code (bison, flex, etc etc).
> Where do you draw the line.  And how big of a source dirstribution are
> you willing to make?
I would contend, however, that bison, flex, etc. and binutils are totally
different animals.  Bison, Flex, etc. are parts of the build-time support used
by the maintainers to create system-independent files which will be included in
the distribution.  The binutils utilities are runtime support which create
system-dependent files.  You could say that it's not absolutely necessary on
all systems to compile binutils in order to use gcc, but I've found that on
most systems it is either necessary or necessary in order to compile
non-trivial programs.

>   > include binutils.  After all, if we're going to include libstdc++, which is
>   > built by egcs, in the egcs distribution, don't we want to make SURE that
>   > we're using the correct binutils to build our libstdc++?
> libstdc++ is a little different -- it's totally impossible to use egcs
> without runtime libraries; furthermore, the runtime libraries need to
> be released in lock-step with the compiler.
> 
> That's rarely true for the assembler.
You could say that it's not absolutely necessary on all systems to compile
binutils in order to use gcc, but I've found that on most systems it is either
necessary or necessary in order to compile non-trivial programs.  And I've yet
to see a version of gcc that works with old versions of binutils on non-trivial
programs.  I agree that binutils isn't quite as much in lockstep with egcs as
is libstdc++, but it is nontheless a very important part of gcc.

-- 
Ian Haggard  ||  ian@shellus.com (work)  ||  IanHaggard@juno.com (home)
GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]