I'm trying to use the Intel MKL library from a fresh install of Debian 11.
I'm looking to use the Debian installation of MKL instead of installing manually.
A simple program like
program main
use f95_precision
write(*,*) "hello world"
end program main
compiled with
mpifort -m64 -I/usr/include/mkl/intel64/lp64 -L/usr/lib/x86_64-linux-gnu/mkl -Wl,--no-as-needed -lmkl_gf_lp64 -lmkl_sequential -lmkl_core -lpthread -lm -ldl -o test test.F90
fails with error
f951: Fatal Error: Reading module ‘/usr/include/mkl/intel64/lp64/f95_precision.mod’ at line 1 column 2: Unexpected EOF
Typical error when the f95_precision.mod file has been generated with another compiler.
What is the right way to use the file f95_precision when using the Debian package installation of MKL?
Edit: I know I can download MKL from the Intel site, install it, compile the blas95 and lapack95 interfaces and then use the f95_precision.mod generated then. That works. The point of this post is to know how do I use the already existing f95_precision.mod, blas95.mod and lapack95.mod that a fresh Debian installation provides.
Related
Background
I have read countless GitHub project threads and everything I can find on StackOverflow about this problem, though so far no luck. I have a Mac 10.14 box running with the stock CommandLineTools and/or Xcode. I'm trying to "port" a Python wrapper library I have written around an older C and C++ library using CTypes in Python3. It works well already on Ubuntu Linux. However, there is no end to the problems I have been coming across since moving to a Mac platform. There just doesn't seem to be an easy answer to fixing what I'm trying to do on the broken Mac OS platform right now -- at least for the uninitiated Linux person like myself.
I have one question right off the bat before I describe how I'm compiling the dylib I'm trying to load up with CTypes: Do I now need to sign my dylib somehow before I can use it on Mac 10.14? Otherwise, I guess my question boils down to how the $%^# (and that is truncated speak for what I do mean right now) can I deal with shared / dynamic libraries on Mac with a Python C extension interface?
My preference is to not even touch Xcode and just use the stock Mac tools that come with the system out of the box. My solution must work on the command line without defering to some auto configuration magic that Xcode will give you in GUI form. Really, this is all fairly painless for what it is under Linux.
Compilation and linking
The scenario is actually more complicated than I can describe. I will just sketch what seems to me to be the relevant parts of the solution, and then let you all experts who have gotten this working before tell me the obvious missteps in between.
I'm compiling the older C/C++ source code library as a static archive first using the following
gcc (read clang) options on Mac (some of them get ignored):
-O0 -march=native -force_cpusubtype_ALL -fPIC -I../include -fPIC -m64 \
-fvisibility=default -Wno-error -lc++ -lc++abi
Then I'm compiling and linking with a combination of
-Wl,-all_load $(LIBGOMPSTATIC).a $(LIBGMPSTATIC) -Wl,-noall_load \
-ldl -lpthread -lc++ -lc++abi
and
-dynamiclib -install_name $(MODULENAME) \
-current_version 1.0.0 -compatibility_version 1.0
to generate the dylib output.
For comparison, on Linux, the analogs to these flags that work are approximately
-Wl,-export-dynamic -Wl,--no-undefined -shared -fPIC \
-fvisibility=default -Wl,-Bsymbolic
-Wl,-Bstatic -Wl,--whole-archive $(LIBGOMPSTATIC).a $(LIBGMPSTATIC) -Wl,--no-whole-archive \
-Wl,-Bdynamic -Wl,--no-as-needed -ldl -lpthread
and
-Wl,-soname,$(MODULENAME)
The dylib output
The above procedure gives me a dylib file that I can scan with nm to see the symbols I am trying to import with CTypes. This is a good start. When I try to run the test python script to test my CTypes wrapper library, I get a SEGFAULT immediately. Since gdb is apparently useless on Mac these days (sorry), I used the stock llvm to load up a brew-installed python3 with extra debugging symbols:
lldb /usr/local/Cellar/python-dbg\#3.7/3.7.6_13/bin/python3
(lldb) run myscript.py
Process 75435 launched: '/usr/local/Cellar/python-dbg#3.7/3.7.6_13/bin/python3' (x86_64)
Process 75435 stopped
* thread #2, stop reason = exec
frame #0: 0x0000000100005000 dyld`_dyld_start
dyld`_dyld_start:
-> 0x100005000 <+0>: popq %rdi
0x100005001 <+1>: pushq $0x0
0x100005003 <+3>: movq %rsp, %rbp
0x100005006 <+6>: andq $-0x10, %rsp
Target 0: (Python) stopped.
(lldb) bt
* thread #2, stop reason = exec
* frame #0: 0x0000000100005000 dyld`_dyld_start
(lldb) c
... redacted path information ...
File "/usr/local/Cellar/python-dbg#3.7/3.7.6_13/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
return self._dlltype(name)
File "/usr/local/Cellar/python-dbg#3.7/3.7.6_13/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py", line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(GTFoldPython.dylib, 6): image not found
Process 75435 exited with status = 1 (0x00000001)
I do have each of the environment variables PYTHONAPPSDIR=/usr/local/Cellar/python-dbg#3.7/3.7.6_13, PYTHONPATH, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH set to correct paths.
So the question is what do I try next to get this working? Many, many hours of thanks in advance!
In my case, the issue turned out to be two things.
The first is that I was running my python script with a different version of python than the C extensions were linked with. For example, the following is the output of my python3-config --ldflags command:
-L/usr/local/Cellar/python-dbg#3.7/3.7.6_13/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7dm-darwin -lpython3.7dm -ldl -framework CoreFoundation
So running it with /usr/local/Cellar/python-dbg#3.7/3.7.6_13/bin/python3 caused errors for me. This can be resolved by running the script with /usr/local/Cellar/python-dbg#3.7/3.7.6_13/bin/python3.7dm. Not an obvious fix given that brew installs each with an only slightly modified tap formula.
Second, in my C code, I am frequently writing to an extern'ed character buffer that lives on the stack. When this happens, the default clang stack protection mechanisms throw a SIGABRT at the script. To avoid this, you can recompile by passing the following flags to both the compiler and linker (might be more disabling than is actually needed):
-fno-stack-check -fno-stack-protector -no-pie -D_FORTIFY_SOURCE=0
With these two fixes in place my script runs. And still crashes for other reasons related to multithreading with Python in C. However, this is to be expected, but still has yet to show up in my testing on Linux.
Thanks to #l'L'l for helping me to work through this.
Working with embedded C-projects. There are libraries, include files and so on - for micro controllers. No need for me to use GCC for a host machine and OS (Linux Mint 64 bit). As a rule...
But now I'm trying to compile mspdebug project from a Github - with a GCC of course. And I get an error at the very begin of make:
mspdebug$ make
cc -DUSE_READLINE -O1 -Wall -Wno-char-subscripts -ggdb -I. -Isimio -Iformats -Itransport -Idrivers -Iutil -Iui -DLIB_DIR=\"/usr/local/lib/\" -o util/btree.o -c util/btree.c
util/btree.c:19:20: fatal error: assert.h: No such file or directory
#include <assert.h>
^
compilation terminated.
I search for the includes in all possible paths (I've got the list of them via gcc -v command) - there are no assert.h file, as well, as stdio.h and so on. Except virtual box directories there is only one place (where GCC does not search includes): /usr/lib/syslinux/com32/include
AFAIK, all standard libs and includes are installed with the GCC. So I try to reinstall GCC (4.8.4) - nothing changes.
What is the normal way to give GCC all standard environment it needs?
Thanks to the right direction set by Sam Varshavchik I found the info in the stackoverflow. So I did the following:
1) installed build-essential:
sudo apt-get install build-essential
2) installed libusb (since my try to build the package revealed the absence of usb.h):
sudo apt-get install libusb-dev
And it is OK! The mspdebug (v.023) is compiled and successfully tested!
So, Linux Mint 17.2 (at least) requires installing some libs to a GCC, the most basic is build-essential.
assert.h is not part of gcc, it's a part of glibc.
Most likely, your Linux distribution puts the system headers into a separate package that you need to install.
Fedora, for examples, puts the header files in the glibc-headers package. However, you can't be using Fedora, because Fedora's gcc package has a dependency on glibc-headers, to make sure that it gets pulled in.
Whatever Linux distribution you're using, you need to research which distribution package will install the system header files you need to build stuff with.
I am trying to compile a Hello World for ARM-1136J-S processor. When I compile the C source using CodeSourcery arm-none-linux-gnueabi-gcc (2008q3 edition), it executes successfully on the ARM, but when I compile same code using arm-linux-gnueabi-gcc (installed through apt-get in Ubuntu 12.01) it gives the following error:
./helloworld: line 1: syntax error: unexpected word (expecting ")")
readelf of both the executables show that the binary compiled using Ubuntu toolchain has following extra attributes:
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
How can I make it run using Ubuntu toolchain? Can anyone give some hint on that? Thanks
./helloworld: line 1: syntax error: unexpected word (expecting ")")
This doesn't look like a native code error at all - it looks like a script error. Are you sure "helloworld" is actually your compiled binary. Running compiled C code binaries does not give syntax errors ...
Check that your kernel has support for THUMB binaries:
zcat /proc/config.gz |grep THUMB
Try running 'readelf' on your executable. If the entry point address is an odd number (indicating THUMB or mixed ARM/Thumb) and your kernel lacks THUMB executable support, your binary will be rejected by the kernel, and will be attempted to be run as a shell script.
I had the same problem. The problem went away by adding "-static" to link:
arm-linux-gnueabi-gcc -c test.c -o test.o
arm-linux-gnueabi-g++ -o test test.o -static
If your code use "gethostbyname" you will get
warning: Using 'gethostbyname' in statically linked..
but that is another subject and not easily solved.
I'm trying to generate pdf file by using libharu library but i have compiled the code its creates objective file while run that executable file its giving
error like :undefined reference 'print_grid'
first i export the path:
export PATH="$PATH:/usr/local/lib/libhpdf.so"
and compiled
gcc -c text_demo.c -o text_demo.o
gcc text_demo.o -L"/usr/loca/lib" -lhpdf -o "text_demo.exe"
Try this:
1) Make sure you've actually installed libhpdf.so into /usr/local/lib
2) Compile and link: gcc -Wall -g text_demo.c -L/usr/local/lib -lhpdf -o text_demo
Note that you do not need "exe", you do not need the extraneous quote marks.
Also note that $PATH has nothing to do your your shared library path. That's for Windows; Linux uses $LD_LIBRARY_PATH.
3) Type ldd text_demo
This checks any runtime dependencies
4) Finally, try running your program: ./text_demo
5) Please copy/paste any EXACT error messages during your build, ldd or execute.
You need to install libharu and libharu-devel package
Please find apperopriate pakage from here for centos 5 or cent os 6
http://pkgs.org/search/libharu
And then compile your source code
I have never done any major programing outside of VS08.
I am trying to compile a program called LAMMPS with either of the two relevant make files. One calls g++ and the other calls icc (Intel's compiler).
icc produces this error:
icc -O -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DFFT_FFTW -M write_restart.cpp > write_restart.d
write_restart.cpp(15): catastrophic error: cannot open source file "mpi.h"
#include "mpi.h"
and g++ throws this error
g++ -g -O -DLAMMPS_GZIP -DMPICH_SKIP_MPICXX -DFFT_FFTW -M verlet.cpp > verlet.d
pointers.h:25: fatal error: mpi.h: No such file or directory
compilation terminated.
The mpi.h file is located in /usr/lib/openmpi/include
It is my understanding that I need to set that $PATH variable which reads
bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/opt/intel/bin:/usr/lib/openmpi/include:
and $LD_LIBRARY_PATH which currently reads
/usr/lib/openmpi/lib:
SO, how does one include the mpi.h file? So that either icc or g++ find it?
mpi.h is a header for MPI library. That would be included if you use mpic++ MPI compiler wrapper instead of g++ in your makefile. mpic++ will call the appropriate compiler. From what you describe you have openmpi package installed on your ubuntu machine.
For more info, you need to consult the manual, e.g.
http://lammps.sandia.gov/doc/Section_start.html#2_2 (for LAMMPS)
and perhaps you need to see openmpi manual as to how to set up additional compiler. Not sure if this can be done after openmpi itself has been built. By default I think in Ubuntu openmpi compiler wrappers would only call g++. CMIIW.
Okay, so I got it to work with g++ when setting up cc as "mpic++.mpich2" instead of "mpic++"
you can try compile using openmpi make file in /src/MAKE
make openmpi
in my case, this option was successful