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: David Holland <dholland-bugs%netbsd.org@localhost>, 
 toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
 netbsd-bugs%netbsd.org@localhost
Subject: Re: toolchain/47503: Request automated addition of gfortran to base
 compiler set
Date: Fri, 25 Jan 2013 09:00:17 -0600

 On 01/24/2013 23:35, David Holland wrote:
 > The following reply was made to PR toolchain/47503; it has been noted by 
 > GNATS.
 >
 > From: David Holland<dholland-bugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: toolchain/47503: Request automated addition of gfortran to base
 >   compiler set
 > Date: Fri, 25 Jan 2013 05:30:02 +0000
 >
 >   On Fri, Jan 25, 2013 at 02:40:01AM +0000, jwbacon%tds.net@localhost wrote:
 >    >  The pkgsrc gcc packages are not viable at this point, since they
 >    >  only work on NetBSD.
 >
 >   Not AFAIK...
 I misspoke.  They may also work on DragonFly.
 
 Presently (or at least recently) none of the gcc packages build on RHEL 
 5, CentOS 6, or Darwin.  I put some effort into patching them and got 
 one to build on RHEL, but still experienced runtime errors.  I abandoned 
 the effort when we started moving toward CentOS 6, which has a mature 
 base compiler suite.
 
 
    >  It would be hard to match the various base toolchain versions
    >  anyway, which leads to mixing toolchains in package builds.
 
   At least in theory this shouldn't matter.
 
 Actually, the gcc project doesn't guarantee object code compatibility 
 across versions, so it does matter in theory.  In practice, it's 
 generally OK to mix two GNU compilers with the same major version, but I 
 have run into link problems in the past when mixing gcc versions.
 
 There's a chance that relying on gcc packages for Fortran support while 
 using the base C/C++ compilers will bite pkgsrc users down the road.  A 
 gfortran in the base would eliminate that risk.
 
 >
 >    >  Finally, it would be messy to use the base
 >    >  gfortran on some platforms and a gcc package on others.
 >
 >   This is the whole point of the compiler logic in pkgsrc, though.
 >
 >   pkgsrc is at least in theory capable of installing a FORTRAN compiler
 >   of your choice, more or less on its own, if and only if the base
 >   FORTRAN compiler is nonexistent or unsuitable.
 >
 >   If this isn't working (or doesn't know about gfortran vs. g77 vs. f2c
 >   or whatnot) it should be fixed.
 I would agree that it *should* be fixed, but it's an awfully squirrelly 
 problem and I think it would be much easier and much safer to build 
 gfortran as part of the base.
 
 I've been wrangling with these issues for over a year and a complete 
 base compiler suite seems like the only clean, safe solution.
 
 Thanks,
 
      -J
 
 -- 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Jason W. Bacon
 jwbacon%tds.net@localhost
 http://personalpages.tds.net/~jwbacon
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~