Compiler for Red Hat Linux 8

Compiler for Red Hat Linux 8

[Geoff Keating]

It's now time for us here at Red Hat to begin planning for the next
major Red Hat Linux release.  One of the first questions that we're
looking at is "which compiler should we use?"

At present, we have three compilers for the linux releases.  There is
the default compiler, which is currently based off a 2.96 snapshot.
There is a special compiler for the kernel, which is based off egcs
1.1.2.  There is also a GNUPro compiler, which is a Red Hat-released
compiler on which we offer full support; it came out of the Red Hat
internal tree.

We'd really like to get this list down to one compiler.  These
compilers have subtle incompatibilities with each other, and it's really
annoying that we can't fully support the compiler that comes with the
system.

So, one plan being considered is that we take a compiler out of the
Red Hat internal tree (based sometime after 3.0), make a release, and
ship that as the default compiler.  Then if we can make the kernel
work with this compiler, we have one compiler, which we can fully
support.  We didn't have time to do either of these for RHL 7, but we
do for RHL 8.

The other problem with what we did for RHL 7 was that it was difficult
for other distributors to be compatible with our system, because the
2.96 snapshot wasn't binary-compatible with any FSF release.  With the
release of GCC 3.0, this shouldn't happen for the new compiler; other
distributors will be able to use any 3.0-compatible compiler.

[I know IA64 has a completely different set of problems; I'm mostly
concerned about IA32 and Alpha at this point, but if anyone has
suggestions about IA64 we're happy to hear them; the main problem
seems to be that the ABI for IA64 is still changing, but the internal
tree is better for IA64 than the FSF releases at this point.  I also
know about the glibc issues on all platforms, but that's a separate
issue also.]

So, how do people feel about this?  Does the SC have an opinion?

-- 
- Geoffrey Keating <geoffk@redhat.com>

Re: Compiler for Red Hat Linux 8

[Joe Buck]

Geoff Keating writes:

> It's now time for us here at Red Hat to begin planning for the next
> major Red Hat Linux release.  One of the first questions that we're
> looking at is "which compiler should we use?"

While I am an SC member, I am speaking only for myself in this message.

Red Hat's decision has an effect on many people, in many capacities: the
non-Red Hat gcc developers; application developers (free software or
otherwise) who target GNU/Linux; users of Red Hat; users of other
GNU/Linux distributions.

> At present, we have three compilers for the linux releases.
[ egcs-1.1.2, 2.96-RH, GNUPro ]

Rather, three for *your* releases.  A number of other GNU/Linux
distributors (e.g. Debian) use 2.95.x, plus minor patches.
So there are really four distinct gcc versions in widespread use
on GNU/Linux, all binary-incompatible.

(one way to really piss people off, without intending to do so, is
to make statements that give the impression that you think that
Red Hat == Linux.  I know that you didn't mean to, but you wrote
"the linux releases".  Please be more careful).

> We'd really like to get this list down to one compiler.

Looking at the larger world, we're probably talking about three compiler
groupings: 2.95.x, 3.0.x, and GNUpro, as people move away from egcs-1.1.2.
If 3.0.x and GNUpro are pretty closely source and binary compatible,
though, we will have two groups of compilers for binary-compatibility
purposes.  I would recommend developing some kind of test framework
for binary compatibility to catch breakage before things ship.

> So, one plan being considered is that we take a compiler out of the
> Red Hat internal tree (based sometime after 3.0), make a release, and
> ship that as the default compiler.  Then if we can make the kernel
> work with this compiler, we have one compiler, which we can fully
> support.  We didn't have time to do either of these for RHL 7, but we
> do for RHL 8.

If you can fix the Linux kernel and/or GCC so that any compatibility problems
are gone, and contribute these changes upstream (successfully negotiating
the politics involved), that would be terrific.  (That is, we should wind
up with both GNUPro and FSF-3.0.x building the new kernels correctly).

> The other problem with what we did for RHL 7 was that it was difficult
> for other distributors to be compatible with our system, because the
> 2.96 snapshot wasn't binary-compatible with any FSF release.  With the
> release of GCC 3.0, this shouldn't happen for the new compiler; other
> distributors will be able to use any 3.0-compatible compiler.

That's a necessary but not a sufficient condition.  We still haven't
frozen libstdc++'s ABI; we can't because it isn't really done and still
could be made better by more refactoring of templates and such.  To have
GNU/Linux applications portable between distros that use your compiler
and those that use FSF releases, you'll need to use the FSF version of
libstdc++, or make sure that any deviations don't break binary
compatibility.  It will be tempting to make some improvements.  Resist
that temptation.

> [I know IA64 has a completely different set of problems; I'm mostly
> concerned about IA32 and Alpha at this point, but if anyone has
> suggestions about IA64 we're happy to hear them; the main problem
> seems to be that the ABI for IA64 is still changing, but the internal
> tree is better for IA64 than the FSF releases at this point.  I also
> know about the glibc issues on all platforms, but that's a separate
> issue also.]

I don't know enough about IA64 issues to comment.

glibc is a sensitive matter; a number of us got rather nervous to see a
couple of glibc developers advocating the use of gcc-2.96-rh instead of
getting the 3.0 problems fixed.  To the extent that a number of glibc
developers work at Red Hat, I ask that you be sensitive to this.  Folks
who've taken on the task of maintaining packages for the FSF need to make
sure that they work together.

> So, how do people feel about this?  Does the SC have an opinion?

I do have concerns (that the world's largest concentration of gcc
developers will be putting their energy into a fork of gcc, rather than
the net gcc), but evidently you have decided for business reasons that
this is the way to go.  This is your right, but I hope that you make
efforts to keep the divergence small by regular re-syncs with the FSF
gcc tree.  The old Cygnus model was, in effect, that you were selling
what the FSF gcc would be like six months ahead, today.  I suppose I
could live with that, though it would be preferable not to have to.

Speaking personally, as a C++ developer my ideal world would be to write
to one fairly standards-conformant front end, say gcc-3.1.x, for all
platforms that I need to support.  However, I doubt that Red Hat has much
interest in supporting Solaris, HP/UX, or AIX (at least without special
contracts), so if your front end has a different set of bugs, it might be
easier just not to use it, even if that means (for the kind of compiled
simulation work that I do) shipping a complete copy of the FSF gcc to run
on Red Hat 8.x.  Each additional C++ compiler tends to mean a different
set of bugs and support issues.

Re: Compiler for Red Hat Linux 8

[Per Bothner]

[Speaking for myself of course, not for my current employer, nor
my past Cygnus affliliation, nor in my status as rather depressed
RH stock-owner, nor SC member!]

Joe Buck <jbuck@synopsys.COM> writes:

> I do have concerns (that the world's largest concentration of gcc
> developers will be putting their energy into a fork of gcc, rather than
> the net gcc), but evidently you have decided for business reasons that
> this is the way to go.

I think this is an unfair way of characterizing it.  The work "fork" is
a loaded one, and not appropriate.  I don't see what you would expect
Red Hat to do.  They cannot commit to a non-existent 3.0.x or 3.1.x;
the latter will probably be too late anyway for RH 8, and they need to
start initial test builds RSN.  So they have to work off some release
or snapshot.  They would presumably also add bug-fixes, but they may
not add exactly the same set of bug fixes that correspond to any
particular 3.0.x, because they have a schedule and Gcc has a different
looser schedule.  This is SOP and the same thing everone else does,
not just for Gcc but also the kernel etc.

So I assumme your complaint isn't that RH 8's gcc will not correspond
exactly to any specific Gcc release (which is unavoidable unless they
refuse to apply bug-fixes that appears after the release they use),
but that they are considering using their internal development tree.
Well, they have to use *some* internal development tree, so what is
wrong in using the same one as GNUPro uses, assuming they work to
minimize differences from the FSF tree?

> glibc is a sensitive matter; a number of us got rather nervous to see a
> couple of glibc developers advocating the use of gcc-2.96-rh instead of
> getting the 3.0 problems fixed.

In this case I might be tempted to be more forceful ...
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Compiler for Red Hat Linux 8

[Joseph S. Myers]

On 17 Jul 2001, Per Bothner wrote:

> Well, they have to use *some* internal development tree, so what is

In principle, why shouldn't this compiler have its own branch in the
public GCC CVS repository (which would mean other people could more
readily work out whether a particular feature or bug fix was in a
particular Red Hat compiler version)?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Compiler for Red Hat Linux 8

[Craig Rodrigues]

On Tue, Jul 17, 2001 at 01:20:07PM -0700, Geoff Keating wrote:
> 
> At present, we have three compilers for the linux releases.  There is
> the default compiler, which is currently based off a 2.96 snapshot.
> There is a special compiler for the kernel, which is based off egcs
> 1.1.2.  There is also a GNUPro compiler, which is a Red Hat-released
> compiler on which we offer full support; it came out of the Red Hat
> internal tree.
> 
> We'd really like to get this list down to one compiler.  These
> compilers have subtle incompatibilities with each other, and it's really
> annoying that we can't fully support the compiler that comes with the
> system.
> 
> So, one plan being considered is that we take a compiler out of the
> Red Hat internal tree (based sometime after 3.0), make a release, and
> ship that as the default compiler.  Then if we can make the kernel
> work with this compiler, we have one compiler, which we can fully
> support.  We didn't have time to do either of these for RHL 7, but we
> do for RHL 8.

I (and my customers) use a lot of Red Hat Linux systems.
I do primarily C++ development, and the bugs in the gcc 2.96
versions of the Red Hat compilers have caused problems for
me on real-world C++ projects:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=48835

gcc 3.0 is a fantastic achievement, and hopefully will encourage
the wider adoption of the C++ Standard Library for C++ developers
who use gcc.  To avoid problems with gcc 3.0, I have
done a lot of testing with the snapshots provided by CodeSourcery,
and reported bugs when I've found them.
Most things in gcc 3.0 work for me, except for PR 3189, which I filed
too late for it to be considered a blocking bug for gcc 3.0 to be released:

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&pr=3189&cmd=view

