egcs-970828: Some nits

egcs-970828: Some nits

[Horst von Brand]

- At least with gcc-2.7.2.2.f.2 under Linux, it won't build by 'make': The
  spec file created in .../gcc/ is picked up by gcc (?!), which doesn't
  like it at all. Workaround is to copy gcc's spec in there, and build by
  hand (stage by stage): First stage, then 'rm spec; make spec' and then
  second and third stages. 'make compare' is silent for '-O2
  -fomit-frame-pointer -mpentium' here.
- Line 2201 of ...gcc/invoke.texi contains your address with a single '@'
  in it, makeinfo chokes on that and kills the installation
- It would be nice to install as something like 'gcc-2.8.0' &c, so it
  doesn't kill your setup
- What happened to the ChangeLog files? I've only got .10 and .11 for gcc,
  it seems a lot of history got lost...
- The output of './configure --help' isn't the most helpful ;-)
- Please don't bundle this much stuff into the distributions, you might as
  well assume people are able to get texinfo &c on their own.

OK, let's test this baby some now.  Seems that executables/objects are
somewhat larger than my older gcc with '-O2 -fomit-frame-pointer -m486
-malign-{jumps,loops,functions}=2' (standard kernel compile options),
compared to '-O2 -fomit-frame-pointer -mpentium' on the new one.  At least,
gcc has learned to count malign entities by itself now ;-)
--
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viqa del Mar, Chile                               +56 32 672616

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message < 199709030345.XAA26447@sleipnir.valparaiso.cl >you write:
  > - At least with gcc-2.7.2.2.f.2 under Linux, it won't build by 'make': The
  >   spec file created in .../gcc/ is picked up by gcc (?!), which doesn't
  >   like it at all.
OK.  We've had a couple reports of a similar problem, so we need to track
this down.


The first thing we should do is make sure your gcc-2.7.2.2.f.2 has a properly
installed specs file.

Can you look in the gcc-lib/<config>/<version> directory for your 2.7.2.2.f.2
install and verify that it has a specs file?

  > - Line 2201 of ...gcc/invoke.texi contains your address with a single '@'
  >   in it, makeinfo chokes on that and kills the installation
Yup.  It'll be fixed for the next snapshot.

  > - It would be nice to install as something like 'gcc-2.8.0' &c, so it
  >   doesn't kill your setup
I think the way to do this is to use the --prefix option to install the
binaries into a different location.  egcs  is _not_ gcc-2.8.

  > - What happened to the ChangeLog files? I've only got .10 and .11 for gcc,
  >   it seems a lot of history got lost...
All ChangeLog files before gcc-2.7.2 have been purged to reduce the size of
distributions.  Odds are we'll put the old ones on the ftp server for those
folk that want to review them.

  > - Please don't bundle this much stuff into the distributions, you might as
  >   well assume people are able to get texinfo &c on their own.
I disagree.  The more self contained the distribution is the more likely it
will work out of the box, which makes it more appealing to most folks.

Including texinfo is actually smaller than including all the .info* files.

Jeff

Re: egcs-970828: Some nits

[Wolfgang Schludi]

> From: Jeffrey A Law <law@hurl.cygnus.com>
>   In message < 199709030345.XAA26447@sleipnir.valparaiso.cl >you write:
[...]
>   > - Please don't bundle this much stuff into the distributions, you might as
>   >   well assume people are able to get texinfo &c on their own.
> I disagree.  The more self contained the distribution is the more likely it
> will work out of the box, which makes it more appealing to most folks.
> 
> Including texinfo is actually smaller than including all the .info* files.
> 
Jeff,

I also dislike the fact that installing egcs "corrupts" my
rpm-database (yes, I prefer installing the "original" texinfo package)

Why not let the user decide whether additional tools should be
installed? (perhaps with one or more configure- or make- flag)

Wolf

-- 
schludi@syscomp.de

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message < m0x6WMY-000RieC@ra >you write:
  > I also dislike the fact that installing egcs "corrupts" my
  > rpm-database (yes, I prefer installing the "original" texinfo package)
Actually, you'll find the next snapshot will _not_ install texinfo
as it's an old version and is only included so that the info files
can be recreated.

Jeff

Re: egcs-970828: Some nits

[Joe Buck]

> Actually, you'll find the next snapshot will _not_ install texinfo
> as it's an old version and is only included so that the info files
> can be recreated.

If it isn't going to be installed, we might want to include only the
makeinfo program, leaving out the info reader and the Emacs macros.  Only
the texinfo/makeinfo directory is needed, plus a change to link against
libiberty.a instead of libtxi (libtxi is just a subset of libiberty and
can go away).

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message <199709040329.XAA05067@sleipnir.valparaiso.cl>you write:
  > Yep, the specs file is correctly installed.
Very strange since neither Jim nor myself can figure out how/why 
a gcc-2.7 vintage compiler could die in this manner.

It is interesting to note that his has happened only for linux folks.
Makes me wonder if there's some braindamage going on in one of linux
config files from gcc-2.7.

  > OTOH (and this is more serious, IMHO) is the problem that make builds _all_
  > languages for the first stage. Happened to me with sparc-sun-solaris2.5.1,
  > gcc-2.7.2.3; but not here on Linux for egcs-970901 built with egcs-970828.
  > Not nice (couple hours grinding away...), might blow up in your face with
  > non-gcc compilers.
Yes, we're aware of the problem.  You can stop this by using LANGUAGES=c
when building.

I'm thinking about adding a "bootstrap" target at the toplevel that heads
into the gcc tree first, does a 3stage on gcc, then builds the rest of
the tree.

Regardless, this is something we know has to be fixed before the first
public release.  Since nobody else is working on it, I'll probably just
implement my solution for the next snapshot since it's important.

  > > I think the way to do this is to use the --prefix option to install the
  > > binaries into a different location.  egcs  is _not_ gcc-2.8.
  > 
  > You are right.
Another alternative is to go ahead and install it without the --prefix and
use -V to select different versions of the compiler.

  > OK, I understand that. But the ChangeLog files I see start rather late, and
  > I gather that there were changes that got lost. Or am I wrong here?
Not sure exactly what you mean.  The old ChangeLog files were purged and
thus "lost" (though we have copies and probably will make them available
separate from the main distribution).

gcc/ChangeLog.10 and gcc/ChangeLog.11 cover changes in the gcc2 tree from Nov 1995
(gcc-2.7.2 release) to the present.  gcc/ChangeLog covers the changes we've
made to egcs since we forked from the gcc2 development tree.

  > You are absolutely right. I was thinking about the snapshots, but now
  > thinking it over it is easier on the developers to carry everything around
  > and not have to add it at the end. Dismiss it as the selfish thoughts of a
  > prospective mirror ;-)
As developers, we sometimes lose sight of the so called "out of box experience".

gcc has been successful with developers because they're willing to go find
all those dependencies and pick up makeinfo, bison, gnu make, etc etc.

For egcs/gcc to take the next step forward we have to do a better job
at packaging -- it literally as to be as simple as unpack, configure, make
make install to get a fully functional toolchain.  Hell, it might even
need to be simpler than that :-)

  > OK, OK, I give up.  Must have been sleeping when I mailed you.
No problem :-)

Thanks for the feedback.
Jeff

Re: egcs-970828: Some nits

[H.J. Lu]

> 
>   In message <199709040329.XAA05067@sleipnir.valparaiso.cl>you write:
>   > Yep, the specs file is correctly installed.
> Very strange since neither Jim nor myself can figure out how/why 
> a gcc-2.7 vintage compiler could die in this manner.
> 
> It is interesting to note that his has happened only for linux folks.
> Makes me wonder if there's some braindamage going on in one of linux
> config files from gcc-2.7.
> 

What problem with Linux? I didn't see any, except for the libstdc++
one, which I have sent in patches for.

FWIW, I always use gcc 2.7.2 to bootstrap. Maybe I should use 2.7.2.3
now.

H.J.

Re: egcs-970828: Some nits

[David Bristow]

> 
> I'm thinking about adding a "bootstrap" target at the toplevel that heads
> into the gcc tree first, does a 3stage on gcc, then builds the rest of
> the tree.
> 
Please make this delete stage1 when stage2 is finished, so that you don't
have to have stage{1+2+3} worth of free disk space to do this in.

David Bristow
dbristow@lynx.dac.neu.edu

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message < Pine.LNX.3.95.970904211942.7585A-100000@xanadu.bogus.org >you write:
  > Please make this delete stage1 when stage2 is finished, so that you don't
  > have to have stage{1+2+3} worth of free disk space to do this in.
It's an interesting thought; though I'm not sure if it's the best thing
to do.

There's plusses and minuses for keeping and deleting the stages as
soon as possible.  Either way there'll be a group of folks that won't
be happy.

My general feeling is to leave the stage? files until they're either
removed by a make clean, or possibly after a successful 3stage + compare.

I would think the folks that need this would be in the minority, and
there _are_ ways to do this which we could document.

Jeff

Re: egcs-970828: Some nits

[Horst von Brand]

Jeffrey A Law <law@hurl.cygnus.com> said:
[...]

> gcc has been successful with developers because they're willing to go find
> all those dependencies and pick up makeinfo, bison, gnu make, etc etc.

True. And linux from the shelf below ;-)

> For egcs/gcc to take the next step forward we have to do a better job
> at packaging -- it literally as to be as simple as unpack, configure, make
> make install to get a fully functional toolchain.  Hell, it might even
> need to be simpler than that :-)

Yes. And no. Maybe.

There _has_ to be a way of not messing up something else (texinfo is at 2.9
in egcs, I used to have 2.11 :-).

To have a toolchain-x.y.z.tar.gz of 200Mb won't go down easy on folks (egcs
is nearly 10Mb now, and that is _huge_. What if I don't want make? Or
Objective C? Or Pascal, FORTRAN, whatever?).  There will be several
separate packages, and to upgrade gui-development-x.y to x.y+1 just because
a new texinfo came out is ridiculous.  The phenomenon of
lagging-behind-packages is to be seen today, specially wrt texinfo.tex and
some elisp files, and there isn't any easy answer to that...

> Thanks for the feedback.

Just trying to give a bit back.
--
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viqa del Mar, Chile                               +56 32 672616

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message < 199709050339.XAA02007@sleipnir.valparaiso.cl >you write:
  > There _has_ to be a way of not messing up something else (texinfo is at 2.9
  > in egcs, I used to have 2.11 :-).
You should find that texinfo is no longer installed as of the 970904
snapshot.  It is built for internal use during the egcs build only.

We'll be upgrading texinfo after we get the first release out the door.

  > To have a toolchain-x.y.z.tar.gz of 200Mb won't go down easy on folks (egcs
  > is nearly 10Mb now, and that is _huge_.
Yup.  That's the driving force behind breaking out the different languages and
runtimes.  That'll save folks from having to ftp, build and install languages
they don't care about (or testsuites).

The process isn't complete, but it's well under way.

Simliarly for removing old ChangeLogs from the distribution -- most folks
don't care about changes made 2+ years ago.

Once you get the languages split out, the major component of the distribution
is the config files which we'll have ot start thinking about.

Jeff

Re: egcs-970828: Some nits

[meissner]

| > I'm thinking about adding a "bootstrap" target at the toplevel that heads
| > into the gcc tree first, does a 3stage on gcc, then builds the rest of
| > the tree.
| > 
| Please make this delete stage1 when stage2 is finished, so that you don't
| have to have stage{1+2+3} worth of free disk space to do this in.

On the other hand, if you don't keep all three directories around, it can make
it mightly hard to debug when things go wrong.  I find bootstrapping with
-save-temps helps even more (again at a cost in disk space).  Every thing in
life is a tradeoff.

Re: egcs-970828: Some nits

[Joe Buck]

> On the other hand, if you don't keep all three directories around, it
> can make it mightly hard to debug when things go wrong.  I find
> bootstrapping with -save-temps helps even more (again at a cost in disk
> space).  Every thing in life is a tradeoff.

Developers often have lots of space, but end users are often very short
of disk space (Linux folk especially).  When we ship, bootstrapping should
just work.

To satisfy both types of users, there could be two targets or an option
to conserve disk space.

Re: egcs-970828: Some nits

[Jeffrey A Law]

  In message < 199709050150.SAA16538@atrus.synopsys.com >you write:
  > Developers often have lots of space, but end users are often very short
  > of disk space (Linux folk especially).  When we ship, bootstrapping should
  > just work.
True, but sometimes it doesn't, regardless of how much testing is done.

  > To satisfy both types of users, there could be two targets or an option
  > to conserve disk space.
That sounds reasonable; I'd happy accept a makefile fragment to do that...

jeff