> On Thu, 2 Jan 2003, Igor Sobrado wrote:
> 
> > It is practically dropped by GNU, they are developing a new compiler,
> 
> Do you have a posting or message indicating it was dropped? Just because a
> g95 is under development doesn't mean g77 has been dropped. Dropped would
> mean that if I get recent gcc sources g77 isn't there.

Hello Bill!

Yes, it is now in maintenance mode.  Only _small_ fixes "might"
be applied.  Look for example at:

  http://gcc.gnu.org/ml/gcc/2000-07/msg00587.html

It is not clear who will maintain it now:

  http://world.std.com/~burley/g77-why.html

But, please, do not misunderstand what am I saying. I DO NOT SAY IT MUST
BE MOVED TO THE PKGSRC SYSTEM BECAUSE ITS LACK OF SUPPORT, there are nice
programs that were not updated in the last ten years and are great
products.  What I am saying is that:

  - It is not required in the base system (NetBSD does not need it
    to build a new kernel, or the world itself)

  - There is a small number of users that need it.  All the research
    groups I know at my old department prefer buying commercial
    FORTRAN compilers (Fujitsu, and HP ones).

  - It is currently in a very bad status, and it will not be improved,
    only fixed.  It has been declared "in maintenance mode" before
    being a mature product.  See other posts on this mailing list.

I cannot understand why g77 users cannot add it from the pkgsrc
(where a most recent release of GCC is available by now).  Because it
is required to build other software packages?  Well, in this case
gtk, qt, Motif, and so on should be added to the base system too.
At least those libraries and tools that do not require X support...
One of the keys with pkgsrc is that it is aware about the requirements
of software being build.

If someone building a package from the pkgsrc system is able to add
software with dependencies to the system, why g77 users cannot do
the same when g77 is required to build a package _or_ it is the
package itself?

I cannot see the problem about moving it to pkgsrc.

> > and g77 is frozen since mid-90.  That compiler does not support
> > FORTRAN-related standards.  It has known bugs and, as I observed
> > above, it is a FORTRAN 77 compiler with "some" FORTRAN 90 extensions.
> > A fully standards-compliant compiler will be nice.
> 
> Do you have one we can use?

A fully ANSI compliant FORTRAN compiler?  Sorry, I do not know about it.
Perhaps Intel compilers will do a nice job in NetBSD/i386,
but not when running NetBSD in one of the other 35 currently
supported platforms.  But that is not a reason to provide g77 in
the base system.

> Ok, so you aren't using it (well your Physics department isn't). That
> doesn't mean we should drop it too.

Now I am a doctoral candidate at the Computer Engineering department, but
I am a physics grad.  By the way, when I went to an ACM/SIGCOMM
plenary session about two years ago, convincing people that my idea
about mobile code works was easy (I onle need three days!!!)  :-)

No, moving a package to the pkgsrc system is not dropping that package.
Has NetBSD dropped Gnome, KDE, nmh, or TeX?  I hope that the answer
will be no.

> So what alternative can you propose? i.e. what can we put in the base
> system in its place?

Is there a strong requirement to have a FORTRAN compiler in the base
system at present?  If true, why not adding nmh, Perl, or TeX?  A lot
of us are using those nice programs too.  I am happy building those
programs from pkgsrc either in /usr/pkg or another place.

> And gcc doesn't have bugs?? :-)

The key is that gcc is under active development.  That means not only
that bugs are fixed, but also that people is worried about improving
its quality (like following standards, supporting the ANSI X3 committees,
mainly X3J11 and X3J16, or changing the standard C library model to best
fit with requirements of products of other manufacturers).

As I said, I like software that has not been upgraded in the latest ten
years, why not using that software?  But that software has been freezed
in a very mature state.  I like too software in maintenance mode, I do
not like great changes from a release to the next one, that IS the reason
I think that the BSDs are great products.  BSD maintainers are not
playing with memory-models, swapping/pagging algorithms, or big kernel
changes.  I like too the stability of the C library, the function
prototypes, and so on, that makes running older precompiled binaries
as easy in NetBSD than in other high-quality OSes (like Solaris).

> We put it in for a reason. You have not addressed that reason. Your case
> for removing g77 will go much farther if you can explain to everyone how
> that reason doesn't apply.

The reason is not running a second gcc compiler, am I wrong?

I do not see why g77 users cannot build a new (and updated) GCC
release from pkgsrc.  Most users do it now only to get an updated
gcc, or g++.

That means that Java, and others compilers that are now being added
to GCC 3.x *will be* in the NetBSD base system if the GNU Compiler
Collection is upgraded?

IMHO, NetBSD (better all the BSDs!) should provide small and
VERY WELL TESTED C and C++ compilers to build both the kernel
and the world.  That software needs to be stable, but it is
not required to be the *latest* stable release.  State-of-the-art
GCC compilers can be provided through pkgsrc.

That goal can be easily achieved with my proposal in the other
thread (adding /usr/contrib to NetBSD).  My first proposal was
not providing a not-so-updated but well tested gcc, and g++ in
/usr/contrib/bin, but it can be done too, and it will simplify
managing the compilers.  Users that only need C/C++ compilers
to update the operating system can use those compilers, users
that are aware about the advantages of the latest stable releases
(or that need java, ADA, or FORTRAN support on their machines)
can build a new compiler and install it at /usr/pkg (/usr/local
should be for software and scripts made locally).

> > > > Moving it to the ports collection is not bad.
> 
> Please note, it is pkgsrc. Ports are the different things NetBSD runs on.
> :-)

Thanks a lot for that explanation!  I am relatively new to the BSD
world and I make a lot of mistakes (like sending those proposal to
the PR system before discussing them in the right mailing list...)
I will try to be most accurate in the future, but all it is a
continuos learning process.

Best regards,
Igor.

-- 
Igor Sobrado, UK34436 - sobrado@acm.org