The attached patch removes the unused variables BUILD_CONFIGDIRS and
TARGET_CONFIGDIRS from Makefile.tpl. It also removes the
AC_SUBST(target_configdirs) from configure.in.
Boostraped on a GNU/Linux/x86
Rafael
2005-12-18 Rafael Ávila de Espíndola <[EMAIL PROTECTED]>
* Makefile.tpl (BU
On Fri, 16 Dec 2005, Richard Kenner wrote:
>> A wiki page that has the mapping from the old style to the new style
>> targets is appropriate. I know that I'll hit the, what is x called
>> now, and I too will be at a loss. Going back and reading the email
>> archives to find it would be
The top level bootstrap model is to rebuild all the useful bits of the
entire tree as a group; and repeat that as many times as necessary to
be able to compare them.
Please define "useful". I'm very concerned if we're doing more builds
than before and don't have a way to restrict the
On 18/12/2005, at 10:57 AM, Mike Stump wrote:
On Dec 17, 2005, at 10:27 PM, Andrew Pinski wrote:
On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote:
Yes; to do this right, GCC's builtins need to know about the
different names.
If you're interested in fixing this, I can tell you what to do
i use the gentoo flavor of linux and a recent install method has become
popular there. i myself have not done this and i do doubt the usefulness
of it but i want to check with the people who would know the most about
the basic tool-chain as it is called.
this is the install method
http://forums.gen
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
[...]
| We can bootstrap the assembler in a combined tree. The first stage's
| gcc will invoke a stage1 assembler, the second stage's gcc will invoke
| a stage2 assembler. This doesn't have any fundamental benefits except
| for thoroughness; it's an
On Sun, Dec 18, 2005 at 07:49:13PM +0100, Mark Kettenis wrote:
> Heh, the shell does set PWD, but does not export it. If I explicitly
> say "export PWD", before "make bootstrap" it seems to work.
Weird.
> > I've been considering disabling ln -s support. It's too fragile,
> > though this is the
On Dec 17, 2005, at 10:27 PM, Andrew Pinski wrote:
On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote:
Yes; to do this right, GCC's builtins need to know about the
different names.
If you're interested in fixing this, I can tell you what to do...
I figured out how to fix it and will be posti
On Dec 18, 2005, at 1:40 PM, Daniel Jacobowitz wrote:
We used to have some workarounds in the libcpp-to-gcc interface to work
around the fact that we built libcpp once, with the system compiler,
and then linked it to each stage of the bootstrap. Darwin had a system
compiler that disagreed with
> Date: Sun, 18 Dec 2005 11:49:37 -0500
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> > Looks like the new toplevel bootstrap infrastructure broke
> > bootstrapping on OpenBSD. I get a bootstrap comparison which is
> > caused by
On Sun, Dec 18, 2005 at 01:25:36PM -0500, Richard Kenner wrote:
> The answer to both of these questions is the same. Toplevel bootstrap
> deliberately - as a design decision, and in my opinion, a very good
> one - puts every stage in its own directory.
>
> Of course: we've always ha
The answer to both of these questions is the same. Toplevel bootstrap
deliberately - as a design decision, and in my opinion, a very good
one - puts every stage in its own directory.
Of course: we've always had each stage living in a different directory.
You're not going to get any
On Sun, Dec 18, 2005 at 01:01:11PM -0500, Richard Kenner wrote:
> Because it would have to recurse to the parent directory,
>
> Why do you have to recurse to the parent directory to bootstrap GCC?
> If the desire was to make pieces elsewhere, the command would have been
> issued from elsewher
And don't you think that talking about compatibility expected by our
users is just a little bit disingenuous, when you're talking about
running make inside the gcc subdirectory? Users don't do that!
Only developers of GCC do. It's only useful for incremental builds; a
full bu
(From http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html)
This patch is okay.
(Though please try to watch the sniping in the future, there is no need
to be uncivil).
On Sun, Dec 18, 2005 at 12:12:17PM -0500, Richard Kenner wrote:
> Backwards compatibility is indeed expensive, but is critical. All vendors
> do it and we need to as well. You can be certain that if there were six
> ways of specifying something in VMS on a VAX in 1979, all six will still
> work t
This shows pretty clearly that you haven't looked at it - the
basic bootstrap targets are about 10% of gcc/Makefile.in, which is
rather more than 30 lines.
You're right that I hadn't looked recently and it has indeed grown.
Certainly more than 30 lines, but not quite 10%: I count 375 o
On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> Looks like the new toplevel bootstrap infrastructure broke
> bootstrapping on OpenBSD. I get a bootstrap comparison which is
> caused by differences in the compilation directory encoded in the
> object files from different stages.
>
On Sun, Dec 18, 2005 at 08:28:13AM -0500, Richard Kenner wrote:
> Because the whole point of this process is to remove all the bootstrap
> logic from the gcc subdirectory, which is exactly where it doesn't
> belong. This will let us take major steps forward in our build process
>
> H
I recently had to build gcc 3.2.2 on an FC4 box. This failed using gcc
4.0.2 as the bootstrap compiler since gcc 3.2.2 uses no-longer-accepted
extensions. So I built gcc 3.4.5 using 4.0.2, and used that to bootstrap
3.2.2.
Now, if it is part of the release criteria that release N-1 must be
bu
On 12/18/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
> Richard Guenther <[EMAIL PROTECTED]> wrote on 15/12/2005 14:52:27:
>
> > On 12/15/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
> >
> > > So, in short - when can we assume that pointer types have the minimum
> > > alignment required by their
Richard Guenther <[EMAIL PROTECTED]> wrote on 15/12/2005 14:52:27:
> On 12/15/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
>
> > So, in short - when can we assume that pointer types have the minimum
> > alignment required by their underlying type?
>
> I think the C standard always guarantees this
Because the whole point of this process is to remove all the bootstrap
logic from the gcc subdirectory, which is exactly where it doesn't
belong. This will let us take major steps forward in our build process
How does *removing* something take major steps forward? The "whole
bootstr
Looks like the new toplevel bootstrap infrastructure broke
bootstrapping on OpenBSD. I get a bootstrap comparison which is
caused by differences in the compilation directory encoded in the
object files from different stages.
Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
24 matches
Mail list logo