My recommendation would be for Red Hat to try to release gcc 3.0
as their default compiler, and work with the other free software
projects (Linux kernel, glibc) to make sure that everything compiles with it.
Also, frequently contributing bugfixes back to the FSF mainline gcc branch
so that the fork doesn't diverge too much would be good.

In addition, working with other C++ free software projects with
large user communities such as ACE ( http://www.cs.wustl.edu/~schmidt/ACE.html )
to insure that the Red Hat release of gcc can compile these projects
would be welcomed.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: Compiler for Red Hat Linux 8

[Andreas Jaeger]

Geoff, thanks for opening up this discussion.

Geoff Keating <geoffk@geoffk.org> writes:

> It's now time for us here at Red Hat to begin planning for the next
> major Red Hat Linux release.  One of the first questions that we're
> looking at is "which compiler should we use?"

[...]
> So, one plan being considered is that we take a compiler out of the
> Red Hat internal tree (based sometime after 3.0), make a release, and
> ship that as the default compiler.  Then if we can make the kernel
> work with this compiler, we have one compiler, which we can fully
> support.  We didn't have time to do either of these for RHL 7, but we
> do for RHL 8.

Going to GCC 3.0 is IMO the right way.
>
> The other problem with what we did for RHL 7 was that it was difficult
> for other distributors to be compatible with our system, because the
> 2.96 snapshot wasn't binary-compatible with any FSF release.  With the
> release of GCC 3.0, this shouldn't happen for the new compiler; other
> distributors will be able to use any 3.0-compatible compiler.

IMO we should broaden the issues a bit.  The issues you're facing will
be faced by all Linux distributors.  We should avoid a situation where
each distributor releases a GCC 3.0 version that is only compatible to
itself.  

I personally would appreciate - and support - a commitment from some
of the Linux distributors on the next GCC version they're using and on
compatibility to a *released* GCC version.

Compatibility between distributions is important and I'd even like to
see C++ specified in a newer revision of LSB (we didn't specify C++
for LSB 1.0 because of these incompatibilities).

IMO it would even make sense to discuss a "common Linux GCC" version.

> [I know IA64 has a completely different set of problems; I'm mostly
> concerned about IA32 and Alpha at this point, but if anyone has
> suggestions about IA64 we're happy to hear them; the main problem
> seems to be that the ABI for IA64 is still changing, but the internal
> tree is better for IA64 than the FSF releases at this point.  I also
> know about the glibc issues on all platforms, but that's a separate
> issue also.]
>
> So, how do people feel about this?  Does the SC have an opinion?

Andreas

P.S. I'm not speaking offically for SuSE here - but I'm biased ;-).
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Compiler for Red Hat Linux 8

[H . J . Lu]

On Wed, Jul 18, 2001 at 11:41:18AM +0200, Andreas Jaeger wrote:
> 
> IMO we should broaden the issues a bit.  The issues you're facing will
> be faced by all Linux distributors.  We should avoid a situation where
> each distributor releases a GCC 3.0 version that is only compatible to
> itself.  
> 
> I personally would appreciate - and support - a commitment from some
> of the Linux distributors on the next GCC version they're using and on
> compatibility to a *released* GCC version.

I think that is the problem. When was the last time any Linux
distributions used an unmodified *released* GCC? Probably never. None
of the *released* GCCs was good enough to build a whole Linux
distribution. Every vendor has to modify a *released* GCC or
take a snapshot from CVS. One way to solve it for Linux is to have
a vendor-natural Linux gcc, which is known to be able to compile
a complete, working Linux distribution. But given the release
schedule of gcc, unless a Linux distribution wants to sync their
release schedule with gcc, which I don't believe is likely to happen,
I don't think such a Linux gcc will be a *released* GCC. That is
why I suggested making bug fix releases of gcc every 2 or 3 weeks
so that there is a chance that we can use a *released* GCC for
Linux distributions. Of course, I am assuming that those bug fix
releases fix the reported Linux build bugs.


H.J.

Re: Compiler for Red Hat Linux 8

[Joe Buck]

On Wed, Jul 18, 2001 at 11:41:18AM +0200, Andreas Jaeger wrote:
> > I personally would appreciate - and support - a commitment from some
> > of the Linux distributors on the next GCC version they're using and on
> > compatibility to a *released* GCC version.

HJ Lu wrote:
> I think that is the problem. When was the last time any Linux
> distributions used an unmodified *released* GCC? Probably never.

Andreas is talking about compatibility to a released version, he is not
insisting on no patches.  A few patches to solve localized problems
(example: Debian's patched 2.95.2) is not an issue; no GNU/Linux
distributor ships unmodified Linux kernels either, for similar reasons.
It only becomes an issue when incompatibilities arise or changes don't get
merged back in.

These mini-forks are not a problem because everything keeps getting
re-synced again.  It's only an issue if things start growing apart
or people can't resolve their differences.

> None
> of the *released* GCCs was good enough to build a whole Linux
> distribution. Every vendor has to modify a *released* GCC or
> take a snapshot from CVS. One way to solve it for Linux is to have
> a vendor-natural Linux gcc, which is known to be able to compile
> a complete, working Linux distribution. But given the release
> schedule of gcc, unless a Linux distribution wants to sync their
> release schedule with gcc, which I don't believe is likely to happen,
> I don't think such a Linux gcc will be a *released* GCC.

Given the circumstances in the last couple of years, this is
understandable.  Something like 2.95.3 should have come out ages
before it did, but we weren't in a position to do releases at that
time because we had no release manager.  I'd like to get 3.0.x in
shape to be usable for complete GNU/Linux distributions as soon
as possible.

> why I suggested making bug fix releases of gcc every 2 or 3 weeks
> so that there is a chance that we can use a *released* GCC for
> Linux distributions. Of course, I am assuming that those bug fix
> releases fix the reported Linux build bugs.

It's not necessary to do a whole lot of releases to make this happen: we
have a 3.0 CVS branch.  Volunteers who care about this can build from a
CVS gcc (or download prebuilt releases from daily snapshots, like those
CodeSourcery provides) and report failures.  Our target for 3.0.1 is
August 1.  But it's not necessary to wait until that date to help find and
fix problems.

And remember that there will be lots of problems in apps as well as the
compiler.  Incorrect #ifdefs that break with the bump in major version
number; invalid C++ code that happened to work with 2.95.x, etc.

Re: Compiler for Red Hat Linux 8

[H . J . Lu]

On Wed, Jul 18, 2001 at 12:01:29PM -0700, Joe Buck wrote:
> 
> > why I suggested making bug fix releases of gcc every 2 or 3 weeks
> > so that there is a chance that we can use a *released* GCC for
> > Linux distributions. Of course, I am assuming that those bug fix
> > releases fix the reported Linux build bugs.
> 
> It's not necessary to do a whole lot of releases to make this happen: we
> have a 3.0 CVS branch.  Volunteers who care about this can build from a
> CVS gcc (or download prebuilt releases from daily snapshots, like those
> CodeSourcery provides) and report failures.  Our target for 3.0.1 is
> August 1.  But it's not necessary to wait until that date to help find and
> fix problems.
> 
> And remember that there will be lots of problems in apps as well as the
> compiler.  Incorrect #ifdefs that break with the bump in major version
> number; invalid C++ code that happened to work with 2.95.x, etc.

It is more than that. That is one reason why it is not practical to
download a gcc snapshot everyday or every week and try to rebuild
the whole distribution unless the whole distribution has been built
successfully with the current major gcc release before. What may
happpen is noone can use the to-be-released gcc 3.0.1 to build the
whole Linux distribution before it is released. They may take a gcc
snapshot and go from there. When they finally find all the compiler
bugs, gcc 3.0.1 has been released. Then they will start all over
again. As the result, you still need to make gcc 3.0.2 if you want to
use it to build the whole Linux distribution. Of course, things will
be different if you want to base the gcc release schedule on the xxxx
Linuxx distribution release schedule.


H.J.

Re: Compiler for Red Hat Linux 8

[Joe Buck]

HJ writes:
> What may
> happpen is noone can use the to-be-released gcc 3.0.1 to build the
> whole Linux distribution before it is released. They may take a gcc
> snapshot and go from there. When they finally find all the compiler
> bugs, gcc 3.0.1 has been released. Then they will start all over
> again. As the result, you still need to make gcc 3.0.2 if you want to
> use it to build the whole Linux distribution.

If so, then we'll make 3.0.2, and because of scheduling, some people may
release GNU/Linux distros with 3.0.1+patches because 3.0.2 wasn't out
yet.

Re: Compiler for Red Hat Linux 8

[H . J . Lu]

On Wed, Jul 18, 2001 at 01:21:59PM -0700, Joe Buck wrote:
> HJ writes:
> > What may
> > happpen is noone can use the to-be-released gcc 3.0.1 to build the
> > whole Linux distribution before it is released. They may take a gcc
> > snapshot and go from there. When they finally find all the compiler
> > bugs, gcc 3.0.1 has been released. Then they will start all over
> > again. As the result, you still need to make gcc 3.0.2 if you want to
> > use it to build the whole Linux distribution.
> 
> If so, then we'll make 3.0.2, and because of scheduling, some people may
> release GNU/Linux distros with 3.0.1+patches because 3.0.2 wasn't out
> yet.

The same thing can happen with 3.0.2 ... That means the current
unmodified *released* gcc may not be usable for Linux. That will
last at least from one bug fix release to the next one. If it happens
more than half a year within a year, people may say you shouldn't use
the unmodified *released* gcc on Linux.


H.J.

Re: Compiler for Red Hat Linux 8

[David Edelsohn]

>>>>> "H J Lu" writes:

HJ> The same thing can happen with 3.0.2 ... That means the current
HJ> unmodified *released* gcc may not be usable for Linux. That will
HJ> last at least from one bug fix release to the next one. If it happens
HJ> more than half a year within a year, people may say you shouldn't use
HJ> the unmodified *released* gcc on Linux.

	Various distributions and user communities frequently use patched
versions of GCC, but that does not mean that the variants need to be
incompatible or start from a non-FSF source base.  The two questions are:

1) What GCC sources should be used as the base for the patched version?
2) Should the patched version maintain binary compatibility with the base?

	I personally strongly encourage Red Hat to consider using the FSF
