I know how to code but I really do not know my way around a computer.
I have a program that I have to run for my master thesis. It is a code with multiple collabs and runs perfectly on Linux. However, it is a very complex simulational code and therefore it takes time to run for multiple parameters. I've been using my Linux at the university to run it but would like to run some of it on my personal computer (MAC OS). It works by using the R language to call upon c++ functions as follows (being filename a code on c++).
On a Rstudio script:
Sys.setenv("PKG_CPPFLAGS" = "-fopenmp -DPARALLEL")
system("rm filename.so")
system("rm filename.o")
system ("R CMD SHLIB filename.cpp")
dyn.load("filename.so")
After system ("R CMD SHLIB filename.cpp") I get error:
clang: error: unsupported option '-fopenmp'
make: *** [filename.o] Error 1
I've researched on the subject and found this
Enable OpenMP support in clang in Mac OS X (sierra & Mojave)
I've Installed LLVM, yet I do not know how to use it in this case.
How do I use it in this case?
Thank you in advance.
"Don't do it that way." Read up on R and Rcpp and use the proper tools (especially for packaging and/or compiling) which should pick up OpenMP where possible. In particular,
scan at least the Rcpp Introduction vignette
also look at the Rcpp Attributes vignette
"Just say no" to building the compilation commands by hand unless you know what you are doing with R and have read Writing R Extensions carefully a few times. It can be done, I used to show how in tutorials and workshops (see old slides from 12-15 years ago on my website) but we first moved to package inline which helps here, and later relied on the much better Rcpp Attributes.
Now, macOS has some extra hurdles in which tools work and which ones don't. The rcpp-devel mailing list may be of help, the default step is otherwise to consult the tutorial by James.
Edit: And of course if you "just want the above to work" try the obvious step of removing the part causing the error, i.e. use
Sys.setenv("PKG_CPPFLAGS" = "")
as your macOS box appears to have a compiler but not OpenMP (which, as I understand it, is the default thanks to some "surprising" default choices at Apple -- see the aforementioned tutorial for installation help.)
Related
I am currently installing the HDF5 library, more precisely the hdf5-1.10.0-patch1, on Cygwin, as I want to use it with Fortran. Following the instructions from the hdfgroup website
(here is the link), I did the following:
./configure --enable-fortran
make > "out1_check.txt" 2> "warn1_check.txt" &
make check > "out2_check.txt" 2> "warn2_check.txt" &
The execution of the last command (make check) proceeds as it should, until it gets stuck. The process does not stop and something is happening (8-12% CPU are in use by sh.exe, already 39 hours of CPU time) but "out2_check.txt" looks like
Making check in src
...
[many successful checks]
...
============================
No need to test testlinks_env.sh again.
============================
============================
Testing testswmr.sh
Unfortunately, I do not have the output file from the first run of make check, but it did not contain more information on Testing testswmr.sh. There was never any error message.
So, what is this testswmr.sh, why does it get stuck and how can I finalize the installation process? Maybe I can skip the remaining checks and just proceed to make install?
Important note: an older version of HDF5 is already installed from the Cygwin repo. It does not seem to support Fortran however, so I decided to install the current version myself.
Available (and used) compilers are gcc and gfortran.
As far as I can tell, only Intel Fortran is supported on Windows. There is no Cygwin download here https://support.hdfgroup.org/HDF5/release/obtain518.html and I have never come across a report of experience for Cygwin/Fortran/HDF5.
Your options:
Use Intel Fortran
Use Linux or Mac
Sorry
I am Mac OS 10.11 (El Capitan) user. I used 4.6 and when I tried to build some simulation I always get "Simulation terminated with exit code: 139" and couldn’t do nothing at all with that. I thought that when I install 5.0 then everything will be fine, but now I get something like that:
Simulation terminated with exit code: 132
Working directory: /Users/JL_Data/omnetpp-5.0/samples/tictoc
Command line: tictoc -r 0 --debug-on-errors=false omnetpp.ini
Environment variables:
PATH=/Users/JL_Data/omnetpp-5.0/bin::/usr/bin:/bin:/usr/sbin:/sbin
DYLD_LIBRARY_PATH=/Users/JL_Data/omnetpp-5.0/lib::
OMNETPP_IMAGE_PATH=/Users/JL_Data/omnetpp-5.0/images
And when I tried open some simulation in terminal I get:
Illegal instruction: 4
Do you have some idea what can I do with that problem? I tried to find something on the internet, but after one day I do not get any idea.
If you need some more information, please let me know.
As it is right now, your question is not completely clear, since it requires one to be familiar with omnet++ and probably some experience installing and setting it up. However, let me make a couple guesses.
First, Illegal instruction. This usually occurs when the binary was built for an architecture different than the one it's being run on; e.g. when then SSE2 or AVX instructions are present in the binary code, but are missing on the CPU.
See, for example, this SO question:
Find which assembly instruction caused an Illegal Instruction error without debugging
There is also a question that discusses exactly your problem, namely, "Illegal instruction: 4" on OS X:
What is the "Illegal Instruction: 4" error and why does "-mmacosx-version-min=10.x" fix it?
Now, since omnet++ appears to be an open source project, I expect it to have a mailing list and / or an IRC channel. Indeed, here is the communications page on the official website that links to a Google Groups-based mailing list:
https://omnetpp.org/get-involved
https://groups.google.com/forum/#!forum/omnetpp
I advise you to get in touch with the developers with a thorough description of your problem, since the chances of them knowing the solution are significantly higher compared to the chances of there being a user on SO who has faced similar problems when installing an identical version of omnet++ on an identical version of Mac OS X.
Our project needs a tool to gather path profiling information of a program, so I turn to LLVM for help.
However, it seems the function we need is removed since version 3.4. I try the version 3.3 instead, and I find that edge profiling, optimal edge profiling works well. When it comes to path profiling, it simply doesn't work.
And I can't find libprofile_rt.so in version 3.3 build, I download one from http://rpmfind.net/ instead.
The command I use:
opt -insert-path-profiling -o example.pp.bc example.bc
lli -load WHERE_YOUR_LIBPROFILE_RE_SO_LIES/libprofile_rt.so example.pp.bc
#it produces llvmprof.out successfully
llvm-prof example.pp.bc
#then following error occurs : llvm-prof: Unknown packet type #5!
So, my question is :
1.Is there a new version that support PathProfiling again?
2.Any historical version of LLVM support PathProfiling well? If any, please tell me the version number ...
I've checked some old dev mails. The answer to my questions seems to be "NO". But the newest mails were written 2 years ago. Since LLVM is pretty hot these years and a long time passed, I want to make sure the questions above again and get the up-to-date answer.
I hope I make the problem I met clear. Your comments are very welcome.
Thanks
I am trying to compile OpenCL kernels on OS X. Everything is ok when there are just a few lines. However, after the code grows over 1.5k lines, clGetProgramBuildInfo with CL_PROGRAM_BUILD_LOG flag returned "Compile Server Error." every time. I googled but found nothing about it. Could anyone help me?
You can learn the meaning of OpenCL error codes by searching in cl.h. In this case, -11 is just what you'd expect, CL_BUILD_PROGRAM_FAILURE. It's certainly curious that the build log is empty. Two questions:
1.) What is the return value from clGetProgramBuildInfo?
2.) What platform are you on? If you are using Apple's OpenCL implementation, you could try setting CL_LOG_ERRORS=stdout in your environment. For example, from Terminal:
$ CL_LOG_ERRORS=stdout ./myprog
It's also pretty easy to set this in Xcode (Edit Scheme -> Arguments -> Environment Variables).
Please find the original answer by #James
This unhelpful error message indicates that there is bug in Apple's compiler. You can inform them of such bugs by using the Apple Bug Reporting System.
I'm trying to profile a C++ application, that I did not write, to get a sense for where the major computation points are. I'm not a C++ expert and even less so C++ debugging/profiling expert. I believe I am running into a (common?) problem with dynamic libraries.
I compile link to Google CPU Profiler using (OS X, G++):
env LIBS=-lprofiler ./configure
make
make install
I then run profile the installed application (jags) with:
env CPUPROFILE=./jags.prof /usr/local/bin/jags regression.cmd
pprof /usr/local/bin/jags jags.prof
Unfortunately, I get the error:
pprof /usr/local/bin/jags jags.prof Can't exec "objdump":
No such file or directory at /usr/local/bin/pprof line 2833.
objdump /System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib: No such file or directory
The program dynamically links to libLAPACK.dylib. So prof does not seem to understand it (?). I thought about trying to statically link, but the documents associated with the program say that it is impossible to statically link in LAPACK or BLAS (two required libraries).
Is there a way to have the profiler ignore libLAPACK? I'm okay if it doesn't sample within libLAPACK. Or how might I get profiling to work?
This error was caused by jags being a shell script, that subsequently called profilable code.
pprof /usr/local/bin/REAL_EXEC jags.prof
fixes the problem.
I don't see a clean way to do it, but maybe there's a hacky workaround -- what happens if you hack the pprof perl script (or better a copy thereof;-), line 2834, so that instead of calling error it emits the message and then does return undef;?
If you're profiling on OSX, the Shark tool is really great as well. It's very simple to use, and has worked out of the box for me when I've tried it.