py-scikits-bvp_solver: New port

[mf2k (Frank Schima)]

I am working on a new port and having problems building it. It is a python module which requires Fortran.

Here is the build error I am seeing when attempting to build with the +gcc47 variant:

/opt/local/bin/gfortran-mp-4.7 -Wall build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverfmodule.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/fortranobject.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_M.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_INTERFACE.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/lampak.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_LA.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverf-f2pywrappers2.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin12/4.7.2 -lgfortran -o build/lib.macosx-10.8-x86_64-2.7/scikits/bvp_solver/bvp_solverf.so
Undefined symbols for architecture x86_64:
  "_PyArg_ParseTupleAndKeywords", referenced from:
      _f2py_rout_bvp_solverf_bvp_guess_1_wrap in bvp_solverfmodule.o
      _f2py_rout_bvp_solverf_bvp_guess_2_wrap in bvp_solverfmodule.o
      _f2py_rout_bvp_solverf_bvp_bvp_eval_wrap in bvp_solverfmodule.o
      _f2py_rout_bvp_solverf_bvp_bvp_solver_wrap in bvp_solverfmodule.o
      _f2py_rout_bvp_solverf_bvp_bvp_extend_wrap in bvp_solverfmodule.o
  "_PyCObject_AsVoidPtr", referenced from:
      _initbvp_solverf in bvp_solverfmodule.o
      _F2PyCapsule_AsVoidPtr in fortranobject.o
  "_PyCObject_FromVoidPtr", referenced from:
      _fortran_getattr in fortranobject.o
      _F2PyCapsule_FromVoidPtr in fortranobject.o
  "_PyCObject_Type", referenced from:
      _initbvp_solverf in bvp_solverfmodule.o
      _F2PyCapsule_Check in fortranobject.o
  "_PyComplex_Type", referenced from:
      _int_from_pyobj.part.1 in bvp_solverfmodule.o
      _double_from_pyobj.part.0 in bvp_solverfmodule.o
  "_PyDict_DelItemString", referenced from:
      _fortran_setattr in fortranobject.o
  "_PyDict_GetItemString", referenced from:
      _fortran_getattr in fortranobject.o
  "_PyDict_New", referenced from:
      _PyFortranObject_New in fortranobject.o
      _PyFortranObject_NewAsAttr in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyDict_SetItemString", referenced from:
      _initbvp_solverf in bvp_solverfmodule.o
      _fortran_getattr in fortranobject.o
      _F2PyDict_SetItemString in fortranobject.o
      _PyFortranObject_New in fortranobject.o
      _fortran_setattr in fortranobject.o
  "_PyErr_Clear", referenced from:
      _cb_fsub_in_bvp_solver_wrap__user__routines in bvp_solverfmodule.o
      _cb_dbcdyp_in_bvp_solver_wrap__user__routines in bvp_solverfmodule.o
      _cb_bcsubp_in_bvp_solver_wrap__user__routines in bvp_solverfmodule.o
      _cb_bcsub_in_bvp_solver_wrap__user__routines in bvp_solverfmodule.o
      _cb_dbcdy_in_bvp_solver_wrap__user__routines in bvp_solverfmodule.o
      _cb_fsubp_in_bvp_solver_wrap__user__routines in bvp_solverfmodule.o
      _cb_dfdy_in_bvp_solver_wrap__user__routines in bvp_solverfmodule.o
      ...

[Veence (Vincent)]

You need to pull the Python library in, either through an additional -l flag or better a -F flag.

[Veence (Vincent)]

’Twas a bit more tricky. I upload a TGZ file with a modified Portfile and a patch. It seems to work on my machine (at least the import directive work, I did not test the algorithm itself)

[Veence (Vincent)]

Portfile + patch

[mf2k (Frank Schima)]

Thanks Vince. But this still fails for me. I am running with +gcc47 in my default variants. Which gcc are you using?

sudo port -d install subport=py27-scikits-bvp_solver
...
/opt/local/bin/gfortran-mp-4.7 -Wall build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverfmodule.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/fortranobject.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_M.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_INTERFACE.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/lampak.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_LA.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverf-f2pywrappers2.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin12/4.7.2 -lgfortran -o build/lib.macosx-10.8-x86_64-2.7/scikits/bvp_solver/bvp_solverf.so -L/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib -lpython2.7 -Wl,-dylib
Undefined symbols for architecture x86_64:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
Undefined symbols for architecture x86_64:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64

[Veence (Vincent)]

Strange. It links fine with me:

/opt/local/bin/gfortran-mp-4.7 -Wall build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverfmodule.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/fortranobject.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_M.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_INTERFACE.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/lampak.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_LA.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverf-f2pywrappers2.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin12/4.7.2 -lgfortran -o build/lib.macosx-10.8-x86_64-2.7/scikits/bvp_solver/bvp_solverf.so -L/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib -lpython2.7 -Wl,-dylib
running scons

[mf2k (Frank Schima)]

Where does "running scons" in your output come from? I do have scons installed :

$ port installed scons
The following ports are currently installed:
  scons @2.2.0_0 (active)

[mf2k (Frank Schima)]

So it seems to build fine if the scons port is *not* installed. That seems counter-intuitive to me. Any ideas on how to get it to build if scons is installed?

[Veence (Vincent)]

I’ll check that later today, at work (where I have four different MacMinis)

[mf2k (Frank Schima)]

I uninstalled scons and it still fails for me with that last error. At least on my main Mac. On at least another computer, it builds fine. The main difference between my failing one and success is the "running scons" line appears when it is successful.

[ryandesign (Ryan Carsten Schmidt)]

• The Portfile has a mixture of tabs and spaces; should be all spaces.
• The +universal variant fails to build with "cc1: error: unrecognized command line option "-arch""
• You don't need to set configure.fc, configure.f77 or configure.f90; MacPorts does that for you when you set configure.compiler.
• The build fails for me on Mountain Lion, whether or not scons @2.2.0_0 is active:

  :info:build Undefined symbols for architecture x86_64:
  :info:build   "_main", referenced from:
  :info:build       start in crt1.10.5.o
  

[mf2k (Frank Schima)]

@ryandesign: Thanks for your input. Somehow Vince is able to build it and we are working on trying to replicate that. I'll clean up and post an updated portfile soon.

[Veence (Vincent)]

@ryan: could you please be more specific as to when exactly during the build you get the error? Is it exactly at the same place than Frank? Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Replying to vince@…:

@ryan: could you please be more specific as to when exactly during the build you get the error? Is it exactly at the same place than Frank?

I've attached my log file.

[mf2k (Frank Schima)]

Yes, that's the same error that I get.

[Veence (Vincent)]

What ld are you using?

-> which ld
/opt/local/bin/ld
-> ld -v
@(#)PROGRAM:ld  PROJECT:ld64-134.9
configured to support archs: i386 x86_64
LTO support using: LLVM version 3.2svn

[ryandesign (Ryan Carsten Schmidt)]

$ which ld
/opt/local/bin/ld
$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-134.9
configured to support archs: i386 x86_64
LTO support using: LLVM version 3.1

[Veence (Vincent)]

Drat. It looks like for both of you the -Wl,-dylib flag is not correctly handed over to the linker, and therefore it expects finding a starting point in the code. Try replacing -Wl,-dylib in the patch file by -Xlinker -dylib and build again?

[mf2k (Frank Schima)]

FYI, here is my output for ld:

$ which ld
/opt/local/bin/ld
$ ld -v
@(#)PROGRAM:ld  PROJECT:ld64-134.9
configured to support archs: i386 x86_64
LTO support using: LLVM version 3.1

@vince: I tried the change and I get a different error. But maybe I did not correctly follow your instructions. I'm attaching the new log and my Portfile.

:info:build /opt/local/bin/gfortran-mp-4.7 -Wall build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverfmodule.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/fortranobject.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_M.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_INTERFACE.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/lampak.o build/temp.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/BVP_LA.o build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverf-f2pywrappers2.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin12/4.7.2 -lgfortran -o build/lib.macosx-10.8-x86_64-2.7/scikits/bvp_solver/bvp_solverf.so XXX
:info:build gfortran-mp-4.7: error: XXX: No such file or directory

[Veence (Vincent)]

Sorry Franck, the substitution should be in the Portfile line 74. Try this line:

reinplace -E "s|XXX|-L${pyfwk}${pyver}/lib -lpython${pyver} -Xlinker -dylib|" \

[mf2k (Frank Schima)]

That's what I had tried and it didn't work for me. It's the same Portfile and log that I attached above. Can you attach your working Portfile?

[mf2k (Frank Schima)]

OK, I fixed the patching to work but I still get the same original error.

build/temp.macosx-10.8-x86_64-2.7/build/src.macosx-10.8-x86_64-2.7/scikits/bvp_solver/lib/bvp_solverf-f2pywrappers2.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin12/4.7.2 -lgfortran -o build/lib.macosx-10.8-x86_64-2.7/scikits/bvp_solver/bvp_solverf.so -L/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib -lpython2.7 -Xlinker -dylib
:info:build Undefined symbols for architecture x86_64:
:info:build   "_main", referenced from:
:info:build       start in crt1.10.6.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: error: ld returned 1 exit status
:info:build Undefined symbols for architecture x86_64:
:info:build   "_main", referenced from:
:info:build       start in crt1.10.6.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: error: ld returned 1 exit status

[mf2k (Frank Schima)]

This was done in r105716.