GCC release as the base.  This is not a question of either using the
vanilla FSF GCC release or using a completely separate branch.  There are
other options besides those two extreme positions.

	I also personally encourage Red Hat to maintain compatibility with
the FSF GCC releases.

	Red Hat employs a large number of highly skilled GCC developers.
If GCC 3.0 or the GCC trunk is not stable enough / correct enough to use
in a GNU/Linux distribution, Red Hat's developers can work to improve and
stabilize a particular FSF GCC source base as effectively as any other GCC
source base.

	Red Hat's GNUPro "devo" source base is synchronized with the FSF
sources and, therefore, contains roughly as many problems as the FSF
sources.  A Red Hat 8 branch in GNUPro would need a similar amount of
stabilization work and performance improvement as the FSF sources.

	Maybe Red Hat could request a branch in the FSF GCC repository to
which they could have exclusive write access for their own development
effort -- using their own patches and acceptance criteria?  Maybe the
generic "GNU/Linux GCC" branch for all distributors, which another person
proposed, is the solution.

	I would like to find a way for Red Hat to develop their Red Hat
Linux 8 GCC release from the FSF GCC sources.  I think that we can find a
solution more easily by starting with a discussion of Red Hat's
requirements and how to fit those into the FSF GCC development environment
instead of starting from the pre-defined, limited proposals which have
been mentioned so far.

Thanks, David

	P.S. Speaking for myself; representing neither IBM nor the GCC
Steering Committee.

===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

Re: Compiler for Red Hat Linux 8

[Joern Rennecke]

> 	Red Hat employs a large number of highly skilled GCC developers.
> If GCC 3.0 or the GCC trunk is not stable enough / correct enough to use
> in a GNU/Linux distribution, Red Hat's developers can work to improve and
> stabilize a particular FSF GCC source base as effectively as any other GCC
> source base.

That is not true.  Contributing to the FSF GCC sources requires patch
review, which often doesn't happen.

> 	Red Hat's GNUPro "devo" source base is synchronized with the FSF
> sources and, therefore, contains roughly as many problems as the FSF
> sources.  A Red Hat 8 branch in GNUPro would need a similar amount of
> stabilization work and performance improvement as the FSF sources.

Our tree contains infrastructure to enable our Q/A to work.
Moreover, you forget the issue of support.  We need control of
the versions that we support.  We can't have third parties check
in changes to our software just before we ship it.
The GNUpro source base also has changes so that there are no spurious
bug reporting instructions.
And sometimes we need to be able to keep track of how patches relate
to customer problems, even if the problem description contains
confidential information.
Hence, we need a repository that is not world-readable.

> 	Maybe Red Hat could request a branch in the FSF GCC repository to
> which they could have exclusive write access for their own development
> effort -- using their own patches and acceptance criteria?  Maybe the
> generic "GNU/Linux GCC" branch for all distributors, which another person
> proposed, is the solution.

Why should we (FSF gcc developers) have a GNU/Linux GCC branch?  Why not
use the latest release branch.  Then the patches will automatically be
included in the next bug fix release.

Re: Compiler for Red Hat Linux 8

[David Edelsohn]

>>>>> Joern Rennecke writes:

Joern> Why should we (FSF gcc developers) have a GNU/Linux GCC branch?  Why not
Joern> use the latest release branch.  Then the patches will automatically be
Joern> included in the next bug fix release.

	We already have a new mechanism for development that includes
doing major development on a branch.  Why not consider GCC for Red Hat
Linux 8 a similar situation.  Branches in the GCC CVS repository are more
than just release branches.

	Even if you do not try to find a way to use the FSF GCC sources as
your base, I hope that you will consider the request from numerous corners
that the version of GCC included in Red Hat Linux 8 be compatible with FSF
GCC releases.

Regards, David

Re: Compiler for Red Hat Linux 8

[Joe Buck]

David Edelsohn writes:
> 	Even if you do not try to find a way to use the FSF GCC sources as
> your base, I hope that you will consider the request from numerous corners
> that the version of GCC included in Red Hat Linux 8 be compatible with FSF
> GCC releases.

It was clear to me from Geoff's message that folks at Red Hat are thinking
about the compatibility issue.

I wouldn't seek to overconstrain Red Hat; any of several mechanisms with
respect to branches may be just fine and choosing what's best is the task
of the developers that do the work.  It would be easiest for all of us in
the long run, however (including Red Hat folks), if the delta between what
Red Hat ships and what others have is never too large.  Forking off at
some point from the 3.0 branch to give a controlled, supportable set of
code that won't be too far from FSF 3.0.x might be a good way to do that,
but perhaps a decent ia64 backend needs newer code that is in RH's
internal tree but not the FSF tree.

The thing to avoid is for the two code bases to diverge so far that bug
fixes don't port or subtle incompatibilities arise.

Re: Compiler for Red Hat Linux 8

[H . J . Lu]

On Wed, Jul 18, 2001 at 03:23:32PM -0700, Joe Buck wrote:
> of the developers that do the work.  It would be easiest for all of us in
> the long run, however (including Red Hat folks), if the delta between what
> Red Hat ships and what others have is never too large.  Forking off at

It has been working quite well with the Linux binutils.


H.J.

Re: Compiler for Red Hat Linux 8

[Toon Moene]

Joe Buck wrote:

> David Edelsohn writes:

> >       Even if you do not try to find a way to use the FSF GCC sources as
> > your base, I hope that you will consider the request from numerous corners
> > that the version of GCC included in Red Hat Linux 8 be compatible with FSF
> > GCC releases.
> 
> It was clear to me from Geoff's message that folks at Red Hat are thinking
> about the compatibility issue.
> 
> I wouldn't seek to overconstrain Red Hat; any of several mechanisms with
> respect to branches may be just fine and choosing what's best is the task
> of the developers that do the work.  It would be easiest for all of us in
> the long run, however (including Red Hat folks), if the delta between what
> Red Hat ships and what others have is never too large.  Forking off at
> some point from the 3.0 branch to give a controlled, supportable set of
> code that won't be too far from FSF 3.0.x might be a good way to do that,
> but perhaps a decent ia64 backend needs newer code that is in RH's
> internal tree but not the FSF tree.

Yes, but what I read from Geoff's message just before this one is that
RH's system compiler will most probably be derived from the 3.1 trunk.

<QUOTE>
5. We would prefer to ship a newer compiler than something off the 3.0
   branch.   By the time that this release goes out, the 3.0 branch
   will be over a year old.  You'll note that RHL 7.2 is not out yet,
   and on the normal schedule RHL 8 will be about six months later.
</QUOTE>

The problem with that move would be that they make a release branch off
the 3.1 trunk (say within two months), and we have to hope that *we*
won't introduce incompatible changes in the time up to April 15, 2002,
the projected release date for 3.1.

I'm professionally involved with predicting the future, but I tend to
limit it to two days ahead ;-)

