I recently followed the instruction on this thread for compiling BLAS and LAPACK as pre-requisites to a SciPy installation. First I got a gfortran error at some point, which recommended that I re-compile LAPACK with -fPIC. So I did this by replacing the -frecursive with -fPIC in makefile.inc (which, I assume is some file the Makefile reads for different compile options) and the error was gone.
Can someone explain more generally what the difference is in compiling something with -fPIC and -frecursive, and how it helped fix the error in my case.
Thanks!
As Soren already commented: -fPIC is totally unrelated to -frecursive. PIC influences how machine code can be positioned inside memory. If you want to compile a library code must be compiled to be relocatable. In other words the code must be able to run regardless of where it is loaded in memory. This question deals with this in more detail.
The -frecursive indeed should be specified if possible. Older implementations of gfortran, e.g. gfortran 4.1.2 on RedHat 5 do not support this option. Currently I haven't seen a workaround, so you have to remove it.
The gfortran documentation describes it as
Allow indirect recursion by forcing all local arrays to be allocated on the stack
In the thread you mentioned, for compilation of the LAPACK library the option -frecursive can be removed. Then the library compiles.
If it works without this feature remains to be seen. Haven't tested yet.
Related
I am currently trying to compile the netCDF-DataReader in JModelica but it appears the package has been developed in Dymola. The process fails at the compilation stage:
netCD = compile_fmu('NcDataReader2.Examples.Simple',r'H:\Modelica\Modelica Libraries\NcDataReader2',compiler_log_level= 'w,i:log.txt')
CcodeCompilationError: Compilation of generated C code failed.
The log file created contains 326 lines. Midway it says
====== Model compiled successfully =======
But there are many errors after. Some of the errors include:
Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" '
unrecognized collect2.exe: error: ld returned 1 exit status
mingw32-make1: *** [ceval_] Error 1 Cannot export
??_C#_01LFCBOECM#?4?$AA#: symbol not found Cannot export
??_C#_01NOFIACDB#w?$AA#: symbol not found
C:\JModelica.org-2.1\install\Makefiles\MakeFile:190: recipe for target
'fmume10' failed
I don't have much experience with compilers and debugging C-code and would prefer to spend my time focused on creating models; therefore this leads to a number of questions:
Are there patterns in this errror log that could be addressed in such a way to make Dymola libraries useable in other Modelica based programs, such as JModelica?
Are then any other compilers that may be more suited to cross-compatible models?
Am I wasting my time trying to make Dymola models run in JModelica? Would it be more sensible to recreate the model separately in JModelica? The lack of a front-end interface makes this tricky.
The problem is that the external libraries available in netCDF-DataReader needs to be compiled using the GCC compiler available in the JModelica distribution. Try to recompile the libraries using GCC and put the libraries in NcDataReader2\Resources\Library\win32 (or even better put them in NcDataReader2\Resources\Library\win32\gcc472)
does anyone know if there is a way to print the compiler (and its version) that is used when I use the Fortran magic and Cython magic in IPython
For example, like the compiler that was used to build Python: platform.python_compiler()
There are probably better ways to do this, but here are two quick ones.
For Cython, the first thing that came to mind was to make a Cython file that passes the Cython compiler and causes an error at the C level.
Here's a simple one.
cdef extern from "nosuchheader.h":
void myfakefunction(int a, double b)
On my computer IPython shows an error from distutils saying that "gcc failed with exit status 1".
I don't currently use the %%fortran magic, but you should be able to see what f2py is doing based on its output.
f2py usually shows which compiler it is using, both when it searches for a compiler, and when it actually calls the Fortran compiler.
To figure that out, I'd recommend compiling some snippet of Fortran code via f2py and looking at the output.
On my windows machine it shows the output as f2py searches for a Fortran compiler, and prints the lines
'Found executable C:\\mingw64\\bin\\gfortran.exe',
'Found executable C:\\mingw64\\bin\\gfortran.exe',
This tells me it is using gfortran.
Further down in the output it also shows the commands used to build the Fortran source code.
The documentation for the fortran magic mentions how to get verbose output.
If you pass the flag -vvv to the fortran magic, it will print the output from f2py.
You could also try looking at the %fortran_config magic mentioned in the documentation.
I have created a mex function (more specifically, using CUDA)
the compilation was successful, and I got a mex file zMul.mexmaci64
but on the execution, matlab reported an error:
Invalid MEX-file '/Users/zlw/Documents/MATLAB/lowComplexity/cbased/matMulGPU/zMul.mexmaci64':
dlopen(/Users/zlw/Documents/MATLAB/lowComplexity/cbased/matMulGPU/zMul.mexmaci64, 1):
Library not loaded: #rpath/libcublas.6.0.dylib
Referenced from: /Users/zlw/Documents/MATLAB/lowComplexity/cbased/matMulGPU/zMul.mexmaci64
Reason: image not found
What should I do do solve it?
additional info
setting the environment vars (PATH,LD_LIBRARY_PATH,DYLD_LIBRARY_PATH) in Matlab and in .bash_profile doesn't work for me
I'm pretty sure that the environment vars are set correctly because when I created an alias to the dylib file, Matlab detected it, tried to load it, but failed with message:no suitable image found
Thanks!
Use otool -L in both Matlab and UNIX console.
In Matlab:
!otool -L /path/to/zMul.mexmaci64
In UNIX console:
otool -L /path/to/zMul.mexmaci64
Try to find the difference between them. If there is a difference in dependency, that is probably breaking the MEX binary. You might need to apply the same technique for the dependent dylib objects recursively. Typically, enforcing the one appearing in UNIX console using DYLD_INSERT_LIBRARIES solves the problem.
Another possibility is the C++ runtime compatibility. If you're using OS X Mavericks, you should check that your MEX command is using libc++ but not libstdc++ in mexopts.sh. Below is my configuration example in mexopts.sh:
CC='clang'
CXX='clang++'
SDKROOT='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/'
MACOSX_DEPLOYMENT_TARGET='10.9'
CFLAGS="$CFLAGS -Dchar16_t=uint16_t"
CXXFLAGS="$CXXFLAGS -std=c++11 -stdlib=libc++ -DCHAR16_T"
CXXLIBS="$MLIBS -lc++"
This post might help: http://www.seaandsailor.com/matlab-xcode6.html
It was easier than I thought. Just replace all 10.x with your OS X version and add -Dchar16_t=UINT16_T to CLIBS in mexopts.sh file.
I have inherited code, trying to compile with gcc on Linux.
what library am I looking for that has __builtin_ia32_stmxcsr ?
apologies -- i was too fast to submit; running gcc inside of Nvidia Eclipse. actual error message is "Functuion . . . could not be resolved" so i jumped the conclusion i needed to reference some lib. As the offending lines hav a :#if defined(SSE) I take it to mean that the -msse2 switch is present although i cannot seem to find a copyh of the compile command line. [just learning this Eclipse tool -- very new!]
You don't need to link with anything - the "builtin" in the name is a clue that it's a gcc built-in (intrinsic) compiler function.
However you do need to be compiling for an x86 target with SSE enabled for this to be recognised, e.g. gcc -msse2 ....
Note that you can use the _mm_getcsr intrinsic from <xmmintrin.h> instead of __builtin_ia32_stmxcsr - this would be a little more portable.
This is a bug in eclipses indexer with gcc's __builtin* functions. The bug report is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=352537
The problem is that even the glibc/gcc libraries themselves use these __builtin* functions, so eclipse complains about a faulty xmmintrin.h etc., which is of course nonsense.
There is a workaround given in the bug report, you can add the function prototypes as user defined macros for the indexer, but of course this becomes tedious if there are a few more and some type checking abilities are lost.
Update
Thank you Vladimir for the usefull insights in libraries. I took another approach, developping first in ubuntu (which was a lot easier then messing around with Eclipse/Cygwin/... and now I'm trying to port to windows, which goes rather ok, however I have some questions about that too, posted here: Problems with porting a fortran program from ubuntu to windows
Question
I currently have the following setup and can't get the lapack library configured so that my fortran code can compile:
Windows 7
Cygwin installation (for GNU fortran), added to the windows PATH
lapack and liblapack-devel installed with cygwin
resulting in liblapack.a and libblas.a in the folder C:/cygwin/lib
In my program I call the lapack library using the following code
program myProgram
!use lapack (stays commented now)
...
In Eclipse I used the following setup (with the Photran package):
Fortran Project: executable GNU fortran on Windows (GCC toolchain)
GNU fortran compiler: gfortran ${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
GNU fortran linker: gfortran ${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
I compiled the libraries libblas.a and liblapack.a, to use as a static library, for windows and they are located in the C:/cygwin/lib folder. In the GNU fortran linker properties, the libraries were called lapackand blasin the folder C:/cygwin/lib. This results in a part -L"C:/cygwin/lib" -llapack -lblas in the {$COMMAND} section of the compiler and linker. (thanx to #vladimir-f for the help)
In the output there are no error messages left anymore. Only I got now the following error in Eclipse and no final .exe or bins:
Errors occured during the build.
Errors running builder 'CDT Builder' on project 'Hamfem'
Internal error building project Hamfem configuration
Release
java.lang.NullPointerException
Internal error building project Hamfem configuration
Release
java.lang.NullPointerException
However, the result of the build is still an executable, in this case called Hamfem.exe. Running this file results in the error message (instead of the routine): The program can't start because cyglapack-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
That file is currently located in C:/cygwin/lib/lapack/ but I want that this file isn't needed to run the program, so I can run it on different computers. Can someone collaborate on this?
Second, when copy-pasting the .dll file in the folder where the .exe is located, it runs for a brief second, generating a stackdump file. I can't use the debugger in Eclipse-Photran due to the 'Building Workspace' error. Eclipse gives the message Binary not found when I want to run it in Eclipse as a local Fortran program. Any ideas how to resolve this problem?
The problem is here
L/lib/lapack –llapack
try to change it for
-L/lib/lapack –llapack
probably it is in you Makefile.
i.e.
gfortran -funderscoring -O3 -Wall -c -fmessage-length=0 -L/lib/lapack -llapack -o
And make sure lapack.mod is really in /lib/lapack which is probably C:\cygwin\lib\lapack on Cygwin.