MEX: C2143 error: stdio.h missing ')' before '*' - windows

I am trying to compile a bunch of C files using MEX under windows 7 (64 bits). In order to do that I installed Matlab R2014a and the Microsoft SDK 7.1 with the C/C++ utilities.
The fact is that when I execute the command:
mex -g file_1.c file_2.c
I got many error like the one posted in the title.
I already tried setting MEX to use the c and c++ VS compiler because I thought it was an error due to the bad compiler choose, but unfortunately it didn't.
Does anyone have some hints what could I try?
Thanks in advance!

Related

Question for GCC equation.com for building the using static

I like windows gcc equation.com because it like ran natively just like windows compiler. However :
I will need some dll's that not included on distributed package. if i compiled a windows equation.com gfortran program like using Openblas, it will need libgcc_s_seh-1.dll libgfortran-5.dll libquadmath-0.dll libwinpthread-1.dll.
I could find it on web. But how to make it statically linked, i saw libgcc.a libgfortran.a libquadmath.a libpthread.a so i dont have to copy the dll from other. It is possible ?
For several c source code it need include <sys/resource.h> that not included. It's compatible with resource.h from where. After just copied from others, and recompile.
I got error :
c:\gcc\x86_64-w64-mingw32\include\sys\resource.h:74:29: error: unknown type name 'id_t'; did you mean 'pid_t'?
Is there any forum for this type gcc? Is there any debugger for windows gcc that friendly like VisualStudio Community for Intel Fortran.
Regards.

MATLAB mex not looking for compiler gfortran on macOS

I need to call some Fortran code from within MATLAB. I did some research and read about the mex command and how to use it. Sadly I'm already failing at getting the Fortran compiler to work.
First of all, here's my setup:
macOS Sierra 10.12.1 (latest version)
MATLAB R2016b (latest version)
gfortran 4.9.2 (installed via .dmg from official GNU site)
According to the MATLAB documentation, I can use mex -setup FORTRAN to prepare mex for building a mex-file from Fortran. However, running the command in verbose mode yields the following output: mex -setup -v FORTRAN
Verbose mode is on.
... Looking for compiler 'Intel Fortran Composer XE' ...
... Looking for environment variable 'IFORT_COMPILER16' ...No.
... Looking for environment variable 'IFORT_COMPILER15' ...No.
... Looking for environment variable 'IFORT_COMPILER14' ...No.
... Looking for environment variable 'IFORT_COMPILER13' ...No.
... Executing command 'which ifort' ...No.
Did not find installed compiler 'Intel Fortran Composer XE'.
Error using mex
No supported compiler or SDK was found. For options, visit
http://www.mathworks.com/support/compilers/R2016b/maci64.html.
Following the link, one can see that MATLAB does support GNU gfortran 4.9.x on Linux. On Mac however, only Intel's commercial compilers are listed as supported. That's what mex seems to be looking for as well.
Since Mac can also use gfortran to compile Fortran code I thought it'd be possible to get it to work with MATLAB. I've also googled alot and found questions like this one on the MathWorks forum, which suggests that MATLAB should be able to use gfortran, even on Mac.
That's what I think is strange, my MATLAB isn't even looking for a gfortran compiler. All it does is look for an Intel compiler, can't find one and then throws above stated error message.
Regarding my gfortran installation. It is definitely 4.9.2 (which is listed as supported under Linux), which gfortran returns /usr/local/bin and I can successfully compile programs via Terminal.
By the way, mex -setup ANY successfully lists the compilers for C and C++ but no Fortran.
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.
MEX configured to use 'Xcode 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 C compiler, select one from the following:
Xcode with Clang mex -setup:'/Users/Lennart/Library/Application Support/MathWorks/MATLAB/R2016b/mex_C_maci64.xml' C
Xcode Clang++ mex -setup:'/Users/Lennart/Library/Application Support/MathWorks/MATLAB/R2016b/mex_C++_maci64.xml'
I also had a look at those .xml files mentioned at the very end of the last output. There was no file for anything having to do with Fortran and I wasn't able to successfully write one myself. I'm not even sure whether that's the problem...
So simply put my question is: How can I get MATLAB to actually look for and then of course also find my gfortran compiler to use it to compile mex files?
Appreciate your help!
Thanks to hsuyaa and the provided link I was able to resolve my problem. As it needed some more experimenting by myself, I'd like to post how exactly I was able to get gfortran to work.
Look at this link and the accepted answer. Although the MathWorks Team explicitly states that the instructions are specifically written for xCode 7.0 and MATLAB R2015b, I got everything to work with xCode 8.1, MATLAB R2016b and macOS Sierra 10.12.
MATLAB seems to be storing the compiler configuration details in .xml-files as mentioned before. You can find the directory in MATLAB by entering
cd( fullfile( matlabroot, 'bin', 'maci64', 'mexopts' ) );
I did perform a fresh install of MATLAB before but at that location, only three files where located, one for Clang, one for Clang++, one for Intel's Fortran. The gfortran one was simply missing.
The solution author at MathWorks appended all of these .xml-files to his post. I downloaded the files and copied gfortran.xml to the above mentioned folder. This granted partial success in that it made MATLAB actually look for gfortran when running the mex setup.
However, since the files are not up-to-date, I had to add a few lines. I don't exactly understand how the configuration files work, but I noticed that some lines where referring to older macOS versions. Download the file gfortran.xml behind the above link and then add the following:
Wherever you see
<dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk" />
or
<cmdReturns name="find $$ -name MacOSX10.11.sdk" />
also add
<dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk" />
or
<cmdReturns name="find $$ -name MacOSX10.12.sdk" />
macOS 10.12 is Sierra. Saving the file and running mex -setup FORTRAN again successfully identified gfortran and set it as the fortran compiler for mex.
Your matlab version is not able to detect the supported compilers. May be this Link can help.

MinGW GCC wildcard

I'm using MinGW GCC compiler on windows how to compile all C files in a directory.
I used
gcc *.c -o Output
after I entered the required folder and I got this error
gcc: error: *.c: Invalid argument
gcc: fatal error: no input files
compilation terminated.
the used version of GCC is 4.7.1
For anyone else like me who's come across this problem:
I ran into this problem when I installed MinGW-w64 on my tablet after having run it for a few years on my desktop.
Basically, I have a ruby script that does some basic compilation stuff for me, and it was breaking at the linking stage on my tablet (developed on, and ran fine on the desktop).
The error: Invalid Argument, no input files (as in the original question).
If you check around, you'll find a few places that tell you that the issue is due to the way CMD on Windows handles passing wildcards to programs (vs UNIX shells).
Basically Windows leaves interpretation of the wildcard up to the program.
Some builds of MinGW can handle a wildcard from CMD, whereas others won't.
I'm able to use wildcards using the MinGW-W64-builds installer for MinGW-W64.
This should work with older mingw-w64 versions:
#ifdef __MINGW64_VERSION_MAJOR
int _dowildcard = -1; /* enable wildcard expansion for mingw-w64 */
#endif

How do I resolve the following libtool 64-bit compilation error

I'm trying to compile the NTL library (host is 64 bit, but target platform is 32), but I'm having some trouble with libtool. The command, alongside with the output can be found in this pastebin. I know I'm doing something wrong with the rpath structure, but I'm not all too familiar with it to know exactly what. Any help?
EDIT: Configure is run as:
./configure CC=/tmp/ntl-build/bin/arm-linux-androideabi-gcc CXX=/tmp/ntl-build/bin/arm-linux-androideabi-g++ SHARED=on AR=/tmp/ntl-build/bin/arm-linux-androideabi-ar RANLIB=/tmp/ntl-build/bin/arm-linux-androideabi-ranlib NTL_GMP_LIP=on GMP_PREFIX=/prod/android-ndk-r8/workspace/verifiable/gmp-precompiled/armeabi-v7a DEF_PREFIX=/tmp/ntl-build/install_dir
How's FFT.o compiled? The huge cascade of error messages that ends with:
.libs/FFT.o: could not read symbols: File in wrong format
indicates that something doesn't match up. From the paste, it seems as if you have cross compiled with the Android NDK tools, but are linking with the native (x86_64) gcc (which in turn calls the native ld).

Compiling Clang on Windows

I followed instructions at http://clang.llvm.org/get_started.html
I compiled latest trunk of llvm and clang with MSVC 2010. Now I can compile simple programs with Clang but when I tried to compile this program I got a lot of errors.
Here is program:
#include <algorithm>
int main(){ return 0; }
And here are some of errors:
In file included from hello.cpp:1:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\algorithm:6:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\memory:987:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\intrin.h:24:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\immintrin.h:32:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\xmmintrin.h:988:
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1384:22: error: expected expression
return (__m128)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1390:23: error: expected expression
return (__m128i)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1396:23: error: expected expression
return (__m128d)__in;
^
Complete output from Clang: http://pastebin.com/qi87K8qr
Clang tries to use MSVC headers but it doesn't work. Maybe I should use libc++ or libstdc++ instead, but how to do that?
Note I'm not interested in precompiled clang binaries
Yes, clang simply does not support all of Microsoft's extended C++ syntax, and therefore cannot parse Microsoft's C++ headers which use that syntax. Not only that but Clang also doesn't have complete support for Microsoft's C++ ABI, name mangling, etc. I believe Clang on Windows works alright with C, however.
To use a different C++ standard library instead you can make clang ignore the normal header and library directories with, IIRC, -nostdinc++ and -nostdlib++. Then you can tell clang the include and library directories you want to use (using -isystem or -I or whatever). However I'm not sure whether libc++ or libstdc++ work under those circumstances, since they probably depend on things that the Windows C runtime library does not have.
Chandler Carruth mentioned at Going Native 2013 that there are now alpha builds of clang for Windows with Visual Studio integration. Lots of stuff is broken, for example, streams (so good old hello world won't work). However, there is a lot of effort being put into making clang work on Windows, so expect it to get pretty good pretty fast.
Errors were in the header supplied with clang itself. Looks like it can't handle MMX/SSE types properly. Try to add -msse -msse2 switches to the command line.
I'm using libstdc++ and built clang using VS2012Express for desktop. The cmake string was "Visual Studio 11 Win64" and the essential dirs. are specified using -I argument.
My guess you program could work if I used mingw headers for Windows.

Resources