This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: RHL 7.0
From: Ivan Jager <ivanjager@bigfoot.com>
Date: Sat, 30 Sep 2000 20:35:29 -0400
I finally finished downloading Red Hat Linux 7.0. I
repartitioned my HD and did a complete install.
During the installation one thing I noticed was that every
time I pressed F1 it would say the help for that was not
available. Is that only because I was doing an FTP install?
I remember RHL 5.2 had help. The help for the packages was
especially useful.
I also noticed kernel 2.2.16. I had been expecting 2.4.*,
but I guess Red Hat didn't want to wait.
I played around a little, then decided to get something
done. I tried to use MySQL, but /var/lib/mysql/ doesn't have
the right permissions. I fixed that with a chmod +rx
/var/lib/mysql/ . Why does Red Hat call the package "mysql"
instead of "MySQL" like the RPMs from http://www.mysql.com/
? That was ~3.5 hours after installing. Makes me wonder how
much testing Red Hat does.
The MySQL bug was already reported at bugzilla, and there
were supposedly some updates, but the updates directory in
ftp://ftp.redhat.com/pub/redhat/releases/guinness/ and in
the mirrors is also lacking read permissions. (so I couldn't
test them) (not to mention it is difficult to log in)
===
Subject: Re: RHL 7.0
From: Craig Kelley <ink@inconnu.isu.edu>
Date: Tue, 3 Oct 2000 09:50:15 -0600 (MDT)
On Sat, 30 Sep 2000, Ivan Jager wrote:
> I finally finished downloading Red Hat Linux 7.0. I repartitioned my HD and did a complete install.
>
> During the installation one thing I noticed was that every time I
> pressed F1 it would say the help for that was not available. Is that
> only because I was doing an FTP install? I remember RHL 5.2 had help.
> The help for the packages was especially useful.
I noticed this as well.
Some other observations: I upgraded my pinstripe which had
kernel-2.2.16-17. RedHat 7.0 installed kernel-2.2.16-22 but anaconda did
not run lilo (even though I remember saying 'linear' mode and all). So, I
had to use the rescue disk to get it up (kudos to the new FTP
rescue!). The fstab had been modified; there was only one kernel image in
there where once there was three; but it looked like this:
image=/boot/vmlinuz-2.2.16-16
label=linux
read-only
root=/dev/sda2
initrd=/boot/initrd-2.2.16-22.img
strange, eh? A quick edit fixed the situation.
===
Subject: RE: RHL 7.0
From: "Barry Smoke" <barry@arhosting.com>
Date: Tue, 3 Oct 2000 12:22:23 -0500
My installation did the same...
Upon rebooting, I had my old kernel boot, which completely messed up all
modules,
edited lilo.conf,
/sbin/lilo
rebooted,
depmod,
couple more reboots,
finally started working correctly.
RH7.0 broke my x ...still haven't gotten it back up yet,
I can't recompile the kernel...
bugs..bugs..bugs..
===
===
Subject: about 7.0 and gcc 2.96
From: Levente Farkas <lfarkas@mindmaker.hu>
Date: Thu, 12 Oct 2000 16:57:00 +0200
hi, first of all I don't know the overall quality of 7.0
since I'm just come back from my vacation, but I read many
mails and news about in which people are criticize red hat
why they include gcc 2.96 in 7.0. it seems to me in the
last few years that there are just a few people who are
using c++ on linux, but this seems more obvious after these
responses. those who realy would like to use c++ first need
a good c++ compiler. linux do not have any good (free) c++
compiler. egcs is not one of them. it's very limited on the
filed of template, exception, namespace... those who realy
argue have to look at more carefuly about it. gcc-2.96 which
is not realy exists are much better, those who realy wanna
use c++ with all of it feature would have be happy red hat
finally include it in their distribution. if I were rh I
even include libstdc++-v3 which is another essential part of
a good c++ developer enviroment. now since v3 is the
default stdc++ library in gcc I hope next rh distro will
include a 'complete' standard c++ developmnet enviroment.
ps. yes I know about the binary compatibility and the new
ABI differencies, but than we can say rh have to include
libc-5 and not glibc or glibc2.0, not glibc2.2 like now
(glib2.1.9x is 2.2:-) and not the 2.4 kernel series...
sometime have to change to the newer and it's high time
now. when rh switch to glibc or elf from a.out than it was a
good decision. sooner is better.
===
Subject: Re: about 7.0 and gcc 2.96
From: John Summerfield <summer@OS2.ami.com.au>
Date: Fri, 13 Oct 2000 01:58:21 +0800
> first of all I don't know the overall quality of 7.0 since I'm just come
> back from my vacation, but I read many mails and news about in which
> people are criticize red hat why they include gcc 2.96 in 7.0.
gcc 2.96 is a development version. Its authors say it's not
ready for release.
I don't think there would have been any argument had gcc
2.96 been put amongs the preview pacakges. However, RHI has
chosen to build the entire distribution with it (kernel
excepted) and has shipped two compilers anyway.
What I find unsettling it the number of packages reshipped
already; the fact so many problem packages have been found
already suggests to me there are lots more to be found. Not
just obscure packages that hardly anyone uses either; glibc
is amongst them.
> ps. yes I know about the binary compatibility and the new ABI differencies,
> but than we can say rh have to include libc-5 and not glibc or glibc2.0,
libc5 should indeed be included, but not as the base libc,
but for applications users already have and which work
well. Not everyone wants to go through the process of
recompiling and retesting their applications just to move
from RHL 5.x to 7.x.
IN some cases, it's not an option; even Linux users use code
that comes in binary-only.
===
Subject: Re: about 7.0 and gcc 2.96
From: jfm2@club-internet.fr
Date: Thu, 12 Oct 2000 23:44:42 +0200 (CEST)
> > first of all I don't know the overall quality of 7.0
> > since I'm just come back from my vacation, but I read
> > many mails and news about in which people are criticize
> > red hat why they include gcc 2.96 in 7.0.
> gcc 2.96 is a development version. Its authors say it's
> not ready for release.
gcc 2.96 is a snapshot plus heavy patches. You could (or could not)
consider that it is alike a production kernel where the code freeze
has taken place before the official one by Linus. Not necessarily
unstable but due to the fact this gcc is not official it has not got
the same kind of post-release testing by users that an official gcc
would have got. It only has got in house testing. This problem (of
relative lack of testing) could have lightened if RH had anoounced in
advance that this gcc would be the "next one". Given that it is not
unusual that RedHat rolls back certain features of its betas I for one
didn't pay much attention to the gcc in pinstripe and I didn't try to
push it too hard.
Also gcc 2.96 at the testsuite are far better than those of gcc 2.95.
This could suggest that it is much better than people suggest. You
could however wait a bit before using it for important things until
other people have really tried it.
> I don't think there would have been any argument had gcc
> 2.96 been put amongs the preview pacakges. However, RHI
> has chosen to build the entire distribution with it
> (kernel excepted) and has shipped two compilers anyway.
> What I find unsettling it the number of packages reshipped
> already; the fact so many problem packages have been found
> already suggests to me there are lots more to be
> found. Not just obscure packages that hardly anyone uses
> either; glibc is amongst them.
This is not necessarily a gcc problem. You have to analyze the nature
of the problems before saying it is. In 5.0 RH took a lot of flak for
moving to glibc but when you look at the problems most of them were
not related to it. It looked more like if the move to glibc had
stretched RH resources to the point the building and testing of other
programs was affected.
===
Subject: About 7.0 and gcc 2.96
From: Mario Torre <mario.torre@katamail.com>
Date: Fri, 13 Oct 2000 01:39:22 +0200
I have finally installed the 7.0 and I have found it has al
ot of bugs. Too many. Anaconda dies when I try to install
files from both the CDs, I have updated the floppy iso from
the update ftp directory, but I have I have not installed it
again to test. I hope there is no need to reinstall
everything, but, please, tell me if the basic installation
compromise the file system. LPD doesn't find the road for
the hostname if I use not the standard localhost. And, even
if I don't change my host name, it doesn't seem to work
(printer do not print). Pop3 doesn't works. I have
installed a pop3 server to work with netscape for multiple
e-mail, it worked on RedHat Linux 6.2, Slackware, Mandrake
... When called, the pop3 seems to die. Note that pop3 is
configured correcly, it is not a bug of my pop3 daemon, I
thing it is a bug in the tcp daemon, that is called by the
pop3 program:
>From the INSTALL file, for the inetd.conf:
pop3 stream tcp nowait root /usr/sbin/tcpd popa3d
RedHat L.7.0 uses xinetd, but the differences in
configuration are not so difficult to understand.
I use the popa3d-0.4 from openwall.
Even if it cannot be attribuited to RedHat, the netscape pkg
die when you chose ADDRESS in the Composer, and then click
on a name and chose TO.
RHL 6.2 had not this problem, Mandrake 7.0 had, but was
fixed in the 7.1 release.
While these problems are significants, they may be fixed by
providing simple patches, so nothing very important - a
little more beta testing is not so hard to do.
And I think you are making beta testing with real users with
the 7.0 release, so you can prepare yourself with the 8.0,
that will be, probabily, your next release, with gcc3,
kernel 2.4, kde2 and gnome revisited.
I think I'm not so far from the truth...
But it is not a bad thing, as who works with the RedHat
Linux probabily have not upgrade to the 7.0, as it is not
secure as it should be.
But the worse problem, is that I cannot compile a kernel. I
have used kgcc, I have edited the Makefile, used gcc, but
nothing to do. Kernel compile errors somewhere, I have not
take track of the bug, but I will do tomorrow, when I will
try to re-compile the kernel with the gcc-2.95.2, as it is
recommended.
A notice, may be something that's about my system only, but
the new GnoRPM should have a bug somewhere, cause it dies
when I ask to install a new pkgs. I have upgraded to the new
version, but it is worse than the previous one (it says
seg-fault).
Ah, something wrong there is also in the xemacs (it takes
too much time to run...) and in some packages of the
Powertools CD. But these are very minor problems, normal
problems even of a great release.
I think, anyway, that you should fix those bugs, above all
the gcc/kgcc problem, the tcp and the lpd problem, and the
netscape should not be bad...
Hope to be useful to you all, I have enjoyed with RedHat,
and I have used it, debug it, and I will use it in future,
but I need to work, not to amuse myself with problems.
Thanks to RedHat and to the Open Source, and good work.
===
Subject: Re: about 7.0 and gcc 2.96
From: Matt Wilson <msw@redhat.com>
Date: Fri, 13 Oct 2000 01:05:32 -0400
On Fri, Oct 13, 2000 at 01:58:21AM +0800, John Summerfield wrote:
>
> What I find unsettling it the number of packages reshipped already;
> the fact so many problem packages have been found already suggests
> to me there are lots more to be found. Not just obscure packages
> that hardly anyone uses either; glibc is amongst them.
Note that none of these packages have been re-released because of
compiler problems. The glibc fixes are mainly to repair broken
backwards compatibility, not necessarily bugs in new functionality.
> > ps. yes I know about the binary compatibility and the new ABI differencies,
> > but than we can say rh have to include libc-5 and not glibc or glibc2.0,
>
>
> libc5 should indeed be included, but not as the base libc, but for
> applications users already have and which work well. Not everyone
> wants to go through the process of recompiling and retesting their
> applications just to move from RHL 5.x to 7.x. IN some cases, it's
> not an option; even Linux users use code that comes in binary-only.
I'll look into at least putting them on the FTP site in a conspicuous
directory for users to download.
===
Subject: Re: about 7.0 and gcc 2.96
From: John Summerfield <summer@OS2.ami.com.au>
Date: Fri, 13 Oct 2000 08:39:19 +0800
This is not necessarily a gcc problem. You have to analyze the nature
> of the problems before saying it is. In 5.0 RH took a lot of flak for
> moving to glibc but when you look at the problems most of them were
> not related to it. It looked more like if the move to glibc had
> stretched RH resources to the point the building and testing of other
> programs was affected.
I didn't intend anyone to think that I think gcc is a cause of any of the
other problems; I see the number of problems reported and (in many cases
fixed) already as an adverse reflection of the quality of RHL 7.0.
gcc is only one of the problems. Dropping support for libc is another.
btw Does anyone know about the new ISOs? What's changed?
===
Subject: Re: about 7.0 and gcc 2.96
From: John Summerfield <summer@OS2.ami.com.au>
Date: Fri, 13 Oct 2000 15:16:48 +0800
libc5 should indeed be included, but not as the base libc, but for
> > applications users already have and which work well. Not everyone
> > wants to go through the process of recompiling and retesting their
> > applications just to move from RHL 5.x to 7.x. IN some cases, it's
> > not an option; even Linux users use code that comes in binary-only.
>
> I'll look into at least putting them on the FTP site in a conspicuous
> directory for users to download.
thanks Matt.
You might put a README in the ISO director(y|ies) too. Not that anyone will
read them;-), but you can say "We told you -- see ftp:.........."
===
Subject: Re: about 7.0 and gcc 2.96
From: Levente Farkas <lfarkas@mindmaker.hu>
Date: Fri, 13 Oct 2000 11:22:00 +0200
jfm2@club-internet.fr wrote:
>
> >
> > > hi,
> > > first of all I don't know the overall quality of 7.0 since I'm just come
> > > back from my vacation, but I read many mails and news about in which
> > > people are criticize red hat why they include gcc 2.96 in 7.0.
> >
> > gcc 2.96 is a development version. Its authors say it's not ready for release.
> >
>
> gcc 2.96 is a snapshot plus heavy patches. You could (or could not)
> consider that it is alike a production kernel where the code freeze
> has taken place before the official one by Linus. Not necessarily
> unstable but due to the fact this gcc is not official it has not got
> the same kind of post-release testing by users that an official gcc
> would have got. It only has got in house testing. This problem (of
> relative lack of testing) could have lightened if RH had anoounced in
> advance that this gcc would be the "next one". Given that it is not
> unusual that RedHat rolls back certain features of its betas I for one
> didn't pay much attention to the gcc in pinstripe and I didn't try to
> push it too hard.
>
> Also gcc 2.96 at the testsuite are far better than those of gcc 2.95.
> This could suggest that it is much better than people suggest. You
> could however wait a bit before using it for important things until
> other people have really tried it.
I've used 2.96 at least for 3 mounts from rawhide and use it with stdc++-v3
and it's much better then the earlier. may be not so many paople use
it but it's time to test it by more people. when glibc comes and libc5
go away then there is just a few 'brave' people who use it and it
was not a realy widely tested. for developers it's better, for users
it's better if they don't have to know about it and they don't bother
with it.
does anybody have any real example why 2.96 is worse the 2.95 ?
anyway 2.95 would be the worst choice, since it's worse some c++ part
than egcs.
ps. I read gcc's statement about it and I agree with them since they
have to portect their 'product' from critic, and 2.96 is not their
'product'. and I've fully respect for them their great product.
but from rh point of view there is many 'good' c++ compiler on
windows, even ms's vc++ is better conforming to the standard c++
then the earlier gcc releases. until linux don't have a good c++
compiler windows c++ programmer can't turn to linux. there is a kai
and will a borland c++ compiler for linux but more linux user would
like to use gcc.
===
Subject: C++/STL compilation under 7.0
From: Steve Borho <steve@borho.org>
Date: Wed, 4 Oct 2000 10:48:32 -0500
Has anyone tried to compile a C++ program which uses the stdc++ libs
with 7.0?
Initially the compile complains it can't find header files. A quick
glance shows that /usr/include/g++ is no more and that
/usr/include/g++-2 and -3 are now there... the -2 version is owned by
the compat-libstc packages and the -3 are owned by the new compiler...
Ok, I add /usr/include/g++-3 to my includes and start the compile again
and I get a few hundred warning messages (complaining about stl_vector.h
and template members) and it stops compiling.
So I add /usr/include/g++-2 to the path instead and start the compile
and it goes great until the linking stage where it barfs:
ld: cannot find -lstdc++
Because there's two copies of the STL libraries installed:
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.a
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
/usr/lib/libstdc++-libc6.1-1.a.2 -> libstdc++-2-libc6.1-1-2.9.0.a
/usr/lib/libstdc++-libc6.1-1.so.2 -> libstdc++-2-libc6.1-1-2.9.0.so
/usr/lib/libstdc++.so.2.7.2 -> libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.8 -> libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.9 -> libstdc++.so.2.9.dummy
/usr/lib/libstdc++.so.2.9.dummy
What's the proper way to make the compiler pick one or the other?
Subject: C++/STL compilation under 7.0--
From: Steve Borho <steve@borho.org>
Date: Wed, 4 Oct 2000 10:48:32 -0500
Has anyone tried to compile a C++ program which uses the stdc++ libs
with 7.0?
Initially the compile complains it can't find header files. A quick
glance shows that /usr/include/g++ is no more and that
/usr/include/g++-2 and -3 are now there... the -2 version is owned by
the compat-libstc packages and the -3 are owned by the new compiler...
Ok, I add /usr/include/g++-3 to my includes and start the compile again
and I get a few hundred warning messages (complaining about stl_vector.h
and template members) and it stops compiling.
So I add /usr/include/g++-2 to the path instead and start the compile
and it goes great until the linking stage where it barfs:
ld: cannot find -lstdc++
Because there's two copies of the STL libraries installed:
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.a
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
/usr/lib/libstdc++-libc6.1-1.a.2 -> libstdc++-2-libc6.1-1-2.9.0.a
/usr/lib/libstdc++-libc6.1-1.so.2 -> libstdc++-2-libc6.1-1-2.9.0.so
/usr/lib/libstdc++.so.2.7.2 -> libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.8 -> libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.9 -> libstdc++.so.2.9.dummy
/usr/lib/libstdc++.so.2.9.dummy
What's the proper way to make the compiler pick one or the other?
===
Subject: Re: C++/STL compilation under 7.0
From: Bernhard Rosenkraenzer <bero@redhat.de>
Date: Wed, 4 Oct 2000 20:57:44 +0200 (CEST)
On Wed, 4 Oct 2000, Steve Borho wrote:
> Has anyone tried to compile a C++ program which uses the stdc++ libs
> with 7.0?
Sure - no problems at all here.
> Initially the compile complains it can't find header files. A quick
> glance shows that /usr/include/g++ is no more and that
> /usr/include/g++-2 and -3 are now there... the -2 version is owned by
> the compat-libstc packages and the -3 are owned by the new compiler...
/usr/include/g++-3 is the correct one and is automatically used by the
compiler.
Are you sure you invoked the compiler as g++ and not just gcc?
> ld: cannot find -lstdc++
>
> Because there's two copies of the STL libraries installed:
You should have /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
Make sure you installed gcc-c++, libstdc++ and libstdc++-devel. Looks like
at least one of them is missing on your system.
===
Subject: Re: C++/STL compilation under 7.0
From: Steve Borho <steve@borho.org>
Date: Wed, 4 Oct 2000 16:57:11 -0500
On Wed, Oct 04, 2000 at 08:57:44PM +0200, Bernhard Rosenkraenzer wrote:
> On Wed, 4 Oct 2000, Steve Borho wrote:
>
> > Has anyone tried to compile a C++ program which uses the stdc++ libs
> > with 7.0?
>
> Sure - no problems at all here.
>
> > Initially the compile complains it can't find header files. A quick
> > glance shows that /usr/include/g++ is no more and that
> > /usr/include/g++-2 and -3 are now there... the -2 version is owned by
> > the compat-libstc packages and the -3 are owned by the new compiler...
>
> /usr/include/g++-3 is the correct one and is automatically used by the
> compiler.
> Are you sure you invoked the compiler as g++ and not just gcc?
ix% g++ -g -Wall -c -o pmcomp_input.o pmcomp_input.C
In file included from pmcomp_input.C:16:
pmcomp.hpp:21: iostream: No such file or directory
pmcomp.hpp:22: vector: No such file or directory
pmcomp.hpp:23: set: No such file or directory
<snip>
ix% g++ -g -Wall -I/usr/include/g++-3 -c -o pmcomp_input.o pmcomp_input.C
In file included from /usr/include/g++-3/vector:31,
from pmcomp.hpp:22,
from pmcomp_input.C:16:
/usr/include/g++-3/stl_alloc.h:742: invalid member template declaration
/usr/include/g++-3/stl_alloc.h:780: invalid member template declaration
/usr/include/g++-3/stl_alloc.h:817: invalid member template declaration
/usr/include/g++-3/stl_alloc.h:858: invalid member template declaration
/usr/include/g++-3/stl_alloc.h:961: empty component declaration
/usr/include/g++-3/stl_alloc.h:961: parse error before `<'
/usr/include/g++-3/stl_vector.h: In method `_Tp * vector<_Tp,_Alloc>::begin()':
In file included from /usr/include/g++-3/vector:34,
from pmcomp.hpp:22,
from pmcomp_input.C:16:
<snip>
ix% g++ -g -Wall -I/usr/include/g++-2 -c -o pmcomp_input.o pmcomp_input.C
ix%
> You should have /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
>
> Make sure you installed gcc-c++, libstdc++ and libstdc++-devel. Looks like
> at least one of them is missing on your system.
ix% rpm -q gcc-c++ libstdc++ libstdc++-devel
gcc-c++-2.96-54
libstdc++-2.96-54
libstdc++-devel-2.96-54
ix% which g++
/celox/bin/g++
Oooof. There it is. Sorry about that. I need to change my path.
I'm getting the site wide compiler. Thanks for the help.
===