I'm trying install files extracted from tar file, but non of my files are installing under usr/include directory on target board, but I see my files under temp/work/aarch64/recipedir/image/usr/include/mydir/ and include/myfile.h. While building I haven't got any errors.
do_install() {
install -d ${D}${includedir}
mkdir -p ${D}${includedir}/mydir
install -m 0644 ${S}/include/myfile.h ${D}${includedir}
install -m 0644 ${S}/include/mydir/*.h ${D}${includedir}/mydir/
}
FILES_${PN} += "${includedir}/mydir
Everything in ${includedir} is put into ${PN}-dev by default.
c.f.: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n316
You have to remember that a file can only be in one package. To determine in which package a file is going to make it, it's pretty simple. Starting from leftmost package in PACKAGES, the first package to have the file matching any path in FILES_<pkg> will have the file.
By default, ${PN}-dev appears before ${PN} in PACKAGES.
c.f.: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n294
You can check which package has your file without "reverse-engineering" the whole thing by running oe-pkgdata-util find-path '/usr/include/mydir'.
If you really want this header file in your system (why?), you can either add ${PN}-dev to your image or hack things (remove the -dev package from PACKAGES or move ${PN} before ${PN}-dev, if you only have one file in ${includedir}, etc.).
I am using the davidva/gcc49 copr, on Fedora 27.
When I try to compile after running source /usr/bin/gcc49 as the copr webpage describes, I get this error:
/usr/bin/ld: cannot find -lgcc_s
After learning about how the flag -l works for gcc, I learned it is looking for library gcc_s. I found it in /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64, which sounds like the right spot for it to be. Why is it not linking? Do I need to add a directory to a library path? If it's LDFLAGS, it's already there because of the file I sourced:
export LDFLAGS="-L/opt/gcc-$gver/$lib/gcc/$gcc_target_platform/$lib/"
What do I need to do to get gcc 4.9 on Fedora 27 to find its library file which is clearly in the LDFLAGS directory?
The problem is that the libgcc_s.so file is in the wrong directory! Just symlink to it in the 4.9.3 directory:
pushd /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3
sudo cp -p ../lib64/libgcc_s.so.1 .
sudo ln -s libgcc_s.so.1 libgcc_s.so
popd
I guess the /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64 directory was supposed to be included in any LDFLAGS parameter, and that might be a weakness of the build process I was using and not the gcc 4.9 package.
Putting this file and appropriately-named symlink in the 4.9.3 directory allows my build process to complete successfully.
Reference: https://bgstack15.wordpress.com/2018/02/01/gcc-4-9-for-fedora-27/
I am trying to install a perl module Bio::DB::Sam on my home directory on a remote server.
I downloaded the module, extracted the files, and ran:
perl Build.pl prefix=~/local
this is what happens next:
This module requires samtools 0.1.10 or higher (samtools.sourceforge.net).
Please enter the location of the bam.h and compiled libbam.a files: **/some_places/samtools-0.1.19**
Found /some_places/samtools-0.1.19/bam.h and /some_places/samtools-0.1.19/libbam.a.
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'Bio-SamTools' version '1.39'
Next when I try to run:
./Build
this is what I get:
Building Bio-SamTools
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o blib/arch/auto/Bio/DB/Sam/Sam.so lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o -L/some_places/samtools-0.1.19 -lbam -lpthread -lz
/usr/bin/ld: /some_places/samtools-0.1.19/libbam.a(bgzf.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/some_places/samtools-0.1.19/libbam.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error building blib/arch/auto/Bio/DB/Sam/Sam.so from lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o at ~/perl5/lib/perl5/ExtUtils/CBuilder/Base.pm line 323.
I did google the possible solutions and tried a couple, but they didn't work, e.g. --enable-shared OR export CXXFLAGS="$CXXFLAGS -fPIC".
I have already have Bioperl installed on my home directory.
Any help would be appreciated.
Cheers
Here is a script that will fetch the SAMtools source and compile it, then fetch and compile the Perl bindings.
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
export SAMTOOLS=`pwd`
cpanm Bio::DB::Sam
Part of the problem you were likely seeing is that the SAMtools project has recently undergone some major code reorganization (and this has naturally made it difficult to work with external language bindings).
I fixed this issue by remaking samtools with the -fPIC parameter
make clean
make CXXFLAGS=-fPIC CFLAGS=-fPIC CPPFLAGS=-fPIC
then installed using cpan.
cpan[2]> install Bio::DB::Sam
[Solved]
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
enter cpan in terminal and enter
install Bio::DB::Sam
Be carefully:
You can not use the following command:
perl -MCPAN -Mlocal::lib -e 'CPAN::install(Bio::DB::Sam)'
You can only use cpan and then use
install Bio::DB::Sam
I followed instructions from README file below of Bio-SamTools-1.43 to edit the Makefile in samtools 0.1.17. Then, to install, I used
perl -MCPAN -e shell
install Bio::DB::Sam
README:
This is a Perl interface to the SAMtools sequence alignment
interface. It ONLY works on versions of Samtools up to 0.1.17. It does
not work on version 1.0 or higher due to major changes in the library
structure.
See http://samtools.sourceforge.net/ for samtools documentation.
ONE-STEP INSTALLATION
In the root directory of this distribution you will find the script
INSTALL.pl. Running this will download the latest versions of this
module and SamTools into a temporary directory, compile them, test and
install. Simply run:
perl INSTALL.pl
MULTI-STEP INSTALLATION
The more traditional install requires you to separately download,
unpack and compile SAMtools 0.1.10 through 0.1.17 in some accessible
directory. Typing "make" in the samtools directory will usually
work. SAMtools versions 0.1.18 and higher do not work with this
library.
Then set the environment variable SAMTOOLS to point to this directory.
You will also need to install Bio::Perl from CPAN.
Now run:
perl Build.PL
./Build
./Build test
(sudo) ./Build install
TROUBLESHOOTING:
If you encounter problems during compiling, you may need to edit
Build.PL so that extra_compiler_flags matches the CFLAGS and DFLAGS
settings in the Samtools Makefile. Here are some common problems:
When building this module, you get an error like the following:
relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
To fix this, edit the Makefile in the Samtools distribution by adding
"-fPIC" to the CFLAGS line. While you're at it, you may also wish to
get rid of a bunch of unused variable warnings that appears under
recent versions of gcc. The modified CFLAGS will look like this
CFLAGS= -g -Wall -Wno-unused -Wno-unused-result -O2 -fPIC #-m64 #-arch ppc
Then do "make clean; make" in the Samtools directory to recompile the
library. After this you should be able to build this module without
errors.
When building this module, you get an error about a missing math
library.
To fix this, follow the recipe in (1) except add -m64 to CFLAGS so it
looks like this:
CFLAGS= -g -Wall -O2 -fPIC #-m64 #-arch ppc
TESTING AND CONTRIBUTING:
You can obtain the most recent development version of this module via
its GitHub site at https://github.com/GMOD/GBrowse-Adaptors. Please
feel free to submit bug reports, patches, etc. via GitHub.
AUTHOR:
Lincoln D. Stein
Copyright (c) 2009-2015 Ontario Institute for Cancer Research
This package and its accompanying libraries are free software; you can
redistribute it and/or modify it under the terms of the Artistic
License 2.0, the Apache 2.0 License, or the GNU General Public License
(version 1 or higher). Refer to LICENSE for the full license text.
I've been given a project to run on MATLAB R2011a. As there are several .c files in there - I need to set up GCC as the MEX compiler for that project. However, I cannot seem to find any explanation as to how to set it up. I've tried a script program called gnumex - but it failed (probably set up for an older version of MATLAB).
Any idea how to set it up?
Why not adjust the mexopts.bat file in your directory? That way you can use the "mex" command transparently to compile anything, as usual in MATLAB, the same as if it was configured by MATLAB using mex -setup. I'm surprised nobody did this before.
The file below is for x64 version of Matlab and Mingw. I'm using the TDM Mingw64 distribution, which I installed in p:\mingw64-tdm. I have Matlab installed in p:\matlab\R2012a -- edit those accordingly.
This is the mexopts.bat file I'm using, copy paste this in %USERPROFILE%\AppData\Roaming\MathWorks\MATLAB\R2012a\mexopts.bat:
#echo off
set MINGWPATH=p:\mingw64-tdm
set PATH=%MINGWPATH%\bin;%PATH%
set COMPILER=gcc
set COMPFLAGS=-c -m64 -I"%MATLAB%\extern\include" -DMATLAB_MEX_FILE -Wall -std=c99
set OPTIMFLAGS=-O3 -DNDEBUG
set DEBUGFLAGS=-g
set NAME_OBJECT=-o
set LINKER=gcc
set LINKFLAGS=-shared -L"%MATLAB%\bin\win64" -L"%MATLAB%\extern\lib\win64\microsoft" -lmex -lmx -leng -lmat -lmwlapack -lmwblas
set NAME_OUTPUT=-o "%OUTDIR%%MEX_NAME%%MEX_EXT%"
Then you can just try doing this in Matlab:
mex -v p:\matlab\R2012a\extern\examples\mex\yprime.c
which yprime
Should yield b:\code\m\yprime.mexw64 (or whatever the current folder is). Then if you do:
yprime(1,1:4)
You should see:
ans =
2.0000 8.9685 4.0000 -1.0947
Which means you're in business. Good luck!
EDIT Oct 2014: I now use an improved mexopts.bat file than the above with a different MinGW64 (yields slightly faster binary code than TDM's). See my homepage for details and downloads.
In Matlab 2011b, just compile and link directly in mingw64 or cygwin environment.
MINGWPATH=c:/MinGW64
CYGPATH=c:/cygwin
MATLABROOT=c:/Progra~1/MATLAB/R2011b
CC=$(MINGWPATH)/bin/x86_64-w64-mingw32-gcc
CFLAG= -Wall -m64 -O3 -I$(MATLABROOT)/extern/include $(SRC) $(LIBS) -o $(EXE)
MEXFLAG=-m64 -shared -DMATLAB_MEX_FILE -I$(MATLABROOT)/extern/include -Wl,--export-all-symbols $(LIBS) $(MEXSRC) -o $(MEXTGT).mexw64
LIBS= -L$(MATLABROOT)/bin/win64 -L$(MATLABROOT)/extern/lib/win64/microsoft -lmex -lmx -lmwlapack -lmwblas -leng
EXE=../bin/engwindemo.exe
MEXTGT=
SRC=engwindemo.c
MEXSRC=
all:$(EXE)
$(EXE): $(SRC)
$(CC) $(CFLAG) -ladvapi32 -luser32 -lgdi32 -lkernel32 -lmingwex -o $(EXE)
#rm -f *.o*
$(MEXTGT): $(MEXSRC)
$(CC) $(MEXFLAG) -ladvapi32 -luser32 -lgdi32 -lkernel32 -lmingwex
#rm -f *.o*
Put this makefile on the source code directory and make. No dll files conversion needed.
As of MATLAB R2015b, MinGW is officially supported!
It's now at the top of the list of supported compilers.
See here for the official instructions for downloading MinGW (they recommend TDB-GCC).
There are several limitations and caveats listed (e.g. don't link with libraries compiled with other compilers, you have to catch your exceptions inside the MEX file, etc.).
Below is my old way of making an XML file to do the same thing.
The years have gone by and MATLAB (as of R2014a) has moved to a new XML-based system for configuring MEX files. MATLAB still temporariily supports legacy .bat files, for now, but it will bother you about it. Another change is that are distinct C and C++ configurations (more later).
What has stayed the same is that you just need to download and extract a MinGW distribution and point MATLAB to it. There is still no need for MSYS, cygwin or gnumex. The only tricky part is pointing MATLAB to it, but here is a solution.
Short Version
Download and extract a MinGW distribution. Pick one, such as MinGW-w64 (64-bit) or TDM-GCC (32-bit and 64-bit options).
Customize the XML config file, using this one as a template (details in long version below).
Set MINGWROOT environment variable.
Run mex -setup:[xmlfile] [C|C++].
Long Version
For MinGW-w64, I do the following to set it up:
Grab the latest revision for w64 from Sourceforge (or use the installer to choose the toolchain you want, picking a pthread or Win32 threads version depending on your needs).
Extract it so that you have a path to the compiler like C:\mingw-w64\x86_64-4.9.2-release-posix-seh-rt_v3-rev1\bin\x86_64-w64-mingw32-g++.exe. There is no need for MSYS, cygwin, or any other environment if you plan on compiling in MATLAB with the mex command. Check your PATH environment variable to make sure you don't have multiple compilers (g++) on your path, preferably none. Verify with a fresh command prompt.
Set it up with a custom XML configuration file. On my GitHub repo, I have posted C++ configurations for MinGW-w64 in both file types: mex_C++_mingw-w64.xml and legacy mingw_mexopts.bat. Start with that as a template and (optionally) edit the XML file with a descriptive name and version of the MinGW distribution you downloaded and extracted.
Set (or create) the MINGWROOT environment variable. This is what allows the mex command to locate the compiler. You can do this in MATLAB (and every time MATLAB starts with a startup.m script in userpath) with setenv, or just once with the Windows properties dialog or the native Windows 7 setx.exe command.
Run mex -setup:C:\actual\configFilePath.xml C++. For example, using the .xml file to set up C++ MEX file compilation:
setenv('MINGWROOT','H:\mingw-w64\x86_64-4.9.2-release-posix-seh-rt_v3-rev1')
mex -setup:H:\building\GitHub\MATLAB\MinGW\mex_C++_mingw-w64.xml C++
The output should look like this:
MEX configured to use 'MinGW-w64 GCC 4.9.2 posixthreads seh' for C++ language compilation.
If needed, set up the C compiler in a similar manner with a new XML config file specifying the C language, the C compiler frontend (e.g. "x86_64-w64-mingw32-gcc.exe" which won't automatically link the C++ standard library), adjust the link libraries as needed, compiler flags (e.g. change -std=c++11 to -std=c99), etc.
Note about static vs. dynamic linking of runtime libraries
Libraries such as a MEX file created with MinGW-w64 as above may depend on a few DLLs (at runtime): LIBGCC_S_SEH-1.DLL (for the seh exception distributions) and LIBSTDC++-6.DLL, and possibly libwinpthread-1.dll if you chose a pthreads distribution instead of Win32 threads. If you don't want to copy these files around, you can statically link the runtime libraries into your MEX file by adding the following switches:
-static-libgcc -static-libstdc++
There's a comment in the XML template about this. See here for info about libpthread-1.dll.
With TDM-GCC, the opposite is true: the runtimes (including pthread) are statically linked automatically. To link dynamically, which will require the DLLs but reduce your MEX file size, you need:
-shared-libgcc -shared-libstdc++
EDIT: There seems to be a much better way with MinGW; see my other answer.
You can compile a .mex file using gcc if you have Matlab installed, from the command line. Some might say it's a little tedious the first time.
First things first - what Matlab do you use? if it's 64-bits, MinGW won't help you, because it's 32-bit. I will therefore show how to use MinGW-w64 instead. Understanding how to do this with 32-bit MinGW should be straightforward.
Add C:\MinGW-64\bin\ to your path. You won't regret this :)
Compile your .c files using gcc:
x86_64-w64-mingw32-c++ -m64 -shared -I"C:\Program Files\MATLAB\R2010b\extern\include" -o bla.mexw64 -DMATLAB_MEX_FILE -Wl,--export-all-symbols *.cpp
This will result in a bunch of linker errors, such as
undefined reference to `mexErrMsgTxt'
To solve this problem, you'll have to create an import library which connects with libmex.dll, libmx.dll, libmat.dll and libeng.dll (you might have others, but these are the main ones)
List the functions you're missing, and, well, guess what dll they're coming from. Hint: mexErrMsgTxt is from libmex.dll, because it starts with "mex"...
For every dll you need to export, create a .def file containing
EXPORTS
... relevant function names go here, such as mexErrMsgTxt, matOpen, etc.
Execute the following command, to create import libraries:
x86_64-w64-mingw32-dlltool -d libmx.def --dllname libmx.dll -l libmx.a
(Same for the rest of the .def files)
Now you're good to go!
x86_64-w64-mingw32-c++ -m64 -shared -I"C:\..." -DMATLAB_MEX_FILE -o bla.mexw64 -Wl,--export-all-symbols *.cpp libmex.a libmx.a libmat.a libeng.a
Things which can be done better -
instead of --export-all-symbol, only export mexFunction (requires creating another .def file, or adding "__declspec(dllexport)" before void mexFunction(...)).
MinGW is capable of direct-linking a DLL; that is, it will create a kind of an import library on the fly when linking.
This means compilation can be performed in one step:
x86_64-w64-mingw32-c++ -m64 -shared -I"%MATLAB%/extern/include" -DMATLAB_MEX_FILE -o bla.mexw64 -Wl,--export-all-symbols *.cpp -L"%MATLAB%/bin/win64" -lmex -lmx -leng -lmat
Matlab links to external code (C++, Fortran, Java etc) using MEX files. (http://gnumex.sourceforge.net/)
Setting up Compiler:
Install TDM-GCC (C++ Compiler "C:\MinGW32\bin;") from http://tdm-gcc.tdragon.net/download
Install Cygwin (toolkit provides Unix tools on the Windows platform) from (http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII4.0/cygwin.htm). Download and Install cygwingDevel.exe
Obtain the gnumex archive via (https://sourceforge.net/projects/gnumex) and extract the gnumex to ($MATLABHOME\gnumex). Where $MATLABHOME would be for example (C:\Program Files\MATLAB\R2010a)
Add this directory ($MATLABHOME\gnumex) to the Matlab path (File->Set Path in Matlab). Note: Run Matlab with Administrator priviledges.
In Matlab, type gnumex at the prompt. Fill in appropriate paths like;
MinGW_Root = C:\MinGW32, Cygwin_Root=C:\cygwin
Do 'File->Save Config', then click 'Make Options file'. Exit from gnumex configure window.
Testing:
Copy mexopts.bat (%AppData%\MathWorks\MATLAB\R2010a\mexopts.bat) to the working directory (%UserProfile%\Documents\MATLAB) for this test.
In matlab, execute the following at prompt;
mex -f mexopts.bat "C:\Program Files\MATLAB\R2010a\extern\examples\mex\yprime.c"
You get (%UserProfile%\Documents\MATLAB\yprime.mexw32) when you type;
which yprime
Run it by typing at Matlab prompt >> yprime(1,1:4) and see if you get 2.0000 8.9685 4.0000 -1.0947.
Now just copy mexopts.bat to $MATLABHOME\bin and it should work from anywhere.
Matlab on Linux Platform:
At Linux prompt, install the following;
sudo apt-get install gcc g++ gfortran
In Matlab, execute the following at prompt;
mex -setup
The options files available for mex are: **1**: /usr/local/MATLAB/R2012b/bin/mexopts.sh : Select option 1. To test the working, execute the following at Matlab prompt;
mex "/usr/local/MATLAB/R2012b/extern/examples/mex/yprime.c"
yprime(1,1:4)
In case you get the warning;
Warning: You are using gcc version "4.6.3-1ubuntu5)". The version
currently supported with MEX is "4.4.6".
For a list of currently supported compilers see:
http://www.mathworks.com/support/compilers/current_release/
At Linux prompt:
sudo apt-get install gcc-4.4 g++-4.4 gfortran-4.4
sudo gedit /usr/local/MATLAB/R2012b/bin/mexopts.sh
Change 'gcc' to 'gcc-4.4' ,'g++' to 'g++-4.4' , 'gfortran' to 'gfortran-4.4' at all instances of CC = 'gcc' , CXX = 'g++' and FC = 'gfortran'.
Save the file and exit.
This is a detailed walkthorugh of this answer. Therefore, all the credit should go to that answer.
1 Install MinGW-w64:
1.1 Download this MinGW64-w64 build and its update:
(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/mingw-w64-bin_x86_64-mingw_20111101_sezero.zip/download)
(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/sezero_20111101-w64-update-rev.5747.zip/download)
(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/README-mingw-w64-20111101_sezero.txt/download)
1.2 Install (unzip) the downloaded archives:
1.2.1 Unzip the build file and move the resulting mingw64\ folder in c:\
1.2.2 Unzip and copy (overwrite) the update file on c:\mingw64
1.3 Add C:\mingw64\bin to the Path variable:
set PATH=C:\mingw64\bin;%PATH%
2 On a commandline (outside Matlab environment), compile your *.c files: For example, CCODEFILE.c (Assuming Matlab 2012b installed in C:\Program Files\MATLAB\R2012b\ folder):
"c:\mingw64\bin\x86_64-w64-mingw32-g++.exe" -m64 -shared -I"C:/Program Files/MATLAB/R2012b/extern/include" -DMATLAB_MEX_FILE -o CCODEFILE.mexw64 -Wl,--export-all-symbols CCODEFILE.c -L"C:/Program Files/MATLAB/R2012b/bin/win64" -lmex -lmx -leng -lmat
3 Then, any Matlab code should work fine when it calls the CCODEFILE function.
If you couldn't install Mingw-w64 using the Add-Ons toolbar of Matlab2016b on Windows, you can use this workaround. Keep this in mind that you need to change the paths according to your installation paths.
The Mingw-w64 official website redirects you to Win-builds project which is a package manager for a bundle of open source development tools. So, first you need to install the Win-builds.
While installing Win-builds, make sure you are entering a path that does not contain any spaces e.g. C:\Win-builds.
After installing Win-builds, just hit the Process button to install all packages where Mingw-w64 is among them.
Now that you installed Mingw-w64, you need to define the MW_MINGW64_LOC environment variable which Matlab uses it to detect Mingw-w64.
To define the environment variable do the following steps:
Control panel\ System\ Advanced system settings\ Advanced\ Environment Variable\ User variables for $YOUR_USER_NAME\ New
Put Variable name = MW_MINGW64_LOC and Variable value = C:\Win-builds. Notice that the Win-builds puts all executables in C:\Win-builds\bin and by defining this variable, Matlab will automatically scans the bin folder of the path looking for gcc.exe.
Now that you installed the Mingw-w64 and define the MW_MINGW64_LOC environment variable, it is time to build and test the yprime example. So Launch Matlab and type the following command (Do not forget to modify the path accordingly):
mex -v 'C:\Program Files\MATLAB\R2016b\extern\examples\mex\yprime.c'
A successful installation will show the following message:
MEX completed successfully.
Finally, you can test your installation by typing yprime(1,1:4). The answer would be:
ans = 2.0000 8.9685 4.0000 -1.0947
Why so many steps? If you have Matlab 2016 or higher, just do:
Download mingw and install to a folder without spaces (ie. not into "Program Files")
Add the MW_MINGW64_LOC environment variable pointing to the install folder (the exact same thing you typed into the installer)
Restart your PC
Open MATLAB and type mex -setup into the console. It should say "configured to use MinGW"
Run/compile your MATLAB program
I've tested these on a new Windows 10 PC and it works!
This one works on Matlab 2012b under Windows 8:
https://github.com/DynareTeam/dynare/blob/master/windows/mexopts-win64.bat
Modify cgwin directory or replace it with mingw directory if used. You can also echange the compiler-exe if you switch to a 64 bit version.
In Windows 64 bit with R2011a it worked with http://tdm-gcc.tdragon.net/ and http://gnumex.sourceforge.net/ but I have to change maxopt.bat line entry GM_ADD_LIBS as follows:
rem Add path to where dlls are:
set DLL_PATH="C:\Program Files\MATLAB\R2011a\bin\win64"
rem Add every dll needed:
set GM_ADD_LIBS=%DLL_PATH%\libmx.dll %DLL_PATH%\libmex.dll %DLL_PATH%\libmat.dll
It took me a long time to get to this point, good luck.
I originally thought this sounded like a form of torture, but based on the above answer by #user10171136 I actually found it pretty straightforward to cross-compile for Windows mex from Fedora Linux. Fedora has mingw and mingw64 packages, so:
sudo yum install mingw64-gcc mingw64-gcc-c++
Copy over from a Windows Matlab install both the extern/include and bin/win64 directories (actually you probably only need a subset of the headers and a small subset of the dlls; libmat.dll libmex.dll libmx.dll might be all you need. I put these two directories into a new R2010a-w64 directory under my existing Linux MATLAB directory; change the below commands appropriate for where you stashed the Windows headers and libs.
There was one problem I ran into, which is that char16_t was needed in matrix.h and wasn't defined. I guess matrix.h forgot to include uchar.h? I worked around with an -include directive; see below.
x86_64-w64-mingw32-gcc -m64 -shared -include uchar.h -I/opt/MATLAB/R2010a-w64/extern/include -DMATLAB_MEX_FILE -L/opt/MATLAB/R2010a-w64/bin/win64 -o bla.mexw64 bla.c -lmx -lmex
(You may need additional libraries for linking, e.g. -lmat -leng -lm, etc.)
This successfully generates a mex file that is executable under Windows Matlab for my setup. So far I've only tested this with pretty simple C programs.
Interested to hear if this sounds reasonable; I don't have much experience with cross-compiling.
On linux, if you type mex -setup, you can choose the compiler.
On windows, you should try to install lcc, you can do so for instance by installing Microsoft Visual Studio Express, which is free.
Simple question: I have a C++ project configured for a existing makefile and it compiles fine. However, the IDE keeps complaining that it cannot resolve most of my symbols.
How do I configure eclipse to use my includes?
Project->properties->C/C++ General->Paths and Symbol
Add the path to your include directory.
You can see in the screenshot, the configuration I use to develop with Qt in C++.
I added my includes in the paths and symbols, but they are not added during qt compilation.
For compilation, qt uses these includes and ignores what I've added:
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Idebug -I. -o debug/bp.o bp.cpp
g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -Idebug -I. -o debug/Navigation.o Navigation.cpp
Navigation.cpp:16:22: error: XnOpenNI.h: No such file or directory
Navigation.cpp:17:26: error: XnCppWrapper.h: No such file or directory
Navigation.cpp:18:20: error: XnHash.h: No such file or directory
Navigation.cpp:19:19: error: XnLog.h: No such file or directory
Navigation.cpp:22:16: error: cv.h: No such file or directory
Navigation.cpp:23:18: error: cv.hpp: No such file or directory
I found the answer here:
QT Eclipse Integration - Adding External Libs
It seems that this is a kind of conflict between the CDT and Qt builder, so even if you add the options in CDT as in the screenshot above, the compiler doesn't find them!
You need to add them in the xxx.pro file as this:
http://doc.qt.digia.com/4.5/qmake-variable-reference.html#includepath
I had the same problem when I imported an existing Makefile project with:
File -> New -> Makefile Project with Existing Code
If you don't want to configure anything and just want eclipse to recognize all Paths from your existing (working) Makefile on it's own just do the following:
right click on your project -> Clean Project
right click on your project -> Build Project
The Eclipse Indexer then recognizes all paths on it's own without needing any additional configuration. You just need Eclipse to execute your imported Makefile and everything is resolved (if your Makefile works properly outside Eclipse).
Tested in:
Eclipse IDE for C/C++ Developers
Version: Luna Service Release 2 (4.4.2)
Build id: 20150219-0600