On Tue, May 24, 2005 at 04:43:38PM +1200, Mark Davies wrote:
> Not sure if this should be considered an R problem or a gcc3-f77 problem or a 
> pkg tools/infrastructure problem but on systems that need/use the gcc3-f77 
> package (eg solaris systems using gcc3), if you install the R package the "R" 
> cmd is unable to compile fortran.
> 
> This is because the gcc3-f77 package installs a "g77" but no "f77".  When 
> building R the tools infrastructure provides both an "f77" and a "g77" (that 
> eventually point to the real "g77") and the R configure prefers to use the 
> "f77" which is fine during the build of the package but once its installed 
> references to "f77" remain in the R package and there is no such command for 
> it to use on the standard path.
> 
> Any suggestions on how to fix?
> 
> Get the gcc3-f77 package to install an f77 as well?  (The post-install stage 
> of its Makefile has this commented out)
> Get the pkgsrc infrastructure to not provide an f77 when one wont exist after 
> the build?  (no idea how to do this)
> Get R to prefer g77 over f77?
 
I've wondered about this issue.  R is not the only example.  Take a look at
math/octave and you'll see there are some hacks to make sure the actual path
to the real compiler ends in in mkoctfile which is a script installed by
octave and later used by users to compile in new code.

I'm wondering if for packages such as these we need to do something like
install a wrapper script for the compiler and have mkoctfile, or whatever,
point to that.  For example,

create and install
/usr/pkg/libexec/octave/{cc,c++,f77}

and in mkoctfile, point to those.

Where things really can get ugly is if we convince some package that our
compiler accepts sunpro or whatever options, use our tool wrappers to actually
use gcc for the build, but then later yank away the tool wrappers.  Now
you're left with a non-functional package.

Sorry for directing this away from R, but I think the discussion holds equally
for both of these packages.

-Dan

--