Re: toolchain/47503: Request automated addition of gfortran to base compiler set

[Jason bacon <jwbacon%tds.net@localhost>]

The following reply was made to PR toolchain/47503; it has been noted by GNATS.

From: Jason bacon <jwbacon%tds.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: "Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>, 
 toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
 netbsd-bugs%netbsd.org@localhost, Aleksej Saushev <asau%inbox.ru@localhost>
Subject: Re: toolchain/47503: Request automated addition of gfortran to base
 compiler set
Date: Tue, 05 Feb 2013 12:42:17 -0600

 On 2/5/13 7:20 AM, Valeriy E. Ushakov wrote:
 > The following reply was made to PR toolchain/47503; it has been noted by 
 > GNATS.
 >
 > From: "Valeriy E. Ushakov"<uwe%stderr.spb.ru@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: toolchain/47503: Request automated addition of gfortran to base 
 > compiler set
 > Date: Tue, 5 Feb 2013 17:18:38 +0400
 >
 >   On Mon, Feb 04, 2013 at 22:55:08 +0000, Jason Bacon wrote:
 >
 >   >   RHEL and CentOS already include gfortran in the base, so a GCC package
 >   >   is unnecessary here.
 >
 >   Does a typical Linux distribution even have a "base" in the same sense
 >   we speak about base system in BSDs?  My impression from my limited
 >   exposure is that in NetBSD terms their "base" gcc is what we would
 >   call a gcc package.
 Not exactly.  RHEL/CentOS don't necessarily have any development tools 
 out of the box,
 but a Yum package in the 'base' category installs them into /usr/bin.  
 This would be the first
 and usually only compiler suite on the system, so it's akin to the BSD 
 base compilers.
 
 The development tools "group" (like a metapackage) is what most people 
 use.  It installs all
 the compilers, flex, bison, subversion, etc.
 
 
https://support.eapps.com/index.php?/Knowledgebase/Article/View/438/55/user-guide---installing-the-centos-development-tools-gcc-flex-etc
 >
 >
 >   >   We could get by with a GCC package on NetBSD, but since GCC 4.5 is now
 >   >   being used as the base compiler, and pkgsrc already contains the logic
 >   >   to use a base gfortran if it's present, I think it would make sense to
 >   >   have gfortran in the base (at least as an option).  This would ensure
 >   >   object code compatibility with code compiled by the base gcc and g++ as
 >   >   well.
 >
 >   Are there some known ABI issues between recent 4.x series, or is it
 >   more in the bad vibes area? (I use it as a neutral technical (sic!:)
 >   term here)
 I'm not aware of any issues between recent 4.x compilers, but that does 
 not make me
 confident that they don't exist.  I'll be more worried with GCC 5.0 
 becomes the preferred
 package.
 >
 >
 >   >   I think it would take fewer man-hours in the long run to put it
 >   >   in the base, and the end result would be cleaner and safer.
 >
 >   ... for as long as gfortran in gcc 4.5 is considered ok, until some
 >   horrible bug that triggers only under rare conditions makes it
 >   unsuitable because you can't trust it any more.
 >
 >   ... or when gcc 4.N+1 has optimizer improvements that cut you batch
 >   wall time by days and you absolutely want to use 4.N+1 instead of that
 >   old base 4.5
 >
 >   ... or until we decide to upgrade the base compiler to, say, gcc 4.7
 >   and it turns out newer gfortran have issues.
 >
 >   I'm sure pkgsrc folks can continute the list.
 >
 >   From the base system persepective I'd say it would take fewer
 >   man-hours in the long run to make sure gfortran packages work smoothly.
 >
 >   . de facto, optional code tends to bit-root
 >
 >   . de jure, once in base, optional code is, effectively, mandatory
 >
 >   . it's "mandatory optional" on *all* ports, including those no-one
 >     would ever going to use for HPC (vax heyday is over; jornada 680
 >     cluster?)
 >
 >   . it will have to be in the standard builds, so limited resources of
 >     netbsd autobuid cluster will be spent on building it (for all
 >     ports).
 This is why I initially suggested only providing instructions or a 
 script for rebuilding the
 base compiler suite with gfortran enabled, rather than including it in 
 the generic installation.
 Based on my experience with manual GCC builds, once you get the build 
 working, adding
 Fortran is unlikely to cause many issues.
 >
 >   . we will have to solve *exactly the same* ABI compatibility issues
 >     (if any) during base gcc upgrade as pkgsrc needs to solve for a gcc
 >     pacakge.
 The ABI issues I'm worried about stem from the fact that the GCC package 
 chosen
 as a prerequisite might be a different version than the base compilers 
 and might
 be built with different options.  Rebuilding the base suite guarantees 
 the same
 version, --build, --host, --target, etc.
 >
 >   So the last item is the same for base and pkgsrc and all previous
 >   items are extra work for base.
 >
 >   It's most likely that my perception of this problem is affected by my
 >   wearing base-hacker hat (mine might have -5 penalty to wisdom and
 >   cursed), so, please, excuse me if this mail might come across as a bit
 >   antagonistic - it's not inteded that way.
 >
 >   -uwe
 >
 No worries.  I see this as collaborative discourse, not a flame war.  
 The least
 that can come of it is we all end up with a better understanding of the 
 issues.
 
 I won't be offended if the developers doesn't agree with my suggestions.  I
 just want to have a discussion to raise awareness of the issues, and
 offer some ideas for solving them.
 
 Regards,
 
 -- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Jason W. Bacon
 jwbacon%tds.net@localhost
 http://personalpages.tds.net/~jwbacon
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~