[ I agree with Joe's remark about constraining Red Hat - I don't have
  the inclination or the time to micro-manage GNU/Linux distributors ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Compiler for Red Hat Linux 8

[Joseph S. Myers]

On Wed, 18 Jul 2001, Joern Rennecke wrote:

> > 	Red Hat employs a large number of highly skilled GCC developers.
> > If GCC 3.0 or the GCC trunk is not stable enough / correct enough to use
> > in a GNU/Linux distribution, Red Hat's developers can work to improve and
> > stabilize a particular FSF GCC source base as effectively as any other GCC
> > source base.
> 
> That is not true.  Contributing to the FSF GCC sources requires patch
> review, which often doesn't happen.

Since Red Hat has two thirds of the global write privileges maintainers,
presumably they can arrange that someone does review patches Red Hat needs
- unless, of course, the problem is that the patches aren't clean enough
for the FSF tree.

> Our tree contains infrastructure to enable our Q/A to work.

Is this infrastructure something of potential use outside Red Hat?  If so,
is it available as free software?

> The GNUpro source base also has changes so that there are no spurious
> bug reporting instructions.

People will still send bug reports to the GCC system when they shouldn't;
gcc-bugs and the GCC GNATS database get some bug reports for *-cygnus-*
versions, which are presumably ones which do not direct bug reports to
gcc-bugs or the GCC GNATS database.

If the Red Hat 8 GCC version were based off a GNUpro version, but that
version were checked in to the FSF repository on a branch, that might at
least help people trying to respond helpfully to misdirected bug reports
and questions work out what is in Red Hat's release - as well as avoiding
wasting people's time on the "seek out GNUpro releases on the net" game
<URL: http://gcc.gnu.org/ml/gcc/2001-03/msg00660.html >.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Compiler for Red Hat Linux 8

[H . J . Lu]

On Wed, Jul 18, 2001 at 11:41:42PM +0100, Joseph S. Myers wrote:
> 
> If the Red Hat 8 GCC version were based off a GNUpro version, but that
> version were checked in to the FSF repository on a branch, that might at
> least help people trying to respond helpfully to misdirected bug reports
> and questions work out what is in Red Hat's release - as well as avoiding
> wasting people's time on the "seek out GNUpro releases on the net" game
> <URL: http://gcc.gnu.org/ml/gcc/2001-03/msg00660.html >.

Has anyone ever noticed most of the Linux vendors can use a *released*
Linux binutils? Has anyone looked at the binutils Red Hat uses? It
has far less patches than the gcc they are using. It is because I have
been making such frequent Linux binutils releases that there is no
need for any Linux vendors to roll their own versions of binutils. If
the current Linux binutils doesn't work, it won't last for more than
2 weeks after I am notified. Forget about the *official* FSF binutils.
I don't think it is usable for Red Hat without serious patches.
Admittedly, gcc is much more complex than binutils. But as long as
people don't make making a release a big deal, I don't see why more
frequent bug releases can't be made. They may not be as polished as
we'd like to be. But at least, there is a chance that Red Hat 8 may use
a *relaased* gcc.


H.J.

Re: Compiler for Red Hat Linux 8

[Sergey Ostrovsky]

"H . J . Lu" wrote:

> I think that is the problem. When was the last time any Linux
> distributions used an unmodified *released* GCC? Probably never. None
> of the *released* GCCs was good enough to build a whole Linux
> distribution.

Quite a few people have built their own systems from sources using only
released
source tarballs of everything ( gcc including ). Check out
linuxfromscratch.org.
I've built 4 such systems, each has of approximately 90 packages installed
( yes, and X,
and teTeX, Qt, KDE, all the bells and whistles ), each
one built from sources. Gcc compilers used are 2.95, 2.95.2, 2.95.3.
Glibc versions used are 2.1.3, 2.2, 2.2.1, 2.2.2. Kernels that glibc was
built against are 2.2.15 - 2.4.4.
Binutils range from 2.9.x to 2.11.x.
Few packages had glibc-2.1 - 2.2 compatibility or pre-ANSI C problems, so
my modest knowledge of C was just sufficient to fix.
And I have yet to see my first segfault, oops, or whatever.

After glibc successfully built.

Because if the build of glibc breaks, there is not much sense in trying
anything else.
If you've built glibc, than the toolchain is good for everything, including
the kernel.
I found the gcc-binutils coupling pretty weak.
Almost every time when new glibc is out, it takes several attempts to chose
one of recent binutils
( H.J. Lu makes bugfix releases quite often, which is appreciated very
much) which will be OK to
1. build binutils
2. build gcc using (1) binutils
3. build glibc using (1) (2) guys.
In these attempt everything seems to matter - with or without -march=, -O#
switches
in CFLAGS, etc.
So I take is as kind of black magic.
Hope this "pure user" point of view helpful.

Regards,

Sergey Ostrovsky.

RE: Compiler for Red Hat Linux 8

[Ken Whaley]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

> Almost every time when new glibc is out, it takes several
> attempts to chose
> one of recent binutils
> ( H.J. Lu makes bugfix releases quite often, which is appreciated very
> much) which will be OK to
> 1. build binutils
> 2. build gcc using (1) binutils
> 3. build glibc using (1) (2) guys.
> In these attempt everything seems to matter - with or without -march=, -O#
> switches
> in CFLAGS, etc.
> So I take is as kind of black magic.
> Hope this "pure user" point of view helpful.
>
> Regards,
>
> Sergey Ostrovsky.
>
>

IÂ’ve just gone through this process, pretty much exactly
as Sergey described, including digging around trying to
find info on what patches, versions, etc. of the tools
are required, and agree that itÂ’s a sort of black magic.
Saying “use an official released version to build your
system” becomes a lot more palatable if there would always
be an up-to-date trio of officially released binutils/glibc/gcc
that all work together.  Easier said than done, I agree, but
that would be a wonderful thing to achieve.   When these 3
pieces achieve alignment so rarely, it doesnÂ’t suprise me that
vendors dig in and make their own modifications.

Another userÂ’s perspective,

Ken

p.s. and thanks to all the folks working on these tools, itÂ’s
definitely appreciated.

Re: Compiler for Red Hat Linux 8

[Toon Moene]

Ken Whaley wrote:

> I?ve just gone through this process, pretty much exactly
> as Sergey described, including digging around trying to
> find info on what patches, versions, etc. of the tools
> are required, and agree that it?s a sort of black magic.
> Saying ?use an official released version to build your
> system? becomes a lot more palatable if there would always
> be an up-to-date trio of officially released binutils/glibc/gcc
> that all work together.  Easier said than done, I agree, but
> that would be a wonderful thing to achieve.   When these 3
> pieces achieve alignment so rarely, it doesn?t suprise me that
> vendors dig in and make their own modifications.

Well, I'm not that convinced that the problems related here are absent
on your Operating System Of Choice, i.e., the one that insert question
marks in your e-mails everytime you think you type a quote (')
character.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

RE: Compiler for Red Hat Linux 8

[Ken Whaley]

Sigh, that just started happening, I will have to figure that 
out (and will write this reply without the use of contractions :).
And this operation system of alleged choice has no place in my 
workflow other than hosting where I write and read mail from and 
where my xterms that are running on linux display (and was not 
a matter of choice based on how IT sets up our workstations).

Do you think the drawbacks and disadvantages of other $y$tem$ should
serve as the standard for what the GNU toolchain should try
to achieve?  All I said, and Sergey by implication, is that
from the perspective of a user, it is *hard* to cobble together a
set of decently up-to-date tools that all work together, and
basically impossible if you add the requirement of only using
officially released FSF versions.  Whether or not this is also the case
on other systems I would hope has no bearing on the goals
of the GNU folks, but just that it is, and I quote (without
quotes), The Right Thing To Do.

Ken

p.s. I said it initially and will say it again, that I enjoy
the fruits of the FSF/GNU teams labors, appreciate their work,
and contribute back such fixes/enhancements as I can.  
I recognize the difficulty of synchronizing what in effect are 
3 separate projects, but the whole point of this thread is 
the asking and aswering of the question: Why Not Use Only 
Released Versions?, and making the point that actually achieving
such synchronization would be a Good Thing.

> 
> Well, I'm not that convinced that the problems related here are absent
> on your Operating System Of Choice, i.e., the one that insert question
> marks in your e-mails everytime you think you type a quote (')
> character.
> 
> -- 
> Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
> Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
> 

Re: Compiler for Red Hat Linux 8

[Toon Moene]

Ken Whaley wrote:

> Sigh, that just started happening, I will have to figure that
> out (and will write this reply without the use of contractions :).
> And this operation system of alleged choice has no place in my
> workflow other than hosting where I write and read mail from and
> where my xterms that are running on linux display (and was not
> a matter of choice based on how IT sets up our workstations).

OK - I'm convinced (hmmm, corporate IT - I almost forgot, but then it's
already close to 3 weeks into my holiday.  DON'T MAKE ME THINK OF THAT).

It's all GNU/Linux around here (Debian, that is).

No, I do not have enough spare time to build it from scratch - that's
what the Debian volunteers are for; and surely, I like to hear from them
if they have a problem with GCC's release cycle ...

Sprinkle with :-)'s liberally - no, I'm not speaking for anyone.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Compiler for Red Hat Linux 8

[Gerald Pfeifer]

[ Disclaimer: I *am* speaking for DBAI. :-) ]

On Wed, 18 Jul 2001, Andreas Jaeger wrote:
> Going to GCC 3.0 is IMO the right way.

...though be prepared to receive extremely bad and annoyed feedback
from those of your customers doing heavy duty C++ development.

Here at DBAI, for example, we simply cannot use GCC 3.0 because it's
an order of magnitude slower while generating larger and also slower
binaries.  I don't know, though, what this means for KDE and other
code you need to compile as part of your GNU/Linux distribution.

Though, if Red Hat could contribute developer time to address this kind of
problems on the GCC 3.0-branch, that would make a lot of sense I guess,
for there *are* significant improvements in the C++ frontend per se which
will be strongly appreciated by many customers.

> I personally would appreciate - and support - a commitment from some
> of the Linux distributors on the next GCC version they're using and on
> compatibility to a *released* GCC version.

Definitely. Having strong compatibility among different GNU/Linux
distributions makes a lot of sense, for *all* affected parties.

> IMO it would even make sense to discuss a "common Linux GCC" version.

Well, why can't this be FSF GCC?  Specifically, the current release
branch?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Compiler for Red Hat Linux 8

[Andreas Jaeger]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> [ Disclaimer: I *am* speaking for DBAI. :-) ]

;-)

> On Wed, 18 Jul 2001, Andreas Jaeger wrote:
>> Going to GCC 3.0 is IMO the right way.
> 
> ...though be prepared to receive extremely bad and annoyed feedback
> from those of your customers doing heavy duty C++ development.
> 
> Here at DBAI, for example, we simply cannot use GCC 3.0 because it's
> an order of magnitude slower while generating larger and also slower
> binaries.  I don't know, though, what this means for KDE and other
> code you need to compile as part of your GNU/Linux distribution.

So, your advice for distributors would be to wait for GCC 3.1 - or use
a compiler taken from the GCC 3.1 branch ...

> Though, if Red Hat could contribute developer time to address this kind of
> problems on the GCC 3.0-branch, that would make a lot of sense I guess,
> for there *are* significant improvements in the C++ frontend per se which
> will be strongly appreciated by many customers.

... unless somebody improves the GCC 3.0 branch significantly?

Btw. what are exactly the problems you're facing with GCC 3.0?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Compiler for Red Hat Linux 8

[Gerald Pfeifer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8940 bytes --]

On Thu, 19 Jul 2001, Andreas Jaeger wrote:
>> Here at DBAI, for example, we simply cannot use GCC 3.0 because it's
>> an order of magnitude slower while generating larger and also slower
>> binaries.  I don't know, though, what this means for KDE and other
>> code you need to compile as part of your GNU/Linux distribution.
> So, your advice for distributors would be to wait for GCC 3.1 - or use
> a compiler taken from the GCC 3.1 branch ... [...]
> ... unless somebody improves the GCC 3.0 branch significantly?

Yes.  Or, use GCC 3.0 for all languages except C++ and ship another, newer
version for C++.

Unfortunately, such another, newer version does not exist yet (the current
CVS head is even worse than GCC 3.0), so you might need to use GCC 2.95
for C++ sources and your users requiring C++.

(Which is, of course, *very* weird, considering that improved C++ support
is one of the most important features of GCC 3.0.)

> Btw. what are exactly the problems you're facing with GCC 3.0?

