I'm new to Matlab and was trying to build a C file. The code gets compiled fine with gcc (4.8.4 in 64-bit Ubuntu). But when I try to build with mex, it shows following error:
error: exponent has no digits
I'm not sure what I'm doing wrong. The error is in this file. Complete error log is here.
When I compile the code using gcc, there are no errors. I do not provide any special arguments to gcc. To my knowledge, mex is using gcc so I do not understand why mex is failing to build the code.
I've little knowledge of C programming and any help is highly appreciated!
Edit:
To clarify more, I've got the source in two files:
File 1 has the C code with a main function, and uses functions from this
file (which mex can not build).
File 2 has the C code of the S-Function which call's File 1's main function. File 2 has an include statement to include File 1.
When I said I can build using gcc, I just built File 1 with this command: gcc file1.c -o file1. I think not building File 2 with gcc has no impact here in my question, as only File 1 uses those functions from the file which mex can not build.
I used this command from Matlab mex file2.c to build and got the error.
For C code, you probably need to enable GNU extensions for C99 (-std=gnu99). As described in my previous post on enabling C99, to pass this to mex:
mex -v -largeArrayDims CFLAGS="\$CFLAGS -std=gnu99" mexSouce.c
The reason the default does not work is because mex likes to choose the ANSI standard, which is often not the newest.
Related
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I am using Mac OSX (yosemite V 10.10.1) and running MATLAB 2014a on it.
I wanted to use SPAM library (sparse modeling software by J. Mairal) on MATLAB and for that I have to install XCode6.1 (that has gcc). First I type in command window mex -setup and result is shown below:
mex -setup
MEX configured to use 'Xcode with Clang' for C language compilation.
Warning: The MATLAB C and Fortran API has changed to support MATLAB
variables with more than 2^32-1 elements. In the near future
you will be required to update your code to utilize the
new API. You can find more information about this at:
http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html.
To choose a different language, select one from the following:
mex -setup C++
mex -setup FORTRAN
So after that I run the compile.m file in SPAM library and suddenly I saw an error that was:
add_flag =
-mmacosx-version-min=10.6
Warning: Directory already exists.
> In compile at 144
compilation of: -I./linalg/ -I./decomp/ -I./prox/ -I./dictLearn/ dictLearn/mex/mexArchetypalAnalysis.cpp
Building with 'Xcode Clang++'.
clang: warning: argument unused during compilation: '-fopenmp'
Error using mex
ld: warning: directory not found for option '-L/usr/lib/gcc/x86_64-linux-gnu/4.8/'
ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in compile (line 439)
mex(args{:});
I don't understand what to do. please help me!
It appears that the actual error is occurring at the point of linking with precompiled libraries. The 2 issues are as follows:
The compile code apparently included in the compile.m file looks like it is intended to compile with gcc (it is trying to include files installed by GCC, possibly even linux-specific ones, are you sure that it's an OSX-compatible toolbox?), and yet the error strongly suggests that you are in fact using clang to compile it - you will either need to change the compiler (easy) or rewrite compile.m (not so easy).
One of the libraries that the code needs to have installed in order to be properly linked hasn't been found. On OSX I think this file should be called libgomp.dylib (any mac afficionados want to confirm this?). If you have it on your computer, then it's not in a directory that clang is looking in. You can confirm the library is installed by running find / | grep libgomp.dylib from the terminal - if it is there, you can add it into the compiler argument in compile.m using the -I /DIRECTORY_HOLDING_LIBRARY syntax.
It is entirely possible that fixing 1. will also remediate 2. - I have never tried using SPAM
I have tried to install the libsvm package with
mex -setup
(since "make" resulted in an error). This was followed by one choice for a compiler, so I chose "1".
Afterwards I typed in "make" got the following error though:
xcrun: error: SDK "macosx10.7" cannot be located
clang: warning: no such sysroot directory: '-mmacosx-version-min=10.7'
libsvmread.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.
mex: compile of ' "libsvmread.c"' failed.
If make.m fails, please check README about detailed instructions.
What can I do?
I think the following answer from the matlab support might be helpful (http://www.mathworks.com/matlabcentral/answers/103904-can-i-use-xcode-5-as-my-c-or-c-compiler-in-matlab-8-1-r2013a-or-matlab-8-2-r2013b):
The Mac OS X 10.7 SDK, available in Xcode 4.1 through 4.6, is used by
MEX and related capabilities. This SDK is no longer available in Xcode
5, resulting in errors similar to the following when compiling:
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang", not a developer tool or
in PATH
The simplest solution is to avoid updating Xcode to version 5 if you
are using R2013a or R2013b. If you need Xcode 5, or you have already
irreversibly upgraded to it, you can update MEX to use the 10.8 SDK:
In the MATLAB Command Window, execute the following commands:
cd(matlabroot)
cd bin
edit mexopts.sh
Save a backup copy of this file somewhere in case you make a mistake and you need to revert your changes.
Scroll down to the Mac (“maci64”) section of this file, beginning around line 120.
Replace all instances of 10.7 with 10.8; there are four of these in all (a fifth may be found in comments only)
Save the file, then execute the following command in the MATLAB Command Window:
mex -setup
Please note that this workaround links MEX files with a different SDK
than with which MATLAB was tested. Although there are no known
compatibility issues, support may be limited.
I have 64-bit Mac, OS X 10.8.5, and I have xcode installed. I can also verify gcc works from the command line. When I type mex -setup I get
The options files available for mex are:
1: /Applications/MATLAB_R2013a.app/bin/mexopts.sh :
Template Options file for building MEX-files
0: Exit with no changes
This is unhelpful. And when I type make, with all of the relevant libsvm files in my folder of choice, I get
make
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang", not a developer tool or in PATH
mex: compile of ' "libsvmread.c"' failed.
If make.m fails, please check README about detailed instructions.
Is anyone able to help me with this?
The quickest thing is to edit the mexopts.sh file directly, using your favorite text editor (you may need to do this with "Administrator Privileges"). The file:
/Applications/MATLAB_R2013a.app/bin/mexopts.sh
defines a bunch of paths and flags for invoking the C/C++ compiler on your system. It tends not to keep up with revisions to the MacOS.
On my system, I had to make the following changes:
lines 258-260
CC='gcc'
SDKROOT='/Developer/SDKs/MacOSX10.6.sdk'
MACOSX_DEPLOYMENT_TARGET='10.6'
line 273
CXX=g++
There will be many references to "CC=" in the file; you're looking for the ones that follow the line
maci64)
But the correct values for your system depend on which gcc/g++ you have and where they are installed. As you can see, I have the MacOS 10.6 Developer tools installed under /Develop. You will need an install of the Developer tools (XCode) - see
How to use/install gcc on Mac OS X 10.8 / Xcode 4.4
In more recent versions of the XCode tools, the path might look more like:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
But compiling MEX code with more recent versions of XCode might cause other problems - I had issues with char16_t, see:
MEX compile error: unknown type name 'char16_t'
I'm trying to make http://iridia.ulb.ac.be/~manuel/hypervolume (version 2.0) on windows using the instructions they've given in their README which is to install MINGW and run "make mex", however I keep getting this error:
$ make mex
mex -D VARIANT=4 Hypervolume_MEX.c hv.c
mex.exe: Invalid command-line option
mex.exe: Data: unknown option
make: *** [mex] Error 1
instructions given:
Guillaume Jacquenot contributed a MEX interface for MATLAB
(Hypervolume_MEX.c). Use make mex to compile it.
Any help would be appreciated thank you
Within matlab change directories to the location of the hypervolume code, then run
mex -DVARIANT=4 Hypervolume_MEX.c hv.c avl.c
at the matlab command prompt. If your c compiler is set up correctly within matlab this should generate an executable named Hypervolume_MEX.xxx (dll in my case).
edit
I used the matlab compiler (Lcc C 2.4) on Matlab 7. No luck with Visual Studio 6 or Watcom 10.6 compilers (although I did not attempt to debug).