I am pretty experienced writing my own code, but not in C++. I am used to adding .NET assembly references, and I want to get into using C++.
I downloaded a VC++ 6 project presenting a graph algorithm, opened it in Visual Studio 2010 Ultimate and downloaded the required libraries (LEDA .NET assemblies) however, they came with both DLLs and LIB so I thought I would have no problems with the .NET and C++ connection. Also, the LEDA project comes with C++ style .header files, and static libraries, yet frustration persists.
I put my LEDA header files in a directory visible to the project, since I can "Go to definition" of all the custom LEDA data types and see where they are defined in the LEDA include files.
But, I can not compile/link these data types in. The VS finds their very existence repulsive, and refuses to acknowledge they could possibly be found in leda.lib.
Steps I have already taken:
Added additional /LIBPATH path under Properties ->Linker->General
Added explicit lib references under Properties->Linker->Input
Added all the paths containing LEDA header files and libraries to every path location I can find, like include path, reference path, library path.
Copied the DLLs and LIBs to the release folder as well as the base folder of the project.
Added a #pragma comment( lib, "leda" )
Still no joy.
It's quite bad since none of the custom typedefs are recognised the errors balloon to 646 errors.
If anyone is kind enough to offer assistance, thank you.
I can't guarantee this will work but try the following steps (therefore using it's default predefined paths instead of setting your own ones) :
1) Copy *.dll into Windows/System32 or / and (there is some confusion about x64 and x32 default checking in my head :)) Windows/SysWOW64.
2) Copy *.h files into x:\PathToVC2010\include\
3) Copy *.lib files into x:\PathToVC2010\lib\
Related
I realise this is a newb question but I've been racking my brains for hours.
So I want to use the STK (Synthesis Toolkit) to generate sine waves etc. I've downloaded the source files from https://ccrma.stanford.edu/software/stk/download.html
I unzipped the tar.gz using 7zip.
I opened up the demo.cpp project file (under /projects/demo/demo.cpp) and whenever I try to compile it, I receive lots of errors, all starting with "undefined reference to"
I have set the compiler search directory to include the root folder of the stk kit (unzipped as "stk-4.5.0"). My understanding is that I also have to find file for the linker, that is of the type .lib? Is that correct? I haven't been able to find a .lib file to link to.
I feel like this is a simple fix - what am I missing?
You've downloaded a source , not the compiled library which might be used by linker (.lib file) There are three solutions:
1. Compile whole src folder of your download ( see instructions on their website). Frankly, I've tried to do that recently but failed, especially under Windows although I don't have any experience in this so you can try yourself.
2. Use precompiled library available in some Linux repositories. I had success with Slacko Puppy linux. Package simply adds libstk.a (linux static library) to /usr/lib and stk headers to /usr/include/stk (notice you have to add exactly that path to compiler, since /usr/lib is not enough). This gave me best results.
3. If you use only several classes, you can copy their .cpp files directly to your project source folder. Remember to add parent classes, too (see STK site -> Classes). Again I recommend that you give the compiler path to include folder you've unzipped, but copying only selected headers should also work.
I've found this article helpful (see also A1): http://www.learncpp.com/cpp-tutorial/a3-using-libraries-with-codeblocks/
Hope I've helped
Greetings, what I'm trying to do is to port an existing Windows application to Linux using CMake with CMakeLists, which I generated with the vcproj2cmake Script (https://github.com/sixman9/vcproj2cmake).
With the CMakeLists.txt and CMake I was able to successfully port a VS 2005 project to VS 2010. Now I try to port the same VS 2005 project to Linux, so that I can edit it with KDevelope.
The project itself is small and I think it would be easier to just create a new project and copy all relevant files (if that would work), the problem is, that it's not only one project but many, hence I was looking for a way to port a project in an as simple as possible way.
In Linux I was able to create a CMakeLists.txt using the vcproj2cmake script. The next step would be creating a KDevelope project using CMake. And this is where I'm stuck.
Everytime I try to run CMake I get the following error:
CMake Error at CMakeLists.txt: 196 (set_property) :
set_property could not find TARGET Test_Project. Perhaps it has not yet been
created.
Test_Project: installing /root/Desktop/Test_Project/vs8/CMakeLists. txt rebuilder (watching /root/Desktop/Test_Project/vs8/Test_Project. vcproj)
Configuring incomplete, errors occurred!
See also “/root/Desktop/Test_Project/vs8/CMakeFiles/CMakeOutput.log”.
I searched for a solution or an approach for quite a time now, but the only results that I get are project-specific, or at least I think they are.
Content of the CMakeLists.txt from line 196:
set_property(TARGET Test_Project PROPERTY PROJECT_LABEL "Test_Project")
v2c_rebuild_on_update(Test_Project "${CMAKE_CURRENT_SOURCE_DIR}/Test_Project.vcproj" ${CMAKE_CURRENT_LIST_FILE} "vcproj2cmake.rb" ".")
include(${V2C_HOOK_POST} OPTIONAL)
Perhaps there are more efficient ways to port many projects form Windows to Linux, I'm open for any suggestion.
It is a bit difficult to help without having your project - since you are using a third party tool to convert a VC project you should ask the author of that tool. :D
If you have many projects which you are going to maintain, I suggest that you select one where you can create a cross platform (Windows/Linux) CMake config for which you can reuse for other projects.
Most of the config should be the same for all platforms you are building for - the difference should be which generator is used and what libraries to link in the final executable (if you are building one that is). The generator is specified when running cmake.
In my opinion you should try an out of source build with the following structure:
/$COMMON_DIR/CMakeLists.txt
/CMakeLists.txt
/src/
/build/
/build/vcX
/build/generate_vcX.bat
/build/linux
/build/generate_linux.sh
$COMMON_DIR should contain the CMake code you expect to be common for all you projects - like a function to create a static library for a module which searches for files in /src and another function which can be used to add an executable for certain platform.
The CMakeLists.txt in the root of your project (repository, I assume) should call the functions defined in $COMMON_DIR and possibly add some project specific defines or link flags.
I am banging my head against a wall here.
All i want is to link a static .lib file in a cpp windows forms application! So, i have an include folder in my project folder that holds header files for that .lib (lib is Yaml-cpp if someone wonders). And i have a lib folder that has the .lib files for that library.
I tested it on a blank project
1.I make a new windows forms project in VS2008, in C++.
2.I go to project properties - c/c++ general and additional include directories that have yaml-cpp header files
3.I go to linker and add path to my lib directory
4.I go to linker - input and add my .lib file
5.I check linker command line and it contains my .lib file so it must be all set.
6.Then i write the sample code in an onbutton function body (which appears in form1.h fie).
Sample code is from here http://code.google.com/p/yaml-cpp/wiki/HowToParseADocument and its just as simple as:
#include <fstream>
#include "yaml.h"
and then:
std::ifstream fin("test.yaml");
YAML::Parser parser(fin);
YAML::Node doc;
while(parser.GetNextDocument(doc)) {
//do nothing yet
}
7.And then i compile and have 10 "unresolved externals".
I have looked into another project that uses same library, and it has exactly same directory structure, same name of .lib added in linker - input - additional dependencies, same .lib and .h files. And it works for that project- but it doesnt work for me.
What in the world is wrong?
EDIT: I tried making new windows 32 console application and it worked correctly. I then tried to make another fresh windows forms application and it failed.
It is confirmed now. Same steps for linking a library work in console application and fail in windows forms application. WHY?
What you've done seems correct from your explanation, let's do some blind troubleshooting.
Try giving full path instead of relative path for library path and additional include directories. (but as u said that the file is getting read, that should be the problem.)
If you are using a copy of original libyaml-cppmdd.lib and its include file, check whether the header file that gets included is of the same version as the lib.
Check whether there are any functions in any part of the code that is having a declaration but no definition.
Check whether you're accessing any private functions from the library.
Please read this Microsoft article on Troubleshooting UnResolved External Symbol error.
Hope it helps!
I am trying to upgrade an old solution to use VS2010 (VC100).
I have it setup so that stdafx.cpp will create a precompiled header stdafx.pch from stdafx.h. Then all the other .cpp files that include stdafx.h are instructed to use the precompiled header.
These posts helped me get this far:
Visual C++ Precompiled Headers errors
Precompiled Headers
Now all is fine when I build in release mode. However when I try and build in debug mode I get a whole heap of errors saying:
Error 1 error C2859: [removed]\debug\vc100.idb is not the idb file that was used when this precompiled header was created, recreate the precompiled header.
I believe that this .idb file is an intermediate debug file created by Visual Studio.
Why am I getting this error? In other words why did it not use this .idb file when it created the precompiled header?
I'm not sure what further information you need to be able to give me answer so just ask if there is more information that I need to provide.
Thanks to a colleague I got the answer.
The problem was that stdafx.cpp had Debug Information Format set to Program Database (/Zi) where as all the other files had it set to Program Database for Edit and Continue (/ZI).
Changing them all to Program Database for Edit and Continue (/ZI) and doing a full rebuild solved the problem.
I guess the upgrade screwed it up somehow.
I've hit this error with VS2005 when compiling a project where the $(ProjectName) is different from the actual output file of the project (i.e. Linker > Output File isn't set to the default of $(OutDir)\$(ProjectName).exe but to something else, e.g. $(OutDir)\$(ProjectName)-custom_postfix.exe)
In this case, and apparently only when doing a Rebuild-Project-Only, the vc80.pdb seems to be looked up wrongly.
What helped me was to additionally set C/C++ > Output Files > Progam Database File Name to $(IntDir)\$(TargetName).pdb. (Instead of the default vc80.pdb)
select Disable for the Debug Information Format in the Properties page for stdafx.cpp, then go back and select Inherit from parent worked for me.
Maybe your release build is configured to write file [removed]\debug\vc100.idb instead of [removed]\release\vc100.idb? Check the project settings for your release build and make sure there are no hardcoded path components like that.
Here's how I just fixed this error on Visual Studio 2008:
Background:
I have a solution that contains two sub-projects.
One project compiles the .dll;
One project compiles the .exe that used this .dll;
The .exe project is dependent on the .dll project;
Problem: I had both of the projects dumping their output into the same directory, i.e. both "OutPutDirectory" and "IntermediateDirectory" set to write to a common directory in the root, "../$(ConfigurationName)".
Cause of error:
The cause of this error was that when the .dll project was compiled, it created the precompiled header (*.pch) in the same directory as the .exe directory, and when the .exe project was compiled, it promptly overwrote the precompiled header (*.pch) from the .dll project.
The fix:
To fix this, I changed the "IntermediateDirectory" for both sub-projects to "temp", so that the temporary files (including the precompiled header files) were written to different directories.
I don't know if it's possible to do this, but I would like the /NODEFAULTLIB to be applied to a static library project.
I have many application projects (A.exe, B.dll, C.dll) that use a common static library D.lib.
This library has a lot of code and also has other .lib dependencies as well. One of them is the openssl library, which seems to have been built for win32 against the Release version of the CRT (i don't have the original project/sources).
So far, to avoid the mixing of the Release/Debug versions of CRT, I have to put the /NODEFAULTLIB:msvcrt.lib linker directive in all leaf projects (A.exe, B.dll). This works but I think it's not the ideal way of dealing with that issue.
I tried to put this property in D.lib project, but it has no effect.
Is there a way to force msvc++ to ignore the msvcrt.lib dependency from the 3rd party library?
A .lib does not have any linker settings because you don't link it, you link to it. A .lib is just an archive of .obj files, sort of like an uncompressed .zip file - that's why you have to put the setting on all projects that link to it.
If you're using VS2005+ you could use property sheets so that you only have to put the setting in one place and then use that property sheet in all projects.
However, OpenSSL is just that - Open Source, so you should be able to get the source for the version you are using and build it again (and add it to your version control system of course). I thought OpenSSL could be built as a DLL or LIB, which would solve your problem as the DLL would not interfere with the linking of your code.
Failing that, you always have the option of slitting your functionality out into a separate DLL so that you only have issues with one project.
To prevent your distributed static link library from depending on a specific MSVC runtime library you need to set this compiler option (in Visual Studio 2010 it looks like):
Configuration Properties -> C/C++ -> Advanced -> Omit Default Library Name = Yes (/ZI)
Now your users can link to your release built static lib from their debug build and not try to link to the incorrect runtime library causing problems, as well as linkers warnings.
Note that may cause link errors if your library actually depends on a specific runtime library or its behavior, and compatible components are not provided in some other way.
My understanding is that if library LIB in linked statically into a DLL, the DLL contains already all relevant code from LIB. Therefore, this coupling cannot be removed. This is just based on my understanding of statical linking, not on experiments.