Compile times (and memory usage) are going through the roof due to
the tree-based inliner and the new libstdc++, and the generated
binaries are larger and often (sensibly) slower.

Today I performed benchmarks using a computational logic programming
system called DLV ( http://www.dbai.tuwien.ac.at/proj/dlv ) which uses
template and STL heavy C++ code on one of our ia32 boxes.

It's just one binary, but the benchmarks exercise completely different
modules and thus types of code. And the results are, well, depressing:

Specifically, compare compile times and -O0 and -O3 of 2.95 versus 3.0!

(I'd really be interested to see how build times compare for KDE, Gnome
or other heavy C++ code, ideally also benchmarks.)

Gerald

	   	  GCC 2.95			   GCC 3.0
	Compile time    Binary size      Compile time	Binary Size
-O0		6:19	3915128	 		 8:20	4159780
-O1		4:20	4203480			11:40	4829732
-O2		5:56	4209368			14:09	4862532
-O3		5:47	4221464			32:04	6166052

   2.95 -O0 |2.95 -O1|2.95 -O2|2.95 -O3| 3.0 -O0 | 3.0 -O1| 3.0 -O2| 3.0 -O3|
============================================================================+
STRATCOMP1-ALL                         |                                    |
      14.07 |   8.20 |   8.28 |   8.09 |  115.09 | 110.63 |  94.47 |  94.35 |
STRATCOMP-770.2-Q                      |                                    |
       4.73 |   1.43 |   1.44 |   1.30 |    6.12 |   1.64 |   1.46 |   1.44 |
2QBF1       |                          |                                    |
      84.64 |  27.01 |  25.75 |  25.78 |  132.42 |  37.78 |  35.30 |  40.93 |
PRIMEIMPL2  |                          |                                    |
     118.51 |  20.01 |  19.35 |  18.87 |  190.20 |  27.21 |  24.54 |  28.85 |
ANCESTOR    |                          |                                    |
      48.66 |  13.89 |  13.79 |  13.18 |   58.68 |  12.67 |  12.47 |  11.72 |
3COL-SIMPLEX1                          |                                    |
      44.60 |  13.62 |  13.49 |  12.05 |   53.87 |  12.11 |  12.61 |  11.91 |
3COL-LADDER1|                          |                                    |
     218.88 |  62.88 |  59.50 |  57.33 |  306.52 |  73.05 |  71.62 |  80.45 |
3COL-N-LADDER1                         |                                    |
     110.45 |  24.72 |  23.09 |  24.36 |  178.58 |  27.58 |  25.78 |  28.44 |
3COL-RANDOM1|                          |                                    |
     106.49 |  20.74 |  20.24 |  19.50 |  173.43 |  26.04 |  23.82 |  26.58 |
HP-RANDOM1  |                          |                                    |
      50.18 |  16.62 |  16.64 |  14.82 |   82.80 |  16.35 |  16.65 |  16.28 |
HAMCYCLE-FREE                          |                                    |
      11.18 |   2.70 |   2.63 |   2.10 |   20.91 |   3.20 |   2.96 |   2.49 |
DECOMP2     |                          |                                    |
     159.62 |  35.21 |  35.41 |  33.76 |  196.10 |  29.71 |  29.81 |  34.68 |
BW-P4-Esra-a|                          |                                    |
     359.78 | 110.74 | 109.56 | 108.27 |  557.31 | 118.59 | 115.80 | 122.23 |
BW-P5-nopush|                          |                                    |
      31.00 |   8.82 |   8.73 |   8.48 |   46.51 |   9.12 |   8.90 |   9.39 |
BW-P5-pushbin                          |                                    |
      32.26 |   8.20 |   7.99 |   7.82 |   49.46 |   8.68 |   8.21 |   8.81 |
BW-P5-nopushbin                        |                                    |
      11.30 |   2.91 |   2.90 |   2.71 |   16.68 |   2.92 |   2.92 |   3.05 |
3SAT-1      |                          |                                    |
     363.47 |  63.99 |  61.34 |  63.08 |  577.92 |  81.84 |  74.44 |  83.96 |
3SAT-1-CONSTRAINT                      |                                    |
     207.35 |  36.67 |  32.39 |  32.81 |  343.00 |  43.70 |  39.51 |  46.89 |
HANOI-Towers|                          |                                    |
      25.71 |   6.80 |   6.74 |   6.25 |   31.30 |   6.18 |   5.85 |   6.59 |
RAMSEY      |                          |                                    |
      56.77 |  16.00 |  15.55 |  14.00 |   76.73 |  16.35 |  16.71 |  14.99 |
CRISTAL     |                          |                                    |
      54.62 |  16.57 |  16.09 |  14.95 |   66.37 |  17.54 |  16.29 |  15.37 |
HANOI-K     |                          |                                    |
     361.15 |  64.51 |  59.92 |  58.67 |  563.88 |  77.92 |  71.98 |  80.24 |
21-QUEENS   |                          |                                    |
      88.28 |  19.63 |  18.92 |  18.89 |  175.51 |  23.67 |  22.79 |  24.31 |
MSTDir[V=13,A=40]                      |                                    |
     133.41 |  45.45 |  43.67 |  42.18 |  195.41 |  37.55 |  35.80 |  35.59 |
MSTDir[V=15,A=40]                      |                                    |
     133.48 |  46.41 |  44.56 |  43.25 |  194.97 |  37.75 |  36.06 |  35.05 |
MSTUndir[V=13,A=40]                    |                                    |
      77.61 |  23.47 |  22.87 |  21.37 |  122.09 |  20.18 |  19.24 |  19.16 |
MSTUndir[V=15,A=40]                    |                                    |
    1216.05 | 386.56 | 368.97 | 352.86 | 1911.62 | 328.32 | 314.92 | 302.76 |
TIMETABLING |                          |                                    |
      93.56 |  26.44 |  25.94 |  24.52 |  125.14 |  26.55 |  24.88 |  25.10 |
============================================================================+

STRATCOMP1-ALL:
STRATCOMP, random instance, |companies| = 60, |products| = 180,
all sets

STRATCOMP-770.2-Q:
STRATCOMP, random instance, |companies| = |products| = 770,
first model, with query

2QBF1:
2QBF, 1000 all-quantified, 20 existentially-quantified variables
10000 clauses, 5CNF

PRIMEIMPL2:
Prime Implicants with 180 variables and 774 clauses (all models [246])

ANCESTOR:
Double ancestor board of size 14 (only grounding)

3COL-SIMPLEX1:
3COL simplex graph, |edges| = 1980, |nodes| = 1035, one model

3COL-LADDER1:
3COL ladder graph, |edges| = 2998, |nodes| = 2000, one model

3COL-N-LADDER1:
3COL, propositional Niemelä style
ladder graph, |edges| = 2998, |nodes| = 2000, one model

3COL-RANDOM1:
3COL random graph, |edges| = 1100, |nodes| = 500, one model

HP-RANDOM1:
Hamiltonian Path on a random graph, |edges| = 700, |nodes| = 85, one model
generated with Stanford Graph Base random_graph(85,700,0,0,0,0,0,1,1,33)
undirected graph, represented as a directed one

HAMCYCLE-FREE:
Hamiltonian Cycle with a free guess.
n = 60, one model

DECOMP2:
query decomposition (k=3), one model

BW-P4-Esra-a:
blocksworld problem P4 with Esra's bw_domain_a program

BW-P5-nopush:
blocksworld problem P5 with Axel's C-translation without push

BW-P5-pushbin:
blocksworld problem P5 with Axel's pushed and binarised C-translation

BW-P5-nopushbin:
blocksworld problem P5 with Axel's binarised C-translation without push

3SAT-1:
3SAT with 280 variables and 1204 clauses, randomly generated, one model

3SAT-1-CONSTRAINT:
3SAT with 280 variables and 1204 clauses, randomly generated, one model, constraint encoding

HANOI-Towers:
"Towers of Hanoi" with 3 stacks, 4 disks, and 15 steps.

RAMSEY:
"Ramsey(3,6) != 17"

CRISTAL:
"Deductive database use as done by Christoph Koch in CERN"

HANOI-K:
"Towers of Hanoi" in K with 3 stacks, 4 disks, and 15 steps.

21-QUEENS:
"N-Queens with 21 queens"

MSTDir[V=13,A=40]:
min spanning tree [prim], directed graph with 13 vertices and 40 arcs

MSTDir[V=15,A=40]:
min spanning tree [prim], directed graph with 15 vertices and 40 arcs

MSTUndir[V=13,A=40]:
min spanning tree [prim], undirected graph with 13 vertices and 40 arcs

MSTUndir[V=15,A=40]:
min spanning tree [prim], undirected graph with 15 vertices and 40 arcs

TIMETABLING:
A timetable problem of the first year of the faculty of Science
of University of Calabria for 1 class, one model

Re: Compiler for Red Hat Linux 8

[LinuxVN]

On Wednesday 18 July 2001 05:41 am, you wrote:
> Geoff, thanks for opening up this discussion.
>
> Geoff Keating <geoffk@geoffk.org> writes:
> > It's now time for us here at Red Hat to begin planning for the next
> > major Red Hat Linux release.  One of the first questions that we're
> > looking at is "which compiler should we use?"
>
> [...]
>
> > So, one plan being considered is that we take a compiler out of the
> > Red Hat internal tree (based sometime after 3.0), make a release, and
> > ship that as the default compiler.  Then if we can make the kernel
> > work with this compiler, we have one compiler, which we can fully
> > support.  We didn't have time to do either of these for RHL 7, but we
> > do for RHL 8.
>
> Going to GCC 3.0 is IMO the right way.
>

Yeah ! I'm using RH7.1, after successfully built gcc-3.0, I can't compile my 
kernel (which i did well on original RH7.1)

I hope that this problem will be solve

Bie^n
--------- LinuxVN Group------------

Re: Compiler for Red Hat Linux 8

[Toon Moene]

[ With my GNU Fortran maintainer hat on, but also a little bit as
  member of the SC ... ]

Geoff Keating wrote:

Thanks for discussing this in the open.

> So, one plan being considered is that we take a compiler out of the
> Red Hat internal tree (based sometime after 3.0), make a release, and
> ship that as the default compiler.  Then if we can make the kernel
> work with this compiler, we have one compiler, which we can fully
> support.  We didn't have time to do either of these for RHL 7, but we
> do for RHL 8.

It would have my preference (strongly) if Red Hat based its system
compiler on GCC-3.0.x (whatever x is released at the moment the decision
has to be made) + bug fixes (which would return in the GCC release
branch).

However, ISTR that gcc-2.96-rh contained the subreg byte patch, which
wasn't deemed stable enough for the 3.0 release branch.

How would Red Hat want to deal with that (David Miller, Jakub Jelinek
?).

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Compiler for Red Hat Linux 8

[mike stump]

> Date: Tue, 17 Jul 2001 13:20:07 -0700
> From: Geoff Keating <geoffk@geoffk.org>
> To: gcc@gcc.gnu.org

> So, how do people feel about this?  Does the SC have an opinion?

I'd like to put in a request that neither the gcc team nor the SC
publicly flog RH for doing whatever they do, not because of any
concern for RH, although I could justify it that way as well, but
because the last flogging has made _my_ life harder than it should be
and I don't think it serves anyone by doing this.

If you want to flag a compiler vendor, go flog a non-gcc compiler
vendor.  :-(

If the gcc team or the SC really wants to `fix' what what RH is going
to do, the we need to directly support them, complete with whatever
testing, bug fixing, timetables and releases that RH needs.  If we
don't want to do the work, then we don't get to flog.  The `them', is
us.

Re: Compiler for Red Hat Linux 8

[Benjamin Kosnik]

> That's a necessary but not a sufficient condition.  We still haven't
> frozen libstdc++'s ABI; we can't because it isn't really done and
> still could be made better by more refactoring of templates and such.

Correct.

> To have GNU/Linux applications portable between distros that use your
> compiler and those that use FSF releases, you'll need to use the FSF
> version of libstdc++, or make sure that any deviations don't break
> binary compatibility. 

You'll need to use the latest stable release of the FSF version of libstdc++. 

-benjamin

Re: Compiler for Red Hat Linux 8

[Benjamin Kosnik]

> Going to GCC 3.0 is IMO the right way.

I agree. I think private trees are a bad idea. If Red Hat can't use
gcc-3, I think a branch on the FSF tree is a good idea.

> Compatibility between distributions is important and I'd even like to
> see C++ specified in a newer revision of LSB (we didn't specify C++
> for LSB 1.0 because of these incompatibilities).

I'm willing to work on this. I know Uli and others have already done
some of this work, so please let me know how I can help. (offlist)

I'm also interested in working with you or whoever at SuSe to make
sure that the libstdc++ versions used are similar. 

best,
benjamin

Re: Compiler for Red Hat Linux 8

[Geoff Keating]

A general tone of the responses so far has been "why can't you use a
FSF released compiler without modification?"

I don't think this will be possible.

1. We don't have a process for supporting a compiler that doesn't come
   out of our internal tree.  We would want to be able to do things
   like commit patches to the branch as we send them to customers.  I
   don't think we'd be able to do this on a FSF release branch.
   What's more, we might need to ship a new compiler to a customer
   with a patch, which would imply making a new release if we are to
   use only released versions.

2. We have fixed deadlines and requirements for the compiler that are
   unlikely to be matched by a FSF release process.  For instance,
   suppose that the compiler is broken on mips-linux at the point when
   the branch is frozen for testing by release engineering.  At that
   point, this means that the release will be broken on mips-linux.
   We don't mind, because we aren't doing a MIPS release, but the SC
   might; but we can't change our schedules because of it, which means
   the release has to go out anyway.  The issue of the subreg_byte
   patch has already been raised.  It also means that we might have to
   block patches that could make the release less stable on the
   platforms we care about, which are only a small subset of the
   platforms that GCC 3.0 supports.

3. It's likely that our releng people would need to be in control of
   the release process.  This is likely to be politically difficult.
   It's probably also not something Red Hat wants to do; we spent a
   lot of time trying to convince people that the GCC development
   process was independent and not "controlled by Red Hat", but for
   this we need the control.  

   We also don't have a releng process for making releases out of a
   branch of the FSF tree.  We're already doing something new---this
   release will be in RPMs, not the usual tclish installer---and it's
   hard to do many new things at once.

4. It's possible that, depending on how the IA64 situation goes, we
   might have to have code in the compiler which no-one outside Red
   Hat (and not on the appropriate NDA) can see until some point
   shortly before the release.  I'm not sure how that could be made to
   work.

5. We would prefer to ship a newer compiler than something off the 3.0
   branch.   By the time that this release goes out, the 3.0 branch
   will be over a year old.  You'll note that RHL 7.2 is not out yet,
   and on the normal schedule RHL 8 will be about six months later.

In short, GCC developers wouldn't like it, Red Hat wouldn't like it,
the FSF and the SC wouldn't like it, and it's a recipe for disaster.
This is why I didn't even suggest it in my original mail.

A number of the above points apply even if we are taking a FSF release
and patching it.  It's also questionable what benefit doing this has
over using our internal tree; you end up with a situation like that of
the kernel, where it is technically based off a release but it has
around 400 patches applied.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Compiler for Red Hat Linux 8

[dewar]

<<4. It's possible that, depending on how the IA64 situation goes, we
   might have to have code in the compiler which no-one outside Red
   Hat (and not on the appropriate NDA) can see until some point
   shortly before the release.  I'm not sure how that could be made to
   work.
>>

I hope this does not imply that such versions of the compiler are released
under NDA to organizations outside Redhat (since that would clearly violate
the GPL).

Even within the organization, restricting access to GPL'ed material by
use of NDA's is extremely dubious if you ask me.

But before I say more, please tell us exactly what you meant by the
above ...

Re: Compiler for Red Hat Linux 8

[Geoff Keating]

dewar@gnat.com writes:

> <<4. It's possible that, depending on how the IA64 situation goes, we
>    might have to have code in the compiler which no-one outside Red
>    Hat (and not on the appropriate NDA) can see until some point
>    shortly before the release.  I'm not sure how that could be made to
>    work.
> >>
> 
> I hope this does not imply that such versions of the compiler are released
> under NDA to organizations outside Redhat (since that would clearly violate
> the GPL).

I believe the ia64 compilers are a special case.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Compiler for Red Hat Linux 8

[Joe Buck]

Robert Dewar writes:
> > I hope this does not imply that such versions of the compiler are released
> > under NDA to organizations outside Redhat (since that would clearly violate
> > the GPL).

Geoff Keating writes:
> I believe the ia64 compilers are a special case.

Did RMS grant special permission for the ia64 NDA?

Re: Compiler for Red Hat Linux 8

[Michael Eager]

dewar@gnat.com wrote:
> 
> <<4. It's possible that, depending on how the IA64 situation goes, we
>    might have to have code in the compiler which no-one outside Red
>    Hat (and not on the appropriate NDA) can see until some point
>    shortly before the release.  I'm not sure how that could be made to
>    work.
> >>
> 
> I hope this does not imply that such versions of the compiler are released
> under NDA to organizations outside Redhat (since that would clearly violate
> the GPL).

Unless I'm reading the GPL incorrectly, this does not violate the GPL.

GPL does not require that code which depends on NDA info to be made public.  
It says that if you produce a product using GPL code, that the source must be 
made available to the recipient of the product and that the derived product 
must be licensed under the GPL.  It does not mandate that you publicly 
distribute the product nor does it prohibit your distribution of the product
selectively.

In the normal case, a microprocessor vendor enters into a development 
agreement and NDA with a compiler developer.  The compiler developer modifies
GCC as required and provides the compiler and source to the microprocessor 
vendor.  That product is covered by the GPL.  The compiler developer is
prohibited under terms of the NDA from distributing any proprietary 
information covered by the NDA, or anything derived from this info, which
is in this case is the compiler.

In the normal course of events, the microprocessor under development is
released along with the compiler and other tools.  At this time the sources 
are made available to the recipients of the tools.  The microprocessor vendor
(or the compiler developer, depending on how the development agreement
is written) may submit the source changes to the FSF or other public
source repository.

While this may be convenient and desirable, the GPL does not require 
it, nor does it require that the source be made available to anyone
other than the recipient of the tools.

Please feel free to correct me if I've misunderstood part of the GPL.

--
Michael Eager     eager@mvista.com	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085

Re: Compiler for Red Hat Linux 8

[Justin Guyett]

On Wed, 18 Jul 2001, Michael Eager wrote:

> Unless I'm reading the GPL incorrectly, this does not violate the GPL.
>
> GPL does not require that code which depends on NDA info to be made public.
> It says that if you produce a product using GPL code, that the source must be
> made available to the recipient of the product and that the derived product
> must be licensed under the GPL.  It does not mandate that you publicly
> distribute the product nor does it prohibit your distribution of the product
> selectively.

That's not my impression...

Yes, you can close the source and keep it in-house, and you can distribute
it to only 1 other person if that's what you want to do.  However, the GPL
_forces_ you to give GPL rights to anyone you distribute software to,
which conflicts with every NDA I've ever seen.  That one person you give
it to then must be allowed to distribute it, modified or not, to anyone
[s]he wants.  Otherwise it's not GPL'd, and thus you cannot give it to
them.

The GPL doesn't only protect the right of people to get source code to
modified versions they received, but also protects the right of those
people to distribute their copies, modified or not.  Otherwise anyone can
tack on a "you must get permission from us before you redistribute" which
is obviously not allowed.

If redhat is allowed to do this to gcc, microsoft can do the same thing,
wrap it in an "NDA" license, and even if you get the program and request
source (which they then must provide), you can't make changes or
distribute it to others.  Seems like a NDA is clearly incompatible with
the GPL.


justin

Re: Compiler for Red Hat Linux 8

[Mark Mitchell]

--On Wednesday, July 18, 2001 07:26:41 PM -0700 Justin Guyett 
<jfg@sonicity.com> wrote:

> On Wed, 18 Jul 2001, Michael Eager wrote:
>
>> Unless I'm reading the GPL incorrectly, this does not violate the GPL.

Gentlemen --

  We have this debate every few months, and I'm bored. :-)

  Unfortunately, none of us are lawyers, and few of us are even copyright 
experts, so we can't really be sure.  It would be nice if the FSF would
take an official position, so that we could at least point to what the
intent of the GPL is in this respect, even if we couldn't be sure of
it's actual meaning.  (You can never be sure until you go to court.)

  Would one of you care to contact the FSF about this issue directly?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Compiler for Red Hat Linux 8

[akbar A.]

good/large example of this would be the ps2.


laterz,
-akbar A.
; http://vertexabuse.cjb.net



On Wed, 18 Jul 2001 18:59:09 -0700
Michael Eager <eager@mvista.com> wrote:

> dewar@gnat.com wrote:
> > 
> > <<4. It's possible that, depending on how the IA64 situation goes, we
> >    might have to have code in the compiler which no-one outside Red
> >    Hat (and not on the appropriate NDA) can see until some point
> >    shortly before the release.  I'm not sure how that could be made to
> >    work.
> > >>
> > 
> > I hope this does not imply that such versions of the compiler are released
> > under NDA to organizations outside Redhat (since that would clearly violate
> > the GPL).
> 
> Unless I'm reading the GPL incorrectly, this does not violate the GPL.
> 
> GPL does not require that code which depends on NDA info to be made public.  
> It says that if you produce a product using GPL code, that the source must be 
> made available to the recipient of the product and that the derived product 
> must be licensed under the GPL.  It does not mandate that you publicly 
> distribute the product nor does it prohibit your distribution of the product
> selectively.
> 
> In the normal case, a microprocessor vendor enters into a development 
> agreement and NDA with a compiler developer.  The compiler developer modifies
> GCC as required and provides the compiler and source to the microprocessor 
> vendor.  That product is covered by the GPL.  The compiler developer is
> prohibited under terms of the NDA from distributing any proprietary 
> information covered by the NDA, or anything derived from this info, which
> is in this case is the compiler.
> 
> In the normal course of events, the microprocessor under development is
> released along with the compiler and other tools.  At this time the sources 
> are made available to the recipients of the tools.  The microprocessor vendor
> (or the compiler developer, depending on how the development agreement
> is written) may submit the source changes to the FSF or other public
> source repository.
> 
> While this may be convenient and desirable, the GPL does not require 
> it, nor does it require that the source be made available to anyone
> other than the recipient of the tools.
> 
> Please feel free to correct me if I've misunderstood part of the GPL.
> 
> --
> Michael Eager     eager@mvista.com	408-328-8426	
> MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085

Re: Compiler for Red Hat Linux 8

[Per Bothner]

dewar@gnat.com writes:

> I hope this does not imply that such versions of the compiler are released
> under NDA to organizations outside Redhat (since that would clearly violate
> the GPL).

If A gives B a GPL'd compiler under the proviso of a NDA prohibiting
B from redistributing the compiler that would violate the GPL.

If A gives B a GPL'd compiler under the proviso of a NDA prohibiting
A from distributing the compiler to third parties that is a very
different matter.  I don't think that in itself violate the GPL.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Compiler for Red Hat Linux 8

[Joe Buck]

> dewar@gnat.com writes:
> 
> > I hope this does not imply that such versions of the compiler are released
> > under NDA to organizations outside Redhat (since that would clearly violate
> > the GPL).

First off, I've gotten a communication from someone who should know,
saying that the ia64 NDA for GCC is no longer in force, so this isn't
relevant any more.  Geoff, you might want to re-check.

Per Bothner wrote:
> If A gives B a GPL'd compiler under the proviso of a NDA prohibiting
> B from redistributing the compiler that would violate the GPL.
> 
> If A gives B a GPL'd compiler under the proviso of a NDA prohibiting
> A from distributing the compiler to third parties that is a very
> different matter.  I don't think that in itself violate the GPL.

Nope, read it again.  The GPL requires that all recipients be given a
license to redistribute.

If you were right, then A could charge B an arbitrarily high charge for
the service of distribution, and thus have an effectively proprietary
compiler, since the only way to get it is to pay A.

Re: Compiler for Red Hat Linux 8

[Per Bothner]

Joe Buck <jbuck@synopsys.com> writes:

> Per Bothner wrote:
> > If A gives B a GPL'd compiler under the proviso of a NDA prohibiting
> > A from distributing the compiler to third parties that is a very
> > different matter.  I don't think that in itself violate the GPL.
> 
> Nope, read it again.  The GPL requires that all recipients be given a
> license to redistribute.

But A is not the recipient - A is the one providing the compile to B.
B is of course free to redistribute the compiler.  But we are talking
about the case where the NDA binds *A*, not B.  Think A==RedHat;
B==Intel; RedHat signs NDA and develops compiler port; Intel receives
compiler from GCC.  RedHat is bound by the NDA; Intel is free to
r-distribute GCC under GPL, and is not bound by the NDA;  viola no
conflict.

Now if Intel then distributes GCC to a third party under an NDA,
*then* there is a confloct.

> If you were right, then A could charge B an arbitrarily high charge for
> the service of distribution, and thus have an effectively proprietary
> compiler, since the only way to get it is to pay A.

A is not charging B for distribution.  A is charging for development.
B is the party that made A sign an NDA in exchange, not vice versa.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: Compiler for Red Hat Linux 8

[Alex Rosenberg]

on 7/18/01 10:41 PM, Per Bothner at per@bothner.com wrote:

> Joe Buck <jbuck@synopsys.com> writes:
> 
>> Per Bothner wrote:
>>> If A gives B a GPL'd compiler under the proviso of a NDA prohibiting
>>> A from distributing the compiler to third parties that is a very
>>> different matter.  I don't think that in itself violate the GPL.
>> 
>> Nope, read it again.  The GPL requires that all recipients be given a
>> license to redistribute.
> 
> But A is not the recipient - A is the one providing the compile to B.
> B is of course free to redistribute the compiler.  But we are talking
> about the case where the NDA binds *A*, not B.  Think A==RedHat;
> B==Intel; RedHat signs NDA and develops compiler port; Intel receives
> compiler from GCC.  RedHat is bound by the NDA; Intel is free to
> r-distribute GCC under GPL, and is not bound by the NDA;  viola no
> conflict.
> 
> Now if Intel then distributes GCC to a third party under an NDA,
> *then* there is a confloct.

It sounds like you've just described a common situation. Notably, this
sounds like the Playtation 2 situation.

+------------------------------------------------------------+
| Alexander M. Rosenberg           < mailto:alexr@_spies.com > |
| Nobody cares what I say. Remove the underscore to mail me. |

Re: Compiler for Red Hat Linux 8

[Jonathan Larmour]

In article < m21yndbhm8.fsf@kelso.bothner.com > you write:
>Joe Buck <jbuck@synopsys.com> writes:
>
>> Per Bothner wrote:
>> > If A gives B a GPL'd compiler under the proviso of a NDA prohibiting
>> > A from distributing the compiler to third parties that is a very
>> > different matter.  I don't think that in itself violate the GPL.
>> 
>> Nope, read it again.  The GPL requires that all recipients be given a
>> license to redistribute.
>
>But A is not the recipient - A is the one providing the compile to B.
>B is of course free to redistribute the compiler.  But we are talking
>about the case where the NDA binds *A*, not B.  Think A==RedHat;
>B==Intel; RedHat signs NDA and develops compiler port; Intel receives
>compiler from GCC.  RedHat is bound by the NDA; Intel is free to
>r-distribute GCC under GPL, and is not bound by the NDA;  viola no
>conflict.
>
>Now if Intel then distributes GCC to a third party under an NDA,
>*then* there is a confloct.

I believe the relevant clauses are indeed, from 6:

"You may not impose any further restrictions on the recipients' exercise
of the rights granted herein."

So if you redistribute, you can't insist they sign an NDA. Of course
what will happen is that the distributor (A) *won't* distribute it to
B if B has not signed an NDA. A is not _obliged_ to redistribute to B.[1]

Then as far as B is concerned, clause 7 applies, namely:

"If you cannot distribute so as to satisfy simultaneously your obligations
under this License and any other pertinent obligations, then as a
consequence you may not distribute the Program at all."

which prevents any further conflict.

So what you can't do is for A to redistribute to B and add an additional
license with the redistribution saying "you can't give this to anyone
else". That's not the same as only choosing to redistribute it to people
who have already signed an agreement separately.

Jifl - who isn't a lawyer, but gets interested in this type of stuff ;)

[1] But only if clause 3a applies. If 3b applies, A can be obliged to
redistribute to any third party.
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: Compiler for Red Hat Linux 8

[dewar]

>>I believe the ia64 compilers are a special case.


what does that mean?

RE: Compiler for Red Hat Linux 8

[Bernard Dautrevaux]

> -----Original Message-----
> From: Toon Moene [ mailto:toon@moene.indiv.nluug.nl ]
> Sent: Thursday, July 19, 2001 12:30 AM
> To: Ken Whaley
> Cc: Sergey Ostrovsky; H . J . Lu; gcc@gcc.gnu.org
> Subject: Re: Compiler for Red Hat Linux 8
> 
> 
> Ken Whaley wrote:
> 
> > I?ve just gone through this process, pretty much exactly
> > as Sergey described, including digging around trying to
> > find info on what patches, versions, etc. of the tools
> > are required, and agree that it?s a sort of black magic.
> > Saying ?use an official released version to build your
> > system? becomes a lot more palatable if there would always
> > be an up-to-date trio of officially released binutils/glibc/gcc
> > that all work together.  Easier said than done, I agree, but
> > that would be a wonderful thing to achieve.   When these 3
> > pieces achieve alignment so rarely, it doesn?t suprise me that
> > vendors dig in and make their own modifications.
> 
> Well, I'm not that convinced that the problems related here are absent
> on your Operating System Of Choice, i.e., the one that insert question
> marks in your e-mails everytime you think you type a quote (')
> character.
> 

I'm not sure I understand you: I get the original mail from Ken (through the
mailing list of course) with proper quotes! It seems it's YOUR Operating
System Of Choice (or one of the mail relays between the mailing list and
your system) that replace quotes with question marks...

Regards,

	Bernard

PS: As a matter of fact the mailing list archive agrees with me: the quotes
get in undisturbed but YOU get them back changed...

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: Compiler for Red Hat Linux 8

[Toon Moene]

Bernard Dautrevaux wrote:

[ This is getting off-topic fast, but one time more ... ]

> I'm not sure I understand you: I get the original mail from Ken (through the
> mailing list of course) with proper quotes! It seems it's YOUR Operating
> System Of Choice (or one of the mail relays between the mailing list and
> your system) that replace quotes with question marks...

This is how my inbox sees the quotes of the text Ken sent:

<QUOTE>
I\x92ve just gone through this process, pretty much exactly
as Sergey described, including digging around trying to
find info on what patches, versions, etc. of the tools
are required, and agree that it\x92s a sort of black magic.
Saying \x93use an official released version to build your
system\x94 becomes a lot more palatable if there would always
</QUOTE>

Doesn't look like the ASCII ' encoding to me ...

[ If you're still not convinced, I can send you an `od' dump of the mail
]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

RE: Compiler for Red Hat Linux 8

[Bernard Dautrevaux]

> -----Original Message-----
> From: Toon Moene [ mailto:toon@moene.indiv.nluug.nl ]
> Sent: Thursday, July 19, 2001 10:18 AM
> To: Bernard Dautrevaux
> Cc: Ken Whaley; Sergey Ostrovsky; H . J . Lu; gcc@gcc.gnu.org
> Subject: Re: Compiler for Red Hat Linux 8
> 
> 
> Bernard Dautrevaux wrote:
> 
> [ This is getting off-topic fast, but one time more ... ]

Last one for me too...

> 
> > I'm not sure I understand you: I get the original mail from 
> Ken (through the
> > mailing list of course) with proper quotes! It seems it's 
> YOUR Operating
> > System Of Choice (or one of the mail relays between the 
> mailing list and
> > your system) that replace quotes with question marks...
> 
> This is how my inbox sees the quotes of the text Ken sent:
> 
> <QUOTE>
> I\x92ve just gone through this process, pretty much exactly
> as Sergey described, including digging around trying to
> find info on what patches, versions, etc. of the tools
> are required, and agree that it\x92s a sort of black magic.
> Saying \x93use an official released version to build your
> system\x94 becomes a lot more palatable if there would always
> </QUOTE>
> 
> Doesn't look like the ASCII ' encoding to me ...
> 
> [ If you're still not convinced, I can send you an `od' dump 
> of the mail
> ]

Oh I'm convinced!... I just now realize your mail reader isn't able to
display correctly iso-8859-1 (latin-1) character set :-)

