I just installed MinGW + MSYS in Windows XP using graphical installer. Everything seems fine.
However, when I try to build a C++ application using ./configure, make, make install, it shows error message. The following 2 checkings failed:
AC_CHECK_LIB(m, memcpy, [], [AC_MSG_ERROR([error msg])])
AC_CHECK_FUNC(memcpy, [],[AC_MSG_ERROR([error msg])])
Why my MinGW couldn't find memcpy and its library? Can anyone give me suggestion how to fix this error? Thank you.
void * memcpy ( void * destination, const void * source, size_t num );
Copy block of memory, copies the values of num bytes from the location pointed by source directly to the memory block pointed by destination.
For reference please see http://www.cplusplus.com/reference/cstring/memcpy/
Related
So, I have a MEX gateway script file that calls my C source code. I've used the -L and -I commands to link my 64-bit compiled GSL libraries (.libs) to my mex executable, which is then compiled under the extension of .mexw64.
I want for this executable to be transferred to another windows machine and run fine, without any GSL libraries installed. That is the the only solution, I don't care what he arguments are regarding the benefits of the dynamic linking/code generation upon compile-time are. I want an executable that has every function not only (of course) pre-declared, but also PRE-DEFINED.
I was lead to believe that this is what 'static' linking is vs. dynamic; but I've read some contradictory definitions all around the interwebs. I need a completely 100% standalone, singular file.
Supposedly you can link the actual .obj file in the mex function, which I can generate, but unfortunately I then get unresolved symbol errors.
Someone else mentioned that I can use the -l (lowercase L) to directly link the actual .lib(s) needed, statically, but that is NOT true.
So is there anyone that can lead me in the right direction, either how to have everything not only linked but to also have the DEFINITIONS linked and ready to load when executable is run--completely standalone, or why I am running into unresolved symbols/linker errors when I include my .obj file? Am I misunderstanding something elementary about the linking process?
Also: To elaborate a bit more, I have the GSL libraries built and linked via Visual Studio for the 64 bit architecture, and I can link it easily with MATLAB, so that is not my problem (any more).
EDIT: I've seen the post here:
Generating standalone MEX file with GNU compilers, including libraries
This doesn't solve my problem, however, although it is the same question. I don't have access to gcc; it's finally compiling on the MSVS12 compiler in MATLAB, I'm not going try to recompile using GCC via MinGW (already tried, couldn't figure it out), so -static and .a options are out.
In your previous post, you mentioned that you decided to compile GSL library with Visual C++, using the VS solution provided by Brian Gladman.
Here is a step-by-step illustration on how to build a MEX-function that links against GSL libraries statically:
Download GNU GSL sources (GSL v1.16)
Download the matching Visual Studio project files (VS2012 for GSL v1.16)
Extract the GSL tarball, say to C:\gsl-1.16
Extract the VS project files on top of the sources, this will overwrite three files as well as add a folder C:\gsl-1.16\build.vc11.
Open Visual Studio 2012, and load the solution: C:\gsl-1.16\build.vc11\gsl.lib.sln
Change the configuration to the desired output: for me I chose platform=x64 and mode=Release
First you must build the gslhdrs project first
Now build the whole solution. This will create two static libraries cblas.lib and gsl.lib stored in C:\gsl-1.16\lib\x64\Release (along with corresponding PDB debugging symbols). It will also create a directory containing the final header files: C:\gsl-1.16\gsl
Next we proceed to build a MEX-function. Take the following simple program (computes some value from a Bessel function, and return it as output):
gsl_test.c
#include "mex.h"
#include <gsl/gsl_sf_bessel.h>
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
if (nrhs != 0 || nlhs > 1) mexErrMsgTxt("Wrong number of args.");
plhs[0] = mxCreateDoubleScalar(gsl_sf_bessel_J0(5.0));
}
This is how to compile the above C code in MATLAB:
>> mex -largeArrayDims gsl_test.c -I"C:\gsl-1.16" -L"C:\gsl-1.16\lib\x64\Release" cblas.lib gsl.lib
Finally we test the MEX-file, and compare it against the value reported by MATLAB's own Bessel function:
>> x = gsl_test()
ans =
-0.1776
>> y = besselj(0,5)
y =
-0.1776
>> max(x-y) % this should be less than eps
ans =
8.3267e-17
Note that the built MEX-function has no external DLL dependencies (other than "Visual C Runtime" which is expected, and the usual MATLAB libraries). You can verify that by using Dependency Walker if you want. So you can simply deploy the gsl_test.mexw64 file alone (assuming the users already have the corresponding VC++ runtime installed on their machines).
I followed steps in this SO link to compile a sample program using OpenCV2.4.0 in windows. I made a setup both in DEVC++ and NetBeans with Mingw. My sample Program is getting Compiled properly, but when I run the exe the application get crashes.
But In same machine I used opencv2.1.0 and the same sample program gets compiled and there is no crash while running it.
The below is the Sample Code I tried to execute:
#include "highgui.h"
using namespace std;
int main( int argc, char** argv ) {
IplImage* img = cvLoadImage( "C:\\Documents and Settings\\All Users\\Documents\\My Pictures\\Sample Pictures\\Water lilies.jpg" );
cvNamedWindow( "Sample", CV_WINDOW_AUTOSIZE );
cvShowImage( "Sample", img );
cvWaitKey(0);
cvReleaseImage( &img );
cvDestroyWindow( "Sample" );
}
UPDATE :
I follwed as the steps as moskito-x link to build the opencv and when I press "configure", I get the following error. And my make file is also 35kb in size.
Any suggestions to solve this?
Using the libs in "...\opencv\build\x86\mingw\bin" and "...\opencv\build\x86\mingw\lib
You can not use the libraries that come with OpenCV-2.4.x.exe.
As some developers in forums and I find out. On some systems, the precompiled libs of "opencv 2.4.x" can not be used.
To compile your own programs, works, but it crashed if you try to run them. Until there are not functioning precompiled libs of "opencv 2.4.x , you have to compile opencv yourself.
Ignore so the folder "...\opencv\build\x86\mingw\bin" and "...\opencv\build\x86\mingw\lib" completely.
As already pointed out you can't rely on precompiled binaries. I also had a lot of problems and finally ended up with compiling my own binaries. My setup was for Windows7, Eclipse CDT (Juno) and MinGW. You can check my post on Stackoverflow here
I guess this is an error related to memory management. Maybe because your'e releasing the window before the image. But anyhow you should use the OpenCV C++ interface, as this does a lot of stuff automagically. With the C++ Interface your code would look like this:
#include <opencv.hpp>
int main( int argc, char** argv ) {
cv::Mat img = cv::imread("C:\\Documents and Settings\\All Users\\Documents\\My Pictures\\Sample Pictures\\Water lilies.jpg");
cv::imshow("Sample", img);
cv::waitKey(0);
return 0
}
I am getting an invalid arguments error in eclipse, though I am confident my arguments are good. The suggested arguments contains a '?' which I think may indicate the problem, though I do not know how to fix it.
I have done my best to copy the example I saw here:
http://www.cplusplus.com/reference/clibrary/cstring/memset/
In order to be certain that I am getting the args right.
#include <stdio.h>
#include <string.h>
void foo()
{
char str[] = "why oh why does my IDE give me errors when I know my args are good?";
memset(str, '-', 4);
puts(str);
}
Eclipse gives me the following error on the memset line:
Invalid arguments ' Candidates are: void * memset(void *, int, ?) '
What could be causing this? And what is up with that '?' as the 3rd arg?
Thanks in advance!
PS: Just noticed I am getting similar errors when I try to use operations like malloc, calloc, etc.
In Eclipse:
right click the project
click properties
Expand "C/C++ general" the item in the left hand tree view by clicking the arrow, (just clicking the item itself does not expand the suboptions)
From the suboptions select "Preprocessor Include Paths, Macros etc."
Click the "Providers" tab
Check the box next to "CDT GCC Built-in Compiler Settings [ Shared ]".
Edit:
The reason this works is that there are a bunch of default includes and defines that the compiler silently adds behind the scene when you compile. These instructions get eclipse to grab these otherwise silent preprocessor directives so that it's own indexer is using the same settings
The following method resolves the same problem that I was having. (on eclipse 4.2)
Clean your project (Project -> Clean)
Reindex files (Project -> C/C++ Index -> Rebuild)
Rebuild your project (Project -> Build All)
I think it is something to do with your Eclipse setup, somehow.
Taken standalone, that fragment compiles under GCC (G++) 4.7.1 on Mac OS X 10.7.5 with the command line:
g++ -O3 -g -Wall -Wextra -c ms.cpp
The only surprising thing about the third argument to memset() is that it is of type size_t, but the headers are supposed to declare that, so it should not be an issue.
If you're using malloc() et al, you will be including <stdlib.h>, of course. There is also room to argue that you should be using <cstdio>, <cstring> and <cstdlib>, but that shouldn't stop the code you presented from compiling without error.
If you're working with Visual Studio, size_t is defined as
typedef unsigned __int64 size_t;
In previous versions of the Eclipse CDT, __int64 was not defined. You can fix that issue by adding into C/C++ General -> Paths and Symbols -> Symbols
Symbol: __int64
Value: long long
Or you can upgrade your Eclipse CDT version
I've been using a 3rd party C++ library for BeagleBone development and I tried every possible way to include it (as preprocessor includes, source folder, assember includes, library includes, C++ compiler includes, C compiler includes etc). Refreshen, reindex, clean and built for every change I attempted. I even deleted the project and copied only the .cpp and .h files over to a new project.
I finally found the problem in my setup and rectified it as follows.
Right-click the project > Properties > C/C++ Build > Tool-chain editor > Current Builder:> Select CDT Internal Builder
I'm using g++, for your information.
I had a similar issue with the Eclipse CDT. But in my case the thing was that I had put the using namespace std; statement in a several headers. And in some combination of conditions, when I included all of this headers the Eclipse had such the behavior.
I had a similar issue when compiling someone's code, and the problem was the code style. They defined some methods in this way:
// ... Inside a class
static void
sleep( u32 ms );
I guess this is GNU style. Just changing the declaration to
static void sleep( u32 ms );
removed the issue.
I am working on the Unity Plugin project and try to import the c++ native dll from c# file.
But I keep getting dllnotfoundexception.
c++ dll code:
extern "C" {
extern __declspec( dllexport ) bool IGP_IsActivated();
}
c# code:
[DllImport("mydll")]
private static extern bool IGP_IsActivated();
Dll is in place and FIle.Exists work properly. All dependent dlls are present at same hierarchy, but I still end up in dllnotfound exception.
Any help, much appreciated!!
Thanks to this Unity forum post I came up with a nice solution which modifies the PATH-environment variable at runtime:
Put all DLLs (both the DLLs which Unity interfaces with and their dependent DLLs) in Project\Assets\Wherever\Works\Best\Plugins.
Put the following static constructor into a class which uses the plugin:
static MyClassWhichUsesPlugin() // static Constructor
{
var currentPath = Environment.GetEnvironmentVariable("PATH",
EnvironmentVariableTarget.Process);
#if UNITY_EDITOR_32
var dllPath = Application.dataPath
+ Path.DirectorySeparatorChar + "SomePath"
+ Path.DirectorySeparatorChar + "Plugins"
+ Path.DirectorySeparatorChar + "x86";
#elif UNITY_EDITOR_64
var dllPath = Application.dataPath
+ Path.DirectorySeparatorChar + "SomePath"
+ Path.DirectorySeparatorChar + "Plugins"
+ Path.DirectorySeparatorChar + "x86_64";
#else // Player
var dllPath = Application.dataPath
+ Path.DirectorySeparatorChar + "Plugins";
#endif
if (currentPath != null && currentPath.Contains(dllPath) == false)
Environment.SetEnvironmentVariable("PATH", currentPath + Path.PathSeparator
+ dllPath, EnvironmentVariableTarget.Process);
}
Add [InitializeOnLoad] to the class to make sure that the constructor is run at editor launch:
[InitializeOnLoad]
public class MyClassWhichUsesPlugin
{
...
static MyClassWhichUsesPlugin() // static Constructor
{
...
}
}
With this script there is no need to copy around DLLs. The Unity editor finds them in the Assets/.../Plugins/...-folder and the executable finds them in ..._Data/Plugins-directory (where they get automatically copied when building).
Well I got it working.
For others who may face this problem, if you have more than one dll, you need to put the secondary dlls at root level of the Unity editor (e.g. C:\Program Files\Unity\Editor) and the actual referenced dll from script into plugins folder.
This worked for me.
Put the DLL(s) Unity interfaces with in Project\Assets\Wherever\Works\Best\Plugins.
Place any dependency DLLs that are not directly accessed by your scripts in Project. This will allow your program to run in the editor.
When you build, again copy the dependency DLL files, this time to the root of the build directory (right next to the generated executable). This should allow your application to load them at runtime.
(Tip: you can use Dependency Walker look at you DLLs and see what they depends on.)
I spent one day with this error. My issue was that Android doesn't get the library and always get and DDLNotFound error. My solution was:
1.- Be sure that you have the libraries for the proper architecture in the Plugins folder.
Plugins/Android/x86 and Plugins/Android/armeabi-v7a if your build settings is FAT(x86&arm)
2.- Check that Unity recognizes them as libraries. If you select them in the Project tab you should see them as a library and the platform and architecture related.
3.- After the build (don't close Unity Editor!), you can check in the Temp/StagingArea/libs if your libraries are there. If there are there for sure the libraries are going to be in the APK. As a double check, you can open your APK (change to zip extension) and see the libraries in the lib folder.
4.- In C# you should remove any lib prefix in your library name, for example:
If your library name is "libdosomething.so" you should call it as
[DllImport ("dosomething")]
I hope this work for you :)
Cheers.
Make sure the following chacklist is satisfied:
Plugins should all stay in a folder called Plugins.
The architecture your dll is built for (x86 or x86_64) must correspond to the architecture version of Unity Editor. Unity Editor 32-bit will not load 64 bit plugins and viceversa.
If you are targeting both 32 and 64 bit architectures you should put your dlls in special named folders inside the Plugins folder. The names are Plugins/x86 for 32 bit dlls and Plugins/x86_64 (x64 also works) for 64 bit dlls.
Visual C++ Redistributables must be installed. I have all from 2008.
When you build all your dlls should be copied into the root where your executable is (and again built for the correct x86/x64 architecture)
If you keep getting a namespace error it means the dll you are importing has unmanaged code and it must be wrapped into another managed dll Pugin in order to work.
These threads are a bit outdated but still relevant
DLLNotFoundException - Unity3D Plugin
Unity internal compiler error with custom dll
In my case, I have DllNotFoundException: ovrplatiformloader
Unity : DllNotFoundException: ovrplatformloader
Unity : at (wrapper managed-to-native) Oculus.Platform.CAPI.ovr_UnityInitWrapperAsynchronous(string)
Unity : at Oculus.Platform.AndroidPlatform.AsyncInitialize (System.String appId) [0x00013] in <29065e843b82403894fca6c6f2974090>:0
Unity : at Oculus.Platform.Core.AsyncInitialize (System.String appId) [0x0004f] in <29065e843b82403894fca6c6f2974090>:0
Unity : at DBHelper.Start () [0x00019] in <29065e843b82403894fca6c6f2974090>:0
My solution is:
Re-import files that doesn't work (libovrplatformloader.so)
Reconstruct the Platform/Plugins architecture. Old: Platform/Plugins/Android32/libovrplatformloader.so. New: Platform/Plugins/Android/x86/libovrplatformloader.so and Platform/Plugins/Android/armeabi-v7a/libovrplatformloader.so
Modify the import setting of libovrplatformloader.so. Change any platform to only Android platform and enable 'load on startup' selection. Choose ARMv7 CPU in armeabit-v7a while choose x86 CPU in x86 folder.
just put the dlls under Plugins folder and that works for me
I was having the same issue, and the solutions described here didn't work.
I think my case was a little different.
I think that the .dll I was importing depended on other .dll files. So I imported the other files related to that .dll (which I thought were unnecessary since I am not calling them directly on c# code) and that solved the issue.
This is Subhash. I am having problem in linking fortran-matlab mex files.
I am running MATLAB R2010a. I am trying to mex fortran subroutines in MATLAB. I have installed MSYS, MinGW and gfortran. I have also downloaded and extracted gnumex in the c:\documents\MATLAB folder. I entered gnumex to run the installation settings.
At this point, I see a window pop-up and I entered the following:
MinGW's root directory ---> Pointed towards c:\mingw b) Cygwin's
root directory -----> left blank c)
Path to g95.exe ------> c:\mingw\bin
path to gfortran.exe ------> c:\program files\gfortran\bin e)
path to gnumex utilities ------> c:\users.....\matlab\gnumex
environment linking type ------> MinGW
generate mex dll or engine-----> mex
language for compilation -------> fortran 77
add stub ------> no
optimization level -----> -O3
path for libraries and .def files
c:\users...\Roaming\MathWorks\MATLAB\R2010a\gnumex
Mex options file to create:
c\users...\Roaming\MathWorks\MATLAB\R2010a\mexopts.bat
The above is my installation setup for mex with gnumex. When I hit make options file, an warning message pops out which says
" cannot corret mex.pl .....
"cannot open c:...\R2010a\bin\mex.pl for writing"
and when I hit ok, again it pops out saying to confirm overwrite of mexopts.bat .
I hit confirm and the opt file is created.
At this point I should have my mex setup ready. But, when I run the fortran mex examples xtimesy.f, etc.. ( I use mex filename.f at the command prompt) and I get the following error
g77: getValidInputLinkLibraries: No such file or directory
c:\prog~1\MATLAB\R2010A\BIN\MEX.PL: Error: Link of 'xtimesy.mexw32' failed.
Error using ---> mex at 222
unable to complete successfully.
I tried this uninstalling several times, but ended up with the same error.
Could anyone please let me know where am I going wrong. Is this not the correct procedure to link the g77? Please throw some light on this.
I appreciate your time..
Thanks.
I recently tried to mex some fortran routines and failed due to the poor support for fortran compilers by matlab in windows. I got around the problem by using f2c to convert the fortran to C code, then creating a gateway routine in C which calls the automatically generated C code functions and mexing the resul using the visual studio 2008 compiler which integrates nicely with matlab (the free express edition version is sufficient, you will also be able to use it for debugging).
You can get f2c from http://www.netlib.org/f2c/. You must link the produced C code to the f2c library, which you may also have to build from the sources.
I know this all sounds very complicated, but it was easiest solution I found.