Hello i build 32 and 64 bit version wxwidget (Batch Build and select all) from source code without any problems. Then add path to the system variables as named "WXWIN" with C:\wxwidget (there is wxwidget source)
In visual studio 2019 in solution i add these path's:
C/C++ -> Additional Include Directories ->
$(WXWIN)\include
$(WXWIN)\include\msvc
Linker -> Additional Library Directories ->
$(WXWIN)\lib\vc_lib $(WXWIN)\lib\vc_lib\mswud
But i got error in visual:
Severity Code Description Project Path File Line Suppression State
Error (active) E1696 cannot open source file
"../../../lib/vc_lib/mswd/wx/setup.h" guiwxwidget C:\wxwidgets\include\wx C:\wxwidgets\include\wx\setup.h 140
And i dont know whats wrong with it.
I try also recompile 4x wxwidget source without any progress.
Your project is not configured to use Unicode, hence it tries using non-Unicode build of wxWidgets (note the missing u in mswd/wx/setup.h) which is not available. You should ensure that the "Character Set" option in the "Advanced" section of your project properties is set to "Use Unicode Character Set".
The strange thing is that this should be the default, so it looks like you might have changed it intentionally. If you really did, you will need to build wxWidgets in (deprecated and soon to be removed) ANSI build mode, but it's much better to leave this option at its default value and use Unicode -- we're in 2021, after all, not 1991.
Related
I am struggling to call MATLAB from a simple .cpp program despite the many resources online for this problem.
My Objective:
Use Microsoft Visual Studio 2010 Professional 64-bit to build .cpp program that
calls MATLAB Engine for built-in functions and graphs (MATLAB R2013b 64-bit)
What I have done:
In the .cpp file property pages, I have:
1) Changed the platform to Active(x64)
2) Added the following paths to the VC++ Directories
Executable Directories: C:\Program Files\MATLAB\R2013b\bin
Include Directories: C:\Program Files\MATLAB\R2013b\extern\include
Reference Directories: C:\Program Files\MATLAB\R2013b\bin\win64
Library Directories: C:\Program Files\MATLAB\R2013b\extern\lib\win64\microsoft
Path Edits
3) Wrote the following program:
// mEng.cpp : Defines the entry point for the console application.
// libeng.dll is in C:\Program Files\MATLAB\R2013b\bin\win64
#include "stdafx.h"
#include <Engine.h>
#include <matrix.h>
#include <iostream>
#include <string>
#include <cmath>
#pragma comment (lib, "libmat.lib")
#pragma comment (lib, "libmx.lib")
#pragma comment (lib, "libmex.lib")
#pragma comment (lib, "libeng.lib")
#pragma comment (lib, "libut.lib")
using namespace std;
int main()
{
Engine *m_pEngine;
if (!(m_pEngine = engOpen("")))
{
fprintf(stderr, "\nCan't start MATLAB engine\n");
return EXIT_FAILURE;
}
//Now call the MATLAB script through MATLAB Engine
engEvalString(m_pEngine, "script");
cout << "Hit return to continue\n\n";
fgetc(stdin);
//Close the MATLAB Engine
engClose(m_pEngine);
return EXIT_SUCCESS;
}
Errors received:
“The program can’t start because libeng.dll is missing from your computer. Try reinstalling the program to fix this problem.”
I faced the same problem and spent one day to solve it.
So here is my answer.
Actually you overdefine different directories (see the "Path Edits" link).
It is enough to made just these:
Project Properties -> VC++ Directories -> Library Directories. Add here path C:\Program Files\MATLAB\R2016a\bin\win64 (version and path can differ, but the idea is to est path to the same folder of your MATLAB)
Project Properties -> C/C++ -> General -> Additional Include Directories. Add path C:\Program Files\MATLAB\R2016a\extern\include (your path of this folder)
Project Properties -> Linker -> General -> Additional Library Directories. Add path C:\Program Files\MATLAB\R2016a\extern\lib\win64\microsoft
Project Properties -> Linker -> Input -> Additional Dependencies. Add here: libeng.lib; libmx.lib;
And the last and the most important: add the path of MATLAB Engine dll libraries to your Windows. This step solve your problem. We can do it this way: My Computer -> right click: Settings. Opened window System. Left bottom corner: Advanced System Settings
Advanced Tab
In the Environment variables for your user press Create... button and add this one:
Variable name: PATH
Variable value: C:\Program Files\MATLAB\R2016a\bin\win64
This path is reference on where is your libeng.dll located.
Important moment: it can require to restart VS or even restart computer.
Hope it helps some people, who start to work in MATLAB and C++!
Follow my notes here:
https://www.mathworks.com/matlabcentral/answers/100603-how-can-i-compile-a-matlab-engine-application-using-microsoft-visual-studio-9-0-or-10-0
I would like to take this opportunity though to re-format the instructions given there:
To compile a MATLAB engine application in the Microsoft Visual Studio 9.0 (2008) or Microsoft Visual Studio 10.0 (2010) environments, perform the steps outlined below:
Open Microsoft Visual Studio and select
File->New->Project
and then select:
Visual C++ -> General -> Empty Project
Following this, enter the name of the project and its location in the
indicated text areas and click OK.
Note be very careful with this step as it will create the solution folder and
put a project folder in there, so you won't want to set this up, get it all
working and then change the folder as that will break the solution and you'll
have to start all over.
Right-click on the SOURCE FILES folder in the SOLUTION EXPLORER and click
Add -> "New Item..."
Choose "C++ file (.cpp)", enter the name of the file
(as enginedemo.cpp) as you wish. Click OK.
Copy the code from the source file: engwindemo.c, and paste it into this
file enginedemo.cpp. The file engwindemo.c may be obtained from the following
location:
$MATLABROOT/extern/examples/eng_mat
where $MATLABROOT is the MATLAB root directory, and may be determined by
entering the command:
matlabroot
at the MATLAB command prompt.
I'd suggest that at this point you open it in Notepad and if it has some
weird format, fix and save it so it looks like a normal C file when you open
it in Notepad (or gedit or whatever).
This is where things change in Visual Studio and I hope this extends somewhat
transparently to VS Code, Eclipse, or whatever IDE you'd like to use.
So I will re-number the property change section in roman numerals and fix the
order.
Also be sure to hit ENTER and then APPLY after making every change.
Make sure of the change before you go to the next section.
Double-check the spelling and MAKE SURE the directories exist on your
platform.
Go into the Solution Explorer view, Right click on the project name and
select PROPERTIES in the solution explorer to open the project properties.
Once this window has opened, make the following changes:
Go to the Configurations bar at the top of the property page.
You most definitely want to start with this setting.
Pick a configuration, debug or release, or "all configs" if you want the
changes to apply to BOTH debug and release, or you will have to do them all
over again for the other configuration. Which may not be such a bad idea, as
the individual release options are often more "optimized" versions of the
corresponding debug options. Note you can run
into serious trouble changing the property values while switching between
debug and release modes, don't be surprised if the IDE crashes, the solution
database gets corrupt, even the debug won't build and you have
to start all over. Get the debug to work first, back-up the entire solution,
then "clone" the debug settings to release, and then tweak the release
settings one at a time, making sure that the code still builds and runs
between each change.
If compiling to 64-bit Windows, change the target from x86 to x64 & use 64-
bit DLLs and library files.
If this is not in the Configuration options at the very top where it says
"Configuration Manager" (as in VS2015), then follow your IDE instructions...
as mentioned on the following link:
https://www.microsoft.com/en-us/download/details.aspx?id=55984
Under
Configuration Properties ->Debugging
Add the following Target path in the Environment:
(for 32 bit MATLAB)
PATH=$matlabroot\bin\win32
(for 64-bit MATLAB)
PATH=$matlabroot\bin\win64 If you want to use an absolute path instead,
use the following (with a semicolon at the end)
PATH=C:\Program Files\MATLAB\R2013a\bin\win32; (for 32 bit MATLAB)
PATH=C:\Program Files\MATLAB\R2013a\bin\win64; (for 64 bit MATLAB)
(probably can skip the "PATH=" here as it doesn't seem to remain there,
otherwise this is straight from the MATLAB reference )
Under C/C++ General, add the following directory to the field ADDITIONAL
INCLUDE DIRECTORIES:
$MATLABROOT\extern\include
i.e.
c:\Program Files\MATLAB\R2019a\extern\include;
Put a semicolon at the end of every line that you enter that is a path. after
the .lib files in that section also.
Under C/C++ Precompiled Headers, select "Not Using Precompiled Headers".
(in release mode this was set to "yes")
Under Linker General, add the library directory to the field ADDITIONAL
LIBRARY DIRECTORIES:
(For 32-bit Windows)
$MATLABROOT\extern\lib\win32\microsoft
(For 64-bit Windows)
$MATLABROOT\extern\lib\win64\microsoft
i.e.
c:\Program Files\MATLAB\Rxxxxx\extern\lib\win(32|64)\microsoft;
Under Linker Input, add the following library names to the field marked
ADDITIONAL DEPENDENCIES:
(use this string in front of whatever else is in there)
libeng.lib;libmat.lib;libmx.lib;
I don't know if the order really matters, but the original reference listed
them in reverse alphabetical order. "I've heard it both ways".
Ok, now you're done changing the VS project property pages, save the changes
(as you've done all along by clicking "Apply" after each change) and click
Ok. The property pages window will close. At this point your code will build
but still won't call Matlab. Back-up the solution again.
Now change the DOS/WINDOWS ENVIRONMENT PATH STRING.
I would save the solution, close VS, back it up, make the PATH changes and
reopen VS and try to build your program and run it and have it work.
The PATH string must be changed so that the bin\win(32:64) directory is the
first instance related to Matlab on the path.
Go in the "advanced system settings" \ Environment
To do this, check the Windows system path by clicking on Start -> Right click
on Computer -> Properties -> Advanced System Settings -> Environment
variables -> System Variables -> Open "Path" for editing.
and modify the PATH variable as so:
Make sure that the following directory is in the PATH:
(For 32-bit Windows)
$MATLABROOT\bin\win32
(For 64-bit Windows)
$MATLABROOT\bin\win64
It does not have to be the first directory in the path, but it needs to be
the first MATLAB directory in the path
PATH=c:\;....;c:\Program Files\MATLAB\Rxxxxx\bin\win(32/64);
The matlab.exe is in \bin; you might want that on the path also just not
before the \bin\win64 entry...
Note: If the machine has more than one MATLAB installed, the directory for
the target platform must be ahead of any other MATLAB directory (for
instance, when compiling a 64-bit application, the directory in the MATLAB
64-bit installation must be the first one on the PATH).
Also make sure that your target install of
MATLAB is registered as a COM server:
https://www.mathworks.com/help/matlab/ref/regmatlabserver.html
For Matlab 2020a & later, try comserver('query') and comserver('register').
For 2019 & earlier use regmatlabserver() (run Matlab as administrator).
Build and execute the application.
So I include a simple app that should demonstrate the functionality:
#include "stdafx.h"
#include "engine.h"
#include
using namespace std;
int main()
{
Engine *eng;
eng=engOpen(""); // put a breakpoint here
cout << "...now you see it...\n"
engClose(eng); // put a breakpoint here
cout << "...now you don't!\n"
return 0;
}
I would like to disable the linker for a particular project configuration of a VS2013 C++ project. How can I do this?
I have tried to remove the output path, remove the <Link> parts of the project file, but this only results in error messages ("error : The OutputPath property is not set for project" / "error: The output paths do not match" etc.)
The reason is that this particular configuration does preprocessing to file so no object files are created, which always results in a linker error.
There is a compiler switch /c to "compile only". Unfortunately this is only available outside of Visual Studio. So you would need to build the project on the command line using cl.exe.
I am getting the error of :
error LNK1104: cannot open file 'ylmtr.obj' in visual studio 2013
In the properties of my project I made the following configurations:
Linker - Input - Additional Dependencies- ylmtr
V/C++ Directories - added to the directories of include, library, source their configurations from the program parser generator (used to create lexer to make a compiler)
https://msdn.microsoft.com/en-us/library/ts7eyw4s.aspx
To fix by checking the following possible causes:
Not enough disk space.
File does not exist.
When specifying libraries in a project's property pages dialog box, library names should be separated by spaces (and not commas).
Incorrect filename or path.
Invalid drive specification.
Insufficient file permissions.
Path for filename expands to more than 260 characters.
If the given file is named LNKn, which is a filename generated by the linker for a temporary file, the directory specified in the TMP environment variable may not exist, or more than one directory is specified for the TMP environment variable. (Only one directory path should be specified for the TMP environment variable.)
If the error message occurs for a library name, and you recently ported the .mak file from a previous Microsoft Visual C++ development system, the library may no longer be valid. Ensure that the library still exists in this circumstance.
Another program may have the file open and the linker cannot write to it.
Incorrect LIB environment variable. For information on how to update the LIB environment variable, see VC++ Directories, Projects, Options Dialog Box . Make sure any directories with libraries you need are listed here.
I'm just diving into VC++ after a number of years in other areas of programming. I am puzzled by the errors that come up when I go from a debug version to a release version. I'm probably doing something stupid here...
For example, this code works fine for debug compiles:
ofn.lpstrFile = (LPSTR)title;
However, if I go to release mode, I get an error and have to put in a W:
ofn.lpstrFile = (LPWSTR)title;
What am I doing wrong? This is not a MFC program, it's really just a very simple program where I read a file, take the information from it to eliminate certain parts of another file, and then write the final file to disc.
This is because you have different settings in the Debug and Release configuration. Your debug configuration is set to have the character set "Not set" while the Release configuration is using "Use Unicode character set".
To change the character set go to the project properties, select your configuration and from Configuration Properties > General > Character Set select the same for all your configurations.
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
This may cause your project to build incorrectly. To correct this, please
make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.