inline_fortran is STILL broken on OS X

[Benjamin Jones]

Despite #7465 being closed as "worksforme", the following snippet in the notebook in Sage-5.2 on Mac OS X 10.7.4 fails.

%fortran
C FILE: FIB1.F
      SUBROUTINE FIB(A,N)
C
C     CALCULATE FIRST N FIBONACCI NUMBERS
C
      INTEGER N
      REAL*8 A(N)
      DO I=1,N
         IF (I.EQ.1) THEN
            A(I) = 0.0D0
         ELSEIF (I.EQ.2) THEN
            A(I) = 1.0D0
         ELSE 
            A(I) = A(I-1) + A(I-2)
         ENDIF
      ENDDO
      END
C END FILE FIB1.F

Here is the error in full: ​http://pastebin.com/iVBkjckp

Apply:

1. 13157_inline_fortran.patch​ to the Sage library.
2. 13157_scripts.patch​ to $SAGE_ROOT/local/bin.

[Karl-Dieter Crisman]

Umm, there is something really odd here. The flags passed seem to indicate something went quite wrong. For instance, one bit is

/var/folders/f4/881mfg491yxdf3zx37ynf5580000gn/T/tmpSLdvBd/Users/bael/.sage/temp/Baels_MacBook_Air.local/2689/tmp_0.o -LUsing built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/Users/bael/sage/sage-5.0.1/local/bin/../libexec/gcc/x86_64-apple-darwin10.8.0/4.6.3/lto-wrapper /Users/bael/sage/sage-5.0.1/local/bin/../lib/gcc/x86_64-apple-darwin10.8.0/4.6.3 -l gfortran -o ./fortran_module_0.so -l gfortran -shared-libgcc

What the heck?

-LUsing built-in specs. COLLECT_GCC=gfortran 

No wonder the errors look like

gfortran: error: built-in: No such file or directory
gfortran: error: specs.: No such file or directory
gfortran: error: COLLECT_GCC=gfortran: No such file or directory

I don't know how that verbiage got passed there, though.

Anyway, since

/Users/bael/sage/sage-5.0.1/local/bin/../lib/gcc/x86_64-apple-darwin10.8.0/4.6.3" -lgfortran -o ./fortran_module_0.so" failed with exit status 1

that means it's no surprise that at the end

    os.unlink(name + '.so')
OSError: [Errno 2] No such file or directory: 'fortran_module_0.so'

though that is just a symptom.

Does ticket:8010:attachment:trac-8010_numpy.patch (sorry, can't get the link right) look like it might solve it for you, just on the off chance? One would have to make a new spkg, of course. But the patch was never applied, to my knowledge.

[Karl-Dieter Crisman]

Wait, there is no sage_fortran any more, so that doesn't make sense to apply anyway. And the ​current numpy code has

'linker_so'    : [None, "-g", "-Wall"],

so the shared business can't be the issue, or at least not in exactly the same way.

I can also confirm that this is not just a Lion issue; the same happens on 10.6.

[Jeroen Demeyer]

The file inline_fortan.py still lacks documentation, but I don't feel like fixing that now. Needs testing and review.

[Jeroen Demeyer]

Tested on Linux, OS X and OpenSolaris, works fine.

[Jeroen Demeyer]

Any reviewers?

[Karl-Dieter Crisman]

This works fine on OS X now. The code changes are minimal and make sense - nice error test. I only tested this on OS X 10.7, not previous systems; I guess someone should test this doesn't break anything on Linux, and take jdemeyer's word for it on OpenSolaris.

Any reason for the change of standard error to standard output instead of the previous vice versa? It does seem more natural given the names of the terms, but I'm not a bash expert...

[Jeroen Demeyer]

I tested this on many platforms and it works. Is that sufficient for positive review then?

Replying to kcrisman:

Any reason for the change of standard error to standard output instead of the previous vice versa? It does seem more natural given the names of the terms, but I'm not a bash expert...

The redirection

1>&2 >foo

is equivalent to

>foo

It's like saying: redirect stdout to stderr. Oh, never mind, redirect it to foo instead. This doesn't really make sense, so I assume it's a mistake.

While

>foo 2>&1

means: redirect stdout to foo. Now redirect stderr to the new stdout, which is foo. This therefore redirects both stdout and stderr to foo.

Off topic and just for educational value: the redirection

2>&1 >foo

would mean: redirect stderr to the current stdout. Now redirect stdout (but not stderr) to foo.

[Benjamin Jones]

I just tested on OS X 10.7, OS X 10.6, and Debian linux and it looks good to go.