f90wrap on Windows (Python wrapper for Fortran 90) - python-2.7

I've got a Python program that calls Fortran routines. These Fortran routines are wrapped with f90wrap (https://github.com/jameskermode/f90wrap), and I've verified that the setup works correctly on Linux and Mac OSX. I'm now trying to get the setup to work equally well on Windows (because I collaborate with people who cannot sometimes switch to Linux).
I've got gfortran working through a MinGW installation and verified that Fortran programs compile and run without errors. I've also verified that a Python 2.7 installation works without issues, and was able to use pip to add numpy, matplotlib and scipy modules without issues. Both MinGW and Python are 64-bit, running on Windows 10. I've also got CMake to create Makefiles that compile standalone fortran programs using mingw-make, so the only part left (to get things working on Windows) is to make sure the Python wrapper for Fortran-90 works. That's where I ran into some issues.
I'm running mingw-make in Powershell (which executes in cmd.exe, I believe).
Q1: The pip installation for f90wrap failed with an absolute path/relative path error (https://github.com/jameskermode/f90wrap/issues/73)
A1: I downloaded the source and ran "python setup.py install", and that got stuck as well. I ran into a "multiple_definition" error with Windows 10, Python 2.7 and mingw-w64.
F:/Programs/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-atonexit.o):atonexit.c:(.text+0xc0): multiple definition of atexit' F:\Programs\Python\libs/libmsvcr90.a(deoks01081.o):(.text+0x0): first defined here F:/Programs/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x0): multiple definition of_decode_pointer'
F:\Programs\Python\libs/libmsvcr90.a(deoks00231.o):(.text+0x0): first defined here
F:/Programs/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x10): multiple definition of `_encode_pointer'
F:\Programs\Python\libs/libmsvcr90.a(deoks00241.o):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
error: Command "gcc -g -shared build\temp.win-amd64-2.7\Release\f90wrap\arraydatamodule.o build\temp.win-amd64-2.7\Release\programs\python\lib\site-packages\numpy\f2py\src\fortranobject.o -LF:\Programs\Python\libs -LF:\Programs\Python\PCbuild\amd64 -lpython27 -lmsvcr90 -o build\lib.win-amd64-2.7\f90wrap\arraydata.pyd" failed with exit status 1

Related

After installing a Library through conda, compiling a C++ script, won't see its headers files

I have already compiled a Script on my Desktop Computer, but now I have to compile it on a Server where I don't have root access.
So I chose to install Anaconda and work with Conda environments.
So, I'm installing a GCC 9.3 Compiler, among with a GXX 9.3 Compiler because I need the execution policies from C17++.
I also installed GSL library through conda install gsl and indeed, on conda list it appears to be:
gsl 2.4 h14c3975_4
so, I decided to compile the script via : x86_64-conda_cos6-linux-gnu-cpp SCRIPT_NAME -o _OUTNAME_ -lgsl since this is the way Anaconda says to call it's compilers (said so on build log)
but I get this error:
mpi_final.cpp:1:10: fatal error: gsl/gsl_math.h: No such file or directory
1 | #include <gsl/gsl_math.h>
| ^~~~~~~~~~~~~~~~
compilation terminated
I have managed to include GSL but ONLY when I install it manually. and then I have problem with other libraries, so I decided to fix anaconda environments. But I dont know how to proceed.
Any Idea on where to look?

Is environment configured incorrectly inside VSCode C++ debug session on OSX?

I have a programming language I'm fiddling with and it calls clang to link the bitcode file it emits. (Perhaps there is a better way to do this all together?) I've been using Visual Studio Code to debug it and it has mostly worked great.
I recently upgraded llvm. At that point, builtin osx clang was complaining about not recognizing a bitcode construct. So I installed clang part of llvm with brew. This looks to work for the compiler but fails to call the linker.
When I run a debug session I get this in the debug window:
clang-6.0: error: unable to execute command: Executable \"ld\" doesn't exist!
However, if I run from the embedded terminal it works fine.
It seems like clang is trying to explicitly expand the location of ld rather than using builtin path resolution. Something in VSCode's C++ debugger launched environment is causing issues with it.
Some supporting bits of diagnosis (trying to keep this a bit short for now...).
When run from the debugger:
whereis ld works and emits...
/usr/bin/ld
env emits what looks like a wrapped environment...
PWD=/Users/<snipped>
SHLVL=1
_=/usr/bin/env
echo $PATH emits...
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
And clang tries to link it runs "ld" and says...
clang-6.0: error: unable to execute command: Executable "ld" doesn't exist!
When run from the embedded terminal on the other hand:
whereis ld works and emits...
/usr/bin/ld
env emits...
a metric ton of stuff including
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
echo $PATH emits...
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
And clang tries to run "/usr/bin/ld" which works fine.
I realize this may be a clang ld lookup bug (not correctly expanding _=/usr/bin/env??). Unfortunately A) I don't know very much about OSX environment expansion B) if VSCode C++ debugger is using some sort of standard OSX environment jujitsu or not C) not sure how to debug clang run from within an existing VSCode debugger session D) don't know how to emulate the VSCode debugger environment setup to get started unravelling the ball of yarn.
I think I've upgraded OSX/XCode that I'm now unblocked (using the builtin clang compiler from within the VSCode debugger works again). I figured I'd raise this anyway in case I can get a problem fixed or at least learn something.
Any thoughts/suggestions?
Thanks,
Adrian

Wrong python interpreter being used when debugging embedded target

I'm running CLion (2017.3 RC) with MinGW-w64 (5.0.3) and using gcc/g++ (7.2.0) + CMake (3.9.3) on Windows 10 x64 to compile a target that embeds python (3.6.3 64 bit). Everything works fine when run, however when I try to debug it and step through with CLion, I get
File "C:\Python36\Lib/site.py", line 178
file=sys.stderr)
^
SyntaxError: invalid syntax
I have my PYTHONPATH pointing towards a Python 3 installation. I do not have Python 2 installed on my system yet it seems like a Python 2 interpreter is trying to use the Python 3 Lib. After some digging I noticed that MinGW-w64 has Python 2 bundled with it but even if I delete the libs, include, and exe, I get the same error.
After some more digging I learned that python2 has been embedded in gdb from version 7.0+. Because of this, if you try to run MinGW64's gdb (like trying to debug from CLion) and you have PYTHONPATH pointing towards a python3 installation, you'll run into a syntax error. This happens because the embedded python2 is trying to use the python3 libs.
I am still unable to debug my C++ target that embeds python but that's a different issue...

Tensorflow r1.2 c++ api error when using libtensorflow.so

I have a code that was working perfectly fine with r1.1.
I am trying to run the code in different computer. So installed Tensorflow r1.2 from sources. I first build libtensorflow.so, and link it to my executable. Now I am getting thousand errors like:
undefined reference to 'tensorflow::internal::LogMessageFatal::
It seems like libtensorflow.so is built at all. I used the command
sudo bazel build -c opt --config=cuda --copt="-mtune=native" --copt="-O3" tensorflow:libtensorflow.so --genrule_strategy=standalone --spawn_strategy=standalone
to build libtensorflow.so. I also tried r1.1 with the same computer and it works fine. What was changed in r1.2?

Running into an error when trying to implement Keras

I'm using Python 2.7, Windows 7, and Keras 1.2.1 (Keras2 seems to be having a lot of compatibility issues with different PC/Python configs, so I was recommened to use 1.2.1)
I'm using a script from Practical Deep Learning For Coders, Part 1 Course
import utils; reload(utils)
from utils import plots
The error I"m getting is as below
Problem occurred during compilation with the command line below:
"g++" -shared -g -DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION -m64 -DMS_WIN64 -I"c:\python27\lib\site-packages\numpy\core\include" -I"c:\python27\include" -I"c:\python27\lib\site-packages\theano\gof" -L"c:\python27\libs" -L"c:\python27" -o C:\Users\Moondra\AppData\Local\Theano\compiledir_Windows-7-6.1.7601-SP1-Intel64_Family_6_Model_94_Stepping_3_GenuineIntel-2.7.12-64\lazylinker_ext\lazylinker_ext.pyd C:\Users\Moondra\AppData\Local\Theano\compiledir_Windows-7-6.1.7601-SP1-Intel64_Family_6_Model_94_Stepping_3_GenuineIntel-2.7.12-64\lazylinker_ext\mod.cpp -lpython27
I can't decipher what this means. Google search brought up a Chinese message board.
It seems to be a g++ problem as the previous warning I got was as follows:
WARNING (theano.configdefaults): g++ not available, if using conda:conda install m2w64-toolchain``. Despite installing m2w64-toolchain afterwards, I was continuing to get the same warning.
Some interesting things I learned while trying to configure theano and keras:
C++/g++
Depending on your python version, you have to install a corresponding version of the C++ compiler, or Visual Studio. Ex: Python 2.7 needs C++ 9.0 (Visual Studio 2008). But Python 3.5 needs C++ 14.0 (Visual Studio 2015) -- See here for more: https://wiki.python.org/moin/WindowsCompilers
I also had to install MinGW for g++ compilers: https://nuwen.net/mingw.html
Even with it correctly installed, you may see an error about hypot. This question shows two possible solutions: g++ error on import of Theano on Windows 7
I tried installing everything via Conda, but all calculations were slower than continents moving away from each other. Then I gave up conda and installed everything via standard python. (First python, then numpy, then scipy, then theano, then keras). Not sure if MinGW goes before of after numpy/scipy, but I think it goes before.
BLAS/LAPACK
Numpy and theano may warn you that no lapack/blas is installed. For that, I used the numpy and scipy libraries available here, they're great and fast: http://www.lfd.uci.edu/~gohlke/pythonlibs/
Another option is installing MKL directly from Intel, before installing numpy and scipy.
Path problems / Invalid Token - ldflags
Avoid installing anything, including the MKL, in folders containing spaces in their names! That will definitely confuse theano/numpy.
You may get "invalid token" errors if you have spaces in folders, and a ldflags var described in that error. To solve that, either reinstall your mkl libraries in folders without spaces, or configure the .theanorc file in the theano home folder with your [blas] configuration and the ldflags var. (See here: Receive AssertionError while optimizing convolution in theano)
Since I wasn't willing to reinstall MKL in another folder, I learned to create symbolic links to windows. (in the answer above)
Replace the folders with space in the theano config and also in the numpy config files (__config__.py), you can see its content with np.__config__.show(). (See answer above)
I solved the problem.
I reinstalled Anaconda.
And then via command line I wrote conda install m2w64-toolchain
This time I didn't get a message stating that m2w64 was already installed. I'm assuming it was a path issue and this time reinstalling everything from the start also created a new path?