Snapshot

Snapshot

[Jeffrey A Law]

Just so everyone knows -- I was waiting on the alpha patch and an osf4 
bootstrap
with that patch before spinning the snapshot.

The patch has been installed and the alpha-osf port is bootstrapping again.
I'll spin the snapshot this evening.

jeff

alpha-dec-osf4.0b problems (was Re: Snapshot)

[Axel Thimm]

On Tue, Jun 01, 1999 at 10:55:19AM -0600, Jeffrey A Law wrote:
> The patch has been installed and the alpha-osf port is bootstrapping again.
> I'll spin the snapshot this evening.

Unfortunately alpha-dec-osf4.0b still gets stuck on the problem I had
reported. What exact system have you been using? I used egcs 19990502 and gcc
2.7.1 for bootstrapping on an EV4.5 (21064). When I reported the problem some
time ago, Alexandre Olivia for instance wrote that he had no problems
compiling egcs on alphas, so I assume this is might be an OS revision problem.

> /amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/xgcc -B/amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/ -B/home/thimm/public/gcc-2.95_19990602/alpha-dec-osf4.0/alpha-dec-osf4.0b/bin/ -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/thimm/work/src/egcs/libiberty/../include /home/thimm/work/src/egcs/libiberty/vasprintf.c
> xgcc: Internal compiler error: program cc1 got fatal signal 11

Regards, Axel.
-- 
Axel.Thimm@physik.fu-berlin.de Axel.Thimm@ifh.de

Re: alpha-dec-osf4.0b problems (was Re: Snapshot)

[Jeffrey A Law]

  In message < 19990603194613.A4029@physik.fu-berlin.de >you write:

  > Unfortunately alpha-dec-osf4.0b still gets stuck on the problem I had
  > reported. What exact system have you been using? I used egcs 19990502 and g
  > cc
  > 2.7.1 for bootstrapping on an EV4.5 (21064). When I reported the problem so
  > me
  > time ago, Alexandre Olivia for instance wrote that he had no problems
  > compiling egcs on alphas, so I assume this is might be an OS revision probl
  > em.
  > 
  > > /amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/xgc
  > c -B/amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/ 
  > -B/home/thimm/public/gcc-2.95_19990602/alpha-dec-osf4.0/alpha-dec-osf4.0b/b
  > in/ -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/thimm/work/src/egcs/libiberty/../
  > include /home/thimm/work/src/egcs/libiberty/vasprintf.c
  > > xgcc: Internal compiler error: program cc1 got fatal signal 11
Can you repost the full testcase?  This is the case that Richard was
supposed to have fixed.

jeff

Re: alpha-dec-osf4.0b problems (was Re: Snapshot)

[Jeffrey A Law]

  In message < 19990603194613.A4029@physik.fu-berlin.de >you write:

  > Unfortunately alpha-dec-osf4.0b still gets stuck on the problem I had
  > reported. What exact system have you been using? I used egcs 19990502 and g
  > cc
  > 2.7.1 for bootstrapping on an EV4.5 (21064). When I reported the problem so
  > me
  > time ago, Alexandre Olivia for instance wrote that he had no problems
  > compiling egcs on alphas, so I assume this is might be an OS revision probl
  > em.
  > 
  > > /amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/xgc
  > c -B/amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/ 
  > -B/home/thimm/public/gcc-2.95_19990602/alpha-dec-osf4.0/alpha-dec-osf4.0b/b
  > in/ -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/thimm/work/src/egcs/libiberty/../
  > include /home/thimm/work/src/egcs/libiberty/vasprintf.c
  > > xgcc: Internal compiler error: program cc1 got fatal signal 11
Can you repost the full testcase?  This is the case that Richard was
supposed to have fixed.

jeff

alpha-dec-osf4.0b problems (was Re: Snapshot)

[Axel Thimm]

On Tue, Jun 01, 1999 at 10:55:19AM -0600, Jeffrey A Law wrote:
> The patch has been installed and the alpha-osf port is bootstrapping again.
> I'll spin the snapshot this evening.

Unfortunately alpha-dec-osf4.0b still gets stuck on the problem I had
reported. What exact system have you been using? I used egcs 19990502 and gcc
2.7.1 for bootstrapping on an EV4.5 (21064). When I reported the problem some
time ago, Alexandre Olivia for instance wrote that he had no problems
compiling egcs on alphas, so I assume this is might be an OS revision problem.

> /amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/xgcc -B/amd/titania/usr/scratch1/thimm/work/build/egcs/alpha-dec-osf4.0b/gcc/ -B/home/thimm/public/gcc-2.95_19990602/alpha-dec-osf4.0/alpha-dec-osf4.0b/bin/ -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/thimm/work/src/egcs/libiberty/../include /home/thimm/work/src/egcs/libiberty/vasprintf.c
> xgcc: Internal compiler error: program cc1 got fatal signal 11

Regards, Axel.
-- 
Axel.Thimm@physik.fu-berlin.de Axel.Thimm@ifh.de

Snapshot

[Jeffrey A Law]

Just so everyone knows -- I was waiting on the alpha patch and an osf4 
bootstrap
with that patch before spinning the snapshot.

The patch has been installed and the alpha-osf port is bootstrapping again.
I'll spin the snapshot this evening.

jeff

snapshot

[Jeffrey A Law]

Sorry about the goof'd snapshot.  One of the disks on the machine ran
out of space.  I've fixed that problem and respun today's snapshot.
jeff

snapshot

[Jeffrey A Law]

