I am trying to compile a mex file using openMp on win7_64. The file compiles fine, but when I try to run it I get the error:
Error: Invalid MEX file, the specified module could not be found
DependecyWalker tells me, that LIBGOMP_64-1.DLL is missing which I guess is the openmp library.
I installed the latest version of TDM-GCC and selected to install openmp support in the installer.
Is there anything else I have to install?
Thanks a lot
I copied the LIBGOMP_64-1.DLL from the mingw/bin directory to the directory where the mex file is and now it works...
Related
I'm trying to set up CMake for a project I'm working on, and I'm first trying to compile a simple Hello World program in C. I'm using Windows 10 with MSYS2. If I invoke the compiler (GCC) directly in Bash, it compiles fine without warnings or errors and gives an executable as output which prints "Hello, world!" exactly as expected. My problem comes in when I try to use CMake to compile my project. When I run cmake -G Ninja .. to compile my project, it throws this error:
CMake Error at C:/msys64/mingw64/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"C:/msys64/mingw64/bin/cc.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/dylanweber/Documents/C-Projects/webapp/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/msys64/usr/bin/ninja.exe cmTC_45340 && [1/2] Building C object CMakeFiles/cmTC_45340.dir/testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_45340.dir/testCCompiler.c.obj
C:\msys64\mingw64\bin\cc.exe -o CMakeFiles/cmTC_45340.dir/testCCompiler.c.obj -c testCCompiler.c
/bin/sh: C:msys64mingw64bincc.exe: command not found
ninja: build stopped: subcommand failed.
Notice how it mentions C:msys64mingw64bingcc.exe... there must be some kind of path delineation problem but I've tried setting the CC environmental variable to C:\\msys64\\mingw64\\bin\\gcc.exe and C:/msys64/mingw64/bin/gcc.exe. I have been clearing the CMake caches between runs.
Here is my CMakeLists.txt file:
cmake_minimum_required(VERSION 3.15)
project(webapp)
set(CMAKE_BINARY_DIR ${CMAKE_SOURCE_DIR}/build)
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR})
set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR})
file(GLOB SOURCES "main/*.c")
add_executable(webapp ${SOURCES})
My code is in a "main" folder which is currently just one "main.c" file, in addition to a build directory used to keep all the temporary files in. The most frustrating part is that CMake was just working an hour ago, and I didn't change anything. What can I do to fix this problem?
The solution was not only installing the MinGW64 version of CMake, but also the MinGW64 version of Ninja as well. Since they have different pathing schemes compared to MSYS, they didn't play well together until they were both on the same POSIX-like platform.
I am trying to compile a mex file that requires the mpfr C library, using MATLAB R2013a on Mac OS 10.8.5. I would like it to run on systems that don't have a separate installation of MPFR, so I am trying to include the static library:
mex my_program.c libmpfr.a
I copied the libmpfr.a library into the folder with my source code to simplify things. When I run this command I get the following error message:
ld: targeted OS version does not support use of thread local variables in _mpfr_add for architecture x86_64
A little research suggested that this issue could be due to a problem with the llvm-gcc-4.2 compiler that comes with Xcode and is used in MATLAB by default. So, I tried to set up a different compiler. I got GCC 4.7.4 (the latest version supported by MATLAB) from MacPorts, as described here: http://www.ficksworkshop.com/blog/14-coding/65-installing-gcc-on-mac. Next, I edited the mexopts.sh file to point MATLAB to the correct compiler, by entering the following settings:
CC='/opt/local/bin/gcc-mp-4.7'
CXX='/opt/local/bin/g++-mp-4.7'
Now when I try to compile, I get a different error message:
In file included from /Applications/MATLAB_R2013a.app/extern/include/matrix.h:294:0,
from /Applications/MATLAB_R2013a.app/extern/include/mex.h:58,
from include/main.h:5,
from include/poisson.h:7,
from src/main.c:22:
/Applications/MATLAB_R2013a.app/extern/include/tmwtypes.h:61:21: fatal error: float.h: No such file or directory
If, in mexopts.sh, I additionally set
SDKROOT='/opt/local/'
or a number of other choices (based on the locations of different copies of float.h that I can find on my system), I instead see
my_program.c:10:20: fatal error: stdlib.h: No such file or directory
So it seems that GCC-MP-4.7 is having trouble locating all of the standard C libraries.
I'd be grateful for a solution to either of these issues (linking to static mpfr useing the default compiler, or configuring GCC 4.7 to find the standard C libraries).
I found that the "thread local variables" error was caused by the compiler trying to include backwards-compatibility to OSX 10.5. Since I don't need it to do this, I edited the mexopts.sh file, replacing this line
MACOSX_DEPLOYMENT_TARGET='10.5'
with this:
MACOSX_DEPLOYMENT_TARGET='10.8'
This resulted in the mex file compiling successfully using the built-in Xcode compiler.
I am having problems getting FFTW 3.3 to work on my system.I downloaded the files from the fftw.org website, and then followed the installation instructions which told me to go to the terminal and type
./Configure
make
and everything seemed OK, but when I try and use FFTW in my C code by using the include<fft3> statement I get the fatal error
fatal error: 'fftw3.h' file not found
Does anyone know what I am doing wrong?
My IDE: Eclipse, My System: OSX 10.8
./configure
make
make install
You forgot the install command.
I'm trying to statically link glib into my C program. I'm not sure what's the best way to do this. I downloaded the code and put it in a subdirectory called glib-2.36.4. I added "-Iglib-2.36.4" when using gcc. The glib.h is in the glib-2.36.4/glib directory and in that file there are references to other header files under the glib directory (such as #include ).
I'm not sure why that is since both glib.h and these other header files are at the same level (in glib subdirectory). I got a compile error due to galloca.h not being found (even though it's there). So I copied glib.h up one level and those errors went away. I then got an error about a missing glibconfig.h. I copied that from my usr directory and that error went away. I compiled my project and now I'm getting an error about undefined reference to g_ptr_array_new. I guess this must be because I haven't actually compiled glib. I had tried to build glib, but when I typed "./configure", but I got this message:
checking if arpa/nameser_compat.h is needed... configure: error: could not compile test program either way
I did install glib using yum, but I really want this code to run even if glib is not installed on a machine.
You need to install both glib and glib-dev via yum, compile using ./configure, (take a look in the ./configure script to see if there are any flags you need to supply or defines you need to produce the static build), without moving any files about, and then you need to compile your code using -i path/to/glib/includes and link with -L path/to/built/static/library
I am trying to compile OpenCV on windows using CMAKE and MinGW on Windows. However, when I try to do that I am getting the following error:
The C compiler identification is GNU
The CXX compiler identification is GNU
Check for working C compiler: C:/MinGW/bin/gcc.exe
CMake Error: Generator: execution of make failed. Make command was: make "cmTryCompileExec\fast"
Check for working C compiler: C:/MinGW/bin/gcc.exe -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple test program.
Does anyone know what could be an issue?
Are you running CMAKE within the MinGW shell or within CMD.exe? The first suggestion I can give you is to use MinGW shell because several environment variables are better setup for the compiler in this way. Otherwise you may have to tweak a little your windows environment variables.
You may have also installed Cygwin (and installed gcc also in cygwin). In this case, if you use CMD.exe and that the bin directory of Cygwin is read first than the one of MinGW in the system PATH variable, you can get this kind of errors too.