Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#13157 closed defect (fixed)

inline_fortran is STILL broken on OS X

Reported by: benjaminfjones Owned by: was
Priority: major Milestone: sage-5.4
Component: interfaces Keywords: fortran osx
Cc: kcrisman, mvngu, flawrence Merged in: sage-5.4.beta0
Authors: Jeroen Demeyer Reviewers: Karl-Dieter Crisman, Benjamin Jones
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by chapoton)

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.

Attachments (2)

13157_scripts.patch (736 bytes) - added by jdemeyer 7 years ago.
13157_inline_fortran.patch (3.5 KB) - added by jdemeyer 7 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 7 years ago by kcrisman

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.

comment:2 Changed 7 years ago by kcrisman

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.

comment:3 Changed 7 years ago by jdemeyer

  • Description modified (diff)
  • Summary changed from %fortran in the notebook (and fortran.eval on command line) is STILL broken on OS X to inline_fortran is STILL broken on OS X

Changed 7 years ago by jdemeyer

comment:4 Changed 7 years ago by jdemeyer

  • Authors set to Jeroen Demeyer
  • Description modified (diff)
  • Status changed from new to needs_review

Changed 7 years ago by jdemeyer

comment:5 Changed 7 years ago by jdemeyer

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

comment:6 Changed 7 years ago by jdemeyer

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

comment:7 Changed 7 years ago by jdemeyer

Any reviewers?

comment:8 follow-up: Changed 7 years ago by kcrisman

  • Reviewers set to 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...

comment:9 in reply to: ↑ 8 Changed 7 years ago by jdemeyer

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.

comment:10 Changed 7 years ago by benjaminfjones

  • Reviewers changed from Karl-Dieter Crisman to Karl-Dieter Crisman, Benjamin Jones
  • Status changed from needs_review to positive_review

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

comment:11 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.3 to sage-5.4

comment:12 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.4.beta0
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:13 Changed 4 years ago by chapoton

  • Description modified (diff)
Note: See TracTickets for help on using tickets.