We had another file table overflow late in the snapshot process.  This
probably messed up the latest_snapshot tag as well as the readme and
hypertext links.  I'm fixing them now.

jeff

snapshot

[Jeffrey A Law]

We had another file table overflow late in the snapshot process.  This
probably messed up the latest_snapshot tag as well as the readme and
hypertext links.  I'm fixing them now.

jeff

snapshot

[Jeffrey A Law]

The automatic snapshot process wedged for some reason over the weekend. 

I've restarted it and we should have a fresh snapshot soon.

Jeff

snapshot

[Jeffrey A Law]

The automatic snapshot process wedged for some reason over the weekend. 

I've restarted it and we should have a fresh snapshot soon.

Jeff

snapshot

[Jeffrey A Law]

I fixed version.c in the 1997-11-22 snapshot and created new .tar.gz and
diff.gz files.

Jeff

Snapshot

[Jeffrey A Law]

Just a note, we're holding up the snapshot so that we can get a libio
patch based on HJ's stuff into the next snapshot.   Hopefully Ulrich
will fix the remaining problems later today/tonight (he's in Germany,
I don't know what kind of hours he usually works) and I'll make a snapshot
as soon as I hear from him.


--
Jeff Law (law@cygnus.com)
Cygnus Solutions		EGCS GNU Compiler System
http://www.cygnus.com		http://www.cygnus.com/egcs

Re: Snapshot

[Joe Buck]

> Just a note, we're holding up the snapshot so that we can get a libio
> patch based on HJ's stuff into the next snapshot.   Hopefully Ulrich
> will fix the remaining problems later today/tonight (he's in Germany,
> I don't know what kind of hours he usually works) and I'll make a snapshot
> as soon as I hear from him.

OK.  Please fix "make install" to clean out $prefix/include/g++ first;
otherwise users are testing a mixture of the current and previous
snapshots.

Re: Snapshot

[Alexandre Oliva]

Joe Buck writes:

> OK.  Please fix "make install" to clean out $prefix/include/g++ first;
> otherwise users are testing a mixture of the current and previous
> snapshots.

this is a bit dangerous, since this directory may be shared among multiple
architectures.  If one runs tests *after* installing gcc, as I do, it
may get random errors for Solaris2.5 and Linux (the fastest ones)
because the SunOS4.1.3 host decided to clean up include/g++

What if the clean-include step were not mandatory, or if it just
cleaned up files older than one day, for instance?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Snapshot

[Jeffrey A Law]

  In message < ork9fefhle.fsf@sunsite.dcc.unicamp.br >you write:
  > Joe Buck writes:
  > 
  > > OK.  Please fix "make install" to clean out $prefix/include/g++ first;
  > > otherwise users are testing a mixture of the current and previous
  > > snapshots.
  > 
  > this is a bit dangerous, since this directory may be shared among multiple
  > architectures.  If one runs tests *after* installing gcc, as I do, it
  > may get random errors for Solaris2.5 and Linux (the fastest ones)
  > because the SunOS4.1.3 host decided to clean up include/g++
Yup, it is dangerous -- Cygnus has run into problems with this kind of
stuff before.

However, we do need to find some way to address the problem of stale
files in the include installation directory.  Until we do I highly
recommend folks wipe it out before doing an install.

  > What if the clean-include step were not mandatory, or if it just
  > cleaned up files older than one day, for instance?
Well, another approach would be to issue a warning and demand user
intervention if files are found in the dir which aren't part of
the current distrubtion.  I don't know how feasible this is.

jeff

Re: Snapshot

[Alexandre Oliva]

Jeffrey A Law writes:

> Yup, it is dangerous -- Cygnus has run into problems with this kind of
> stuff before.

If include/g++ were installed in exec-prefix, or even in the
architecture-specific g++ directory, there would not be such problem.
Besides, it would allow one to have multiple versions of egcs'
libstdc++ installed, which is currently impossible, as one will
overwrite another.  With the expected include-files changes required
by the new template syntax, it might be quite annoying to have to keep
different directory trees just for the sake of preserving an old
version of g++.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Snapshot

[Jeffrey A Law]

  In message < orwwjedyu1.fsf@sunsite.dcc.unicamp.br >you write:
  > If include/g++ were installed in exec-prefix, or even in the
  > architecture-specific g++ directory, there would not be such problem.
I thought this had been discussed at one point.  I don't know what
ever came out of that discussion.

I used to run things like this at the UofU since we tended to
have multiple versions in use at the same time.

jeff

Re: Snapshot

[Alexandre Oliva]

Jeffrey A Law writes:

>   In message < orwwjedyu1.fsf@sunsite.dcc.unicamp.br >you write:
>> If include/g++ were installed in exec-prefix, or even in the
>> architecture-specific g++ directory, there would not be such problem.

> I thought this had been discussed at one point.  I don't know what
> ever came out of that discussion.

Probably, at that point, egcs did not even exist, and libstdc++ was
contained in an independent package.  It might not be that easy to
make sure it would be installed in the proper directory.  Now that
libstdc++ is distributed together with egcs, there's no reason for
keeping it where it is.

> I used to run things like this at the UofU since we tended to
> have multiple versions in use at the same time.

So do we at IC/Unicamp

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Snapshot

[Jeffrey A Law]

  In message < oru3eidxe2.fsf@sunsite.dcc.unicamp.br >you write:
  > Probably, at that point, egcs did not even exist, and libstdc++ was
  > contained in an independent package.
It was quite a while ago.  I don't remember how long -- certainly
before egcs was organized.
jeff