Looking at the headers you'll see that you send only us-ascii (a quite old
subset of iso-8859) while a lot of people use the *standard* iso charset,
where 0x91 is "opening single quote", 0x92 closing, 0x93 "opening double
quote" and 0x94 closing.

Regards,

	Bernard

PS: Just curious: how did you send Dutch diacritics if you only use us-ascii
(or is Dutch different from other german languages in not using any of
these?)

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

RE: Compiler for Red Hat Linux 8

[Joseph S. Myers]

On Thu, 19 Jul 2001, Bernard Dautrevaux wrote:

> Looking at the headers you'll see that you send only us-ascii (a quite old
> subset of iso-8859) while a lot of people use the *standard* iso charset,
> where 0x91 is "opening single quote", 0x92 closing, 0x93 "opening double
> quote" and 0x94 closing.

Have you actually *read* ISO 8859-1, or the free equivalent ECMA-94, or an
adopted national standards body version, or even the draft
<URL: http://wwwold.dkuug.dk/JTC1/SC2/WG3/docs/n411.pdf >?  These are not
graphic characters in the standard.

If you haven't actually read a standard (any standard), please don't
spread misinformation about its contents by making claims about the
standard without referring to it.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Compiler for Red Hat Linux 8

[Roman Zippel]

Hi,

> Looking at the headers you'll see that you send only us-ascii (a quite old
> subset of iso-8859) while a lot of people use the *standard* iso charset,
> where 0x91 is "opening single quote", 0x92 closing, 0x93 "opening double
> quote" and 0x94 closing.

AFAIK these are MS extensions...

bye, Roman

Re: Compiler for Red Hat Linux 8

[Russ Allbery]

Bernard Dautrevaux <Dautrevaux@microprocess.com> writes:

> Looking at the headers you'll see that you send only us-ascii (a quite
> old subset of iso-8859) while a lot of people use the *standard* iso
> charset, where 0x91 is "opening single quote", 0x92 closing, 0x93
> "opening double quote" and 0x94 closing.

No, they're not.  ISO 8859-1 doesn't assign any code points between 0x7F
and 0xA0.

0x91 through 0x94 are assigned that meaning in Windows Code Page 1252,
which is not a standard of any type whatsoever.  Those characters are used
for Windows "smart quotes", and will be unreadable to anyone not using
Windows unless their software specifically caters to mislabelled character
sets or the message is correctly labelled and there is a CP-1252 font
available.  Messages using those characters should be properly tagged with
charset=windows-1252 or they're in violation of the MIME standard.  Most
software on Microsoft platforms does not correctly label this character
set and produces broken messages like the one that started this sub-thread
(which was labelled as ISO 8859-1, despite the fact that it didn't use
that character set).

I'm sure the original author was completely unaware that this was
happening; most Microsoft software makes it extremely easy to make this
mistake and apparently doesn't care about producing readable messages on
non-Microsoft platforms.  Usually turning off Smart Quotes will fix the
problem.

< http://ppewww.ph.gla.ac.uk/%7Eflavell/iso8859/iso8859-pointers.html#unass >
has additional details on why those code points are intentionally
unassigned in ISO 8859-1 (on 7-bit systems, they could be interpreted as
control codes when the eighth bit was stripped, producing serious
problems -- this was a significant issue at the time that ISO 8859-1 was
standardized).

-- 
Russ Allbery (rra@stanford.edu)             < http://www.eyrie.org/~eagle/ >

Re: Compiler for Red Hat Linux 8

[dewar]

<<I'm sure the original author was completely unaware that this was
happening; most Microsoft software makes it extremely easy to make this
mistake and apparently doesn't care about producing readable messages on
non-Microsoft platforms.  Usually turning off Smart Quotes will fix the
problem.
>>

What is more amazing is that even when this obvious violation of standards
is pointed out, you get people, as in this case, claiming that *you* are
non-standard because you don't follow the microjunk special stuff.

Re: Compiler for Red Hat Linux 8

[dewar]

<<  Unfortunately, none of us are lawyers, and few of us are even copyright
experts, so we can't really be sure.  It would be nice if the FSF would
take an official position, so that we could at least point to what the
intent of the GPL is in this respect, even if we couldn't be sure of
it's actual meaning.  (You can never be sure until you go to court.)
>>

One helpful thing to realize in such debates (even if boring :-) is that
there is really no such thing as "violating" the GPL. The GPL is a license
agreement that allows you to perform copying and creation of deriviative
works under certain limited conditions. If you copy software and the GPL
does not give you permission to do this copy, then the copyright has
been violated. The point is that it is up to you to positively show that
the GPL permits the copying.

RE: Compiler for Red Hat Linux 8

[Bernard Dautrevaux]

> -----Original Message-----
> From: Joseph S. Myers [ mailto:jsm28@cam.ac.uk ]
> Sent: Thursday, July 19, 2001 11:40 AM
> To: Bernard Dautrevaux
> Cc: gcc@gcc.gnu.org
> Subject: RE: Compiler for Red Hat Linux 8
> 
> 
> On Thu, 19 Jul 2001, Bernard Dautrevaux wrote:
> 
> > Looking at the headers you'll see that you send only 
> us-ascii (a quite old
> > subset of iso-8859) while a lot of people use the 
> *standard* iso charset,
> > where 0x91 is "opening single quote", 0x92 closing, 0x93 
> "opening double
> > quote" and 0x94 closing.
> 
> Have you actually *read* ISO 8859-1, or the free equivalent 
> ECMA-94, or an
> adopted national standards body version, or even the draft
> <URL: http://wwwold.dkuug.dk/JTC1/SC2/WG3/docs/n411.pdf >?  
> These are not
> graphic characters in the standard.

Ooops, my fault ;-( 

Reading a bit too fast and not noticing some green/black differences in
character tables, where green means "Microsoft-specific", in a Web-page
documenting the 8859-1 character set standard; OK I agree, I was not reading
the OFFICIAL standard, but...

> 
> If you haven't actually read a standard (any standard), please don't
> spread misinformation about its contents by making claims about the
> standard without referring to it.
> 

I should loudly apologize here.

I was fooled by reading a *description* of the standard, found on the web,
instead of the *official* standard (I don't know anyway if it's accessible
on-line) 

AND 

by Micro$oft "claiming" that it send iso-8859-1 encoded mail while its in
fact microsoft-extended-8859-1 

AND 

by this being so well-knowned by people commenting the standard that they
publish character tables where the main indication of this m$-ism (if you
read a bit fast and jump to the nice character tables) is that some
characters are displayed in dark green instead of black

and also probably as I don't have such good eyes :-)

The morale for this may be: Don't trust too much programs (be them Microsoft
or not) that claim to be conforming to a standard and *always* verify
several times before... 

Now I think it's enough for this broadly off-topic sub-thread :-)

Best regards

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
--------------------------------------------