Skip to content

further f77/gfortran

7 messages · Brian Ripley, Ben Bolker, Dirk Eddelbuettel +1 more

Original
Ben Bolker
# 
OK: despite Dirk's very kind help, I decided that
trying to deal with R configuration and Debian configuration
simultaneously was too difficult.

  I did manage to solve my problem by reconfiguring/making/
installing all of 2.3.1 from source:

./configure F77=/usr/bin/g77
make
make install

   A few questions inspired by this experience:

  (1) it seems a bit odd that R sets F77=gfortran
by default, since the system has both g77 and gfortran
compilers on it, and given that there is a separate
variable (FC) for the Fortran 90/95 compiler --
does it make any sense to switch
the search order in configure so that g77 comes up first if present?

  (2) I couldn't figure out a way to set the F77 variable
on a per-package basis: adding a src/Makevars file or a configure
file to the package didn't seem to help, but perhaps I didn't
put it in the right place/get it exactly right.  Any clues?

  cheers
    Ben Bolker
Dirk Eddelbuettel
#
On 7 June 2006 at 11:44, Ben Bolker wrote:
|   OK: despite Dirk's very kind help, I decided that

Yeah, kind but still not useful to you. No cigar yet :)

| trying to deal with R configuration and Debian configuration
| simultaneously was too difficult.

[ I'd still like to learn from useRs what I could do to make the Debian
package more appealing. Local rebuilds seems natural to me; I do that eg on
the Ubuntu boxen at work to combine 'stability' ('frozen' outer system) with
'current' apps where I need and what them. By keeping those within the
package management framework, I feel I combine the best of two worlds. YMMV. ]

|   I did manage to solve my problem by reconfiguring/making/
| installing all of 2.3.1 from source:
| 
| ./configure F77=/usr/bin/g77
| make
| make install
| 
|    A few questions inspired by this experience:
| 
|   (1) it seems a bit odd that R sets F77=gfortran
| by default, since the system has both g77 and gfortran
| compilers on it, and given that there is a separate
| variable (FC) for the Fortran 90/95 compiler --
| does it make any sense to switch
| the search order in configure so that g77 comes up first if present?
| 
|   (2) I couldn't figure out a way to set the F77 variable
| on a per-package basis: adding a src/Makevars file or a configure
| file to the package didn't seem to help, but perhaps I didn't
| put it in the right place/get it exactly right.  Any clues?

That came up recently:

a)  ~/.Makevars  (as I recall)

b)  on a per invocation basis:
	MAKEFLAGS="FFLAGS=-O1" R CMD INSTALL ...
    is something that worked for me.

That said, I personally still dislike that I cannot 'undo' the settings the
R's global Makeconf.  I'd love to turn debugging, optimisation, ... on/off on
demand. 

Dirk
Brian Ripley
#
On Wed, 7 Jun 2006, Ben Bolker wrote:

            

      
      
      
    

        
That's not what is happening, I believe.  If the C compiler is gcc4, it 
preferentially picks gfortran, as gcc4 and g77 are not compatible on 
structures such as double complex on at least some architectures.  From 
the R.m4 file

## * If the C compiler is gcc, we try looking for a matching GCC Fortran
##   compiler (gfortran for 4.x, g77 for 3.x) first.  This should handle
##   problems if GCC 4.x and 3.x suites are installed and, depending on
##   the gcc default, the "wrong" GCC Fortran compiler is picked up (as

We used to pick a F77 compiler first, but note that all legal F77 code is 
legal F95 code so there was no actual advantage is doing so.  The issue 
here is that your code is not legal F77, and g77 (which implements 'GNU 
Fortran') is letting it through.

            

      
      
      
    

        
You cannot override either F77 or the default .f.o rule, as etc/Makeconf 
wins.  However, you set up a specific rule in Makevars, and also need an 
all: target.  See fastICA/src/Makevars for the sort of thing.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Wed, 7 Jun 2006, Dirk Eddelbuettel wrote:

        

            

      
      
      
    

        
~/.R/Makevars, but that applies to all packages on all builds.

            

      
      
      
    

        
Yes, but it only works in some Makes, including GNU Make.

            

      
      
      
    

        
It might make sense to separate CFLAGS, FFLAGS, CXXFLAGS, FCFLAGS out of 
etc/Makeconf into a Makefile included before Makevars.  But I am very 
reluctant to make it easy to change the F77 compiler or FLIBS or 
FPICFLAGS.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Ben Bolker
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

        

            

      
      
      
    

        
Not that it matters:

from  http://gcc.gnu.org/ml/fortran/2004-05/msg00308.html :

    /* We have overlapping initializers.  It could either be
+		       partially initilalized arrays (lagal), or the user
+		       specified multiple initial values (illegal).
+		       We don't implement this yet, so bail out.  */
+                  gfc_todo_error ("Initialization of overlapping
variables");

  so it's not clear to me whether my code is actually illegal,
or an odd case that gfortran doesn't handle ("yet") ...
the specific code that fails (as far as I can tell) is

      INTEGER SMALL(2)
      INTEGER LARGE(2)
      INTEGER RIGHT(2)
      INTEGER DIVER(2)
      INTEGER LOG10(2)
C
      REAL RMACH(5)
      SAVE RMACH
C
      EQUIVALENCE (RMACH(1),SMALL(1))
      EQUIVALENCE (RMACH(2),LARGE(1))
      EQUIVALENCE (RMACH(3),RIGHT(1))
      EQUIVALENCE (RMACH(4),DIVER(1))
      EQUIVALENCE (RMACH(5),LOG10(1))

http://www.fortran.com/F77_std/rjcnf-8.html#sh-8.2
  suggests this should be legal as long as REALs are twice as long
as INTEGERs?

  I'm on the edge of my knowledge here -- don't know if there's a better
idiom ...

   cheers
     Ben

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 7 June 2006 at 17:29, Prof Brian Ripley wrote:

        
| > That came up recently:
| >
| > a)  ~/.Makevars  (as I recall)
| 
| ~/.R/Makevars, but that applies to all packages on all builds.

Yes indeed. Thanks for catching and correcting this.
 
| > b)  on a per invocation basis:
| > 	MAKEFLAGS="FFLAGS=-O1" R CMD INSTALL ...
| >    is something that worked for me.
| 
| Yes, but it only works in some Makes, including GNU Make.
| 
| > That said, I personally still dislike that I cannot 'undo' the settings the
| > R's global Makeconf.  I'd love to turn debugging, optimisation, ... on/off on
| > demand.
| 
| It might make sense to separate CFLAGS, FFLAGS, CXXFLAGS, FCFLAGS out of 
| etc/Makeconf into a Makefile included before Makevars.  But I am very 
| reluctant to make it easy to change the F77 compiler or FLIBS or 
| FPICFLAGS.

Well, as that would cover my past needs (where on certain architectures we
had switch from -O2 to a lower optimisation setting or g77 would die;
obviously a g77 bug and now mostly (?) fixed) so I'd say yes.

Not hugely pressing as the current system has worked, but I would at certain
points in the past have like to have this available.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Kasper Daniel Hansen
    

    

      
      #
    

  


  

      
On Jun 7, 2006, at 10:22 AM, Dirk Eddelbuettel wrote:

        

            

      
      
      
    

        
I would really like the ability to override the optimization flags on  
a per package basis. I have a use case where I am using an SDK  
outside of my control which does not work with -O2 on (some versions  
of) GCC. From Dirk's description it seems I am not alone in having  
this problem. From my point of view it is unreasonable to make a user  
build R with specific optimization flags just because of a single  
package (especially if one wants to distribute the package to many  
users). I guess what I am trying to articulate is that I see this as  
a potential useful ability to have.

Right now I am using a hack by Simon Urbanek posted to R-devel some  
time ago which basically reverses the order of PKG_CXXFLAGS and  
CXXFLAGS, allowing me to override the R supplied ones. I know this is  
not portable since -O* is not a common to all compilers.

I am thinking of something like PKG_CXXSAFEFLAGS which - if set -  
will override the CXXFLAGS set by etc/Makeconf. Then I should be able  
to do something like (pseudo code)
   if using(gcc)
     set PKG_CXXSAFEFLAGS=....
I am not sure whether this is feasible, because I am only really  
interested in overriding the optimization flags and not all the other  
CXXFLAGS.

Unfortunately, my knowledge of Makefiles and configure scripts do not  
make it possible to come up with a specific suggestion - only a use  
case and a wish :)

/Kasper