I'm new to C++ and CGAL, previously I worked mainly with C#.
I installed CGAL as described on https://www.cgal.org/download/windows.html and all steps finished successfully.
Then I looked to a CGAL 'Hello world' (https://doc.cgal.org/latest/Manual/Kernel_23_2points_and_segment_8cpp-example.html); here I had no problem also; all the code was compiled and run propertly.
But when I tried with more complex things I got a strange issue. For example I tried to compile Skeletonization (https://doc.cgal.org/latest/Surface_mesh_skeletonization/Surface_mesh_skeletonization_2simple_mcfskel_example_8cpp-example.html);
here I got a number of errors like these:
C2039 ''extract_mean_curvature_flow_skeleton'': is not a member of ''CGAL''
C2039 ''Matrix'': is not a member of ''CGAL::Default''
C2039 ''Vector'': is not a member of ''CGAL::Default''
As far as I understand it the #include lines processed without errors, all needed headers exist.
I tried to search the answer and found this: http://cgal-discuss.949826.n4.nabble.com/Problem-on-Surface-mesh-deformation-td4661042.html
Unfortunately I don't be sure my case is similar and I don't know what exactly do the line #define CGAL_EIGEN3_ENABLED as recommended there.
In any case I tried to add it and got the same errors as previous if this #define inserted after #include ; in different case arise a lot of errors like this:
LNK2019 unresolved external symbol __imp___gmpq_add referenced in function "class CGAL::Gmpq __cdecl CGAL::operator+(class CGAL::Gmpq const &,class CGAL::Gmpq const &)" (??HCGAL##YA?AVGmpq#0#AEBV10#0#Z)
I work with VS 2017, in Additional library directories I added:
$(CGAL_DIR)/lib/Debug;$(CGAL_DIR)/lib
in Additional include directories:
$(CGAL_ROOT)\include;$(CGAL_ROOT)\auxiliary\gmp\include;
$(CGAL_DIR)\include;$(BOOST_INCLUDEDIR)
maybe some needed libraries or include directories are missing here?
All the components (CGAL, boost, QT) installed in 64 bits versions as well as test project.
UPD: The question is solved!
The answer was extremely simple (please note I'm new in C++):
1. I loaded and unzip EIGEN (it need not to install); for convenience I create also EIGEN_DIR variable;
2. I added to Additional Include Directories: $(EIGEN_DIR);
3. I added before #include statements #define CGAL_EIGEN3_ENABLED;
4. I added to Additional Dependencies such libs:
$(CGAL_ROOT)\auxiliary\gmp\lib\libmpfr-4.lib
$(CGAL_ROOT)\auxiliary\gmp\lib\libgmp-10.lib
and it start to work!
Related
I have an issue since 2days about an LNK2005 & LNK1169 error on MSVC 2015 (Qt 5.12.6)
My error is:
Core.lib(Core.dll) : error LNK2005: "public: __cdecl QMap<int,double>::~QMap<int,double>(void)" (??1?$QMap#HN##QEAA#XZ) already defined in xxx.obj
I have the error when i'm trying to compile a library (named AAA)
The library AAA use Core.dll and both use a 2nd lib named Common.dll. The type QMap<int,double> is used in each libraries.
When i'm looking xxx.obj (located in AAA), the only one usage i have of QMap<int,double>, is when i'm use a function that return a QMap and located in Core.dll
I have lot of function defined in Core and used in AAA but i never seen this error before.
I have check multiple things: trying to change the QMap with QVector, same type of error.
I don't have any "include cpp file"
I don't have the error when i'm using Clang or GCC to compile the project.
I don't have the error if i'm using a QMap<int,double>*, but i don't want to
I think it's an error related to the qmap template but i'm not sure
Do you have an idea? Thanks
Ps: i'v change the name of third lib (AAA) cause this is a code i use for my work and cannot share lot of things about it
So, i have fix my pb by replacing each usage of QMap<int, double> by another object located in a third library.
I have seen multiple definition of QMap<int, double> in the dlls by using Dependency Walker and that why the code counln't compile.
But I don't know if is a problem with the compiler (MSVC2015) or with my code.
I have used these website to help me:
https://forum.qt.io/topic/43408/error-lnk2005-when-deriving-from-qvariantmap
http://web.archive.org/web/20090323151858/https://mareq.com/2008/10/exporting-non-template-class-inherited.html
So, I have problem, when try to use any of static members of SFML Library like sf::RenderState::Default or sf::Color::Blue.
error LNK2001: unresolved external symbol "public: static class sf::RenderStates const sf::RenderStates::Default" (?Default#RenderStates#sf##2V12#B)
But when I comment lines, I have access to sf::window (it be created, but can't draw anything, because sf::Drawble has sf::RenderState::Default as standart argument).
I checked everything including linker and compiler in Solution properties in Visual Studio (I have VS19).
P.S. I use the latest version of SFML (2.5.1) and Visual C++20.
Thanks for your help.
The troubleshooting steps I would undertake in this situation go from easiest to the inverse of that.
If I check the declaration of sf::RenderState::Default, can it be found?
If I create a new project with just this feature used, does the error persist?
If I redo my linking and directory searches, is the problem fixed?
Do I have a version compatible with my compiler?
Furthermore, the amount of information you've given about your environment is not enough to speculate on what the issue could be. It might be helpful to post your version of SFML, your compiler (and kind), what your project is like (shorthand.)
SFML can be compiled from source if necessary. Sometimes, using an incompatible version on accident will not show any issues on many basic things until you run into weird errors.
See this document on compiling SFML from source:
https://www.sfml-dev.org/tutorials/2.5/compile-with-cmake.php
So, thanks for AlixianaBritmonkey, I managed with this problem. I just create new project and moved every file. I don't know why problem occured before, but my solution helped.
I am trying to use BoostPython to write a program in C++.
My presettings are:
a. Win32 Console Application.
b. Property->C/C++->General->Additional Include Directories->C:\Python27\include;C:\Program Files\boost\boost_1_54_0;
c. Property->Linker->General->Additional Library Directions->C:\Python27\libs;
d. Microsoft Visual Studio 2012 Express Version + Python 27 + Boost 1.54
And my code is like follows:
#include <boost/python.hpp>
using namespace boost::python;
int main( int argc, char ** argv )
{
return 0;
}
As you can see, this code is with an empty main function. And I got an error message
error LNK1104: cannot open file 'boost_python-vc110-mt-gd-1_54.lib'
I checked the installation of boost ('bootstrap.bat'+'bjam.exe'), and I've searched within the folder where boost library installed for 'boost_python-vc110-mt-gd-1_54.lib', but found nothing.
I looked for some similar posts, unlike my problem, the lib file they missed was with a prefix 'lib'. On the other hand, I found this post is very similar to mine. But I found the OP made a mistake when he/her solve his/hers problem. That is, Boost is compatible with python 2.2 and its newer versions. And the rest of his answer is not helpful to me.
I guess this problem could because either I've done something wrong during installation, or I was wrong when I link the libs to my application.
Can anyone help me out of this? A detailed solution will be great. Many thanks. :)
==============================================================
EDIT:
I've reinstalled the Boost with a prebuilt binary file. Now I can link to the lib file the compiler asked for. However, new problems are raised. Now I have two new errors:
error LNK2001: unresolved external symbol __imp___Py_NoneStruct
error LNK1120: 1 unresolved externals
When I comment out the line #include <boost/python.hpp>, the above errors are gone.
I really cannot figure out the reason. Can anyone help me with this? Many thanks.
You've added the C:\Python27\libs folder to you linker settings, but that doesn't have the boost files.
You need to run boost's bjam to generate the boost library files. Lots of boost is header only, but there are some libraries which you will need to build.
When you have done that you need to add the directory to
"Property->Linker->General->Additional Library Directories"
I've found out the error is raised because the Boost library was not properly installed in my computer. Actually, the key is bjam, and it must be run to build all these necessary libraries.
I would suggest anyone else that encounter with this problem, if you don't know how to run a bjam properly, go to search for a prebuilt binary file of Boost. That could save you a lot of time.
I'm getting the following error when I compile my program which links to libtorrent.lib. I've tried compiling libtorrent with different settings, I've tried enabling/disabling DHT, deprecated functions, etc.
error LNK2019: unresolved external symbol "void __cdecl
libtorrent::rel_performancetimer_pools_nolog_resolvecountries_deprecated_dht_ext_(void)"
Is anyone here familiar with libtorrent, or can anyone provide any advice for getting rid of this error? I don't see any other libraries that I need to link to.
Thanks in advance.
I've spent two days on it and finally I've found an issue.
Name of this function "void rel_performancetimer_pools_nolog_resolvecountries_deprecated_dht_ext_" consists of the parts, that describes your current preferences. For example, dht_ means you're using DHT, and nolog_ means you're switched off TORRENT_LOGGING directive.
The problem is: this settings works only with Release configuration! rel_ means release_. On the libtorrent 0.16.11 this problem still not solved.
I've put this text in file build_config.hpp on the line 40:
#ifdef _DEBUG
#define TORRENT_DEBUG
#endif
This is the way to compile my project with libtorrent in release and debug configurations, without making any corrections.
Arvid, please, include this 3 lines to your next version of libtorrent.
Appreciated,
Ilya from Russia.
The problem was that my definitions in my project were inconsistent with the configuration/definitions in the libtorrent compilation, so some macros were calling a function that doesn't exist.
Hello industry veterans,
I am a junior in college embarking on my first summer programming internship, and I am in way over my head. The company I'm working for has purchased a colossal application from another company that has slowly been expanding and modifying it since the early 90's. The solution contains over 200,000 lines of code which are spread across more than 300 files. The entire solution has purportedly been written to ANSI-C++ standards. The code is almost entirely undocumented, and most of it looks like hieroglyphs to me. Ultimately, my job is to port this code to embedded Linux. At the moment, my job is simply to get it compiling using Visual Studio 2008 on Windows XP.
Today, I'm running into linker errors such as this one:
libcmtd.lib(sprintf.obj) : error LNK2005: _sprintf already defined in msvcrtd.lib(MSVCR90D.dll)
My understanding is that this often happens when different projects within a solution are compiled using different runtime libraries. There are 6 projects in my solution. 4 of them were set to compile using the multi-threaded debug DLL runtime library (/MDd), one of them was set to compile using the multi-threaded debug library (/MTd), and one of them was set to compile using the multi-threaded dll runtime library (/MD). The first thing I tried after receiving this error message was to change the /MTd and /MD switches to /MDd so that everything would have compiled with the same runtime libraries. Unfortunately, this led to the following error in afx.h:
fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
After some digging around, I discovered that it had already told me what I needed to do. I went ahead and changed the "Use of MFC" option under Project Properties->Configuration Properties->General to "Use MFC in a Shared DLL". At this point I started receiving dozens of unresolved external errors such as these:
dataPropertySheet.obj : error LNK2019: unresolved external symbol "public: __thiscall CResizableSheet::CResizableSheet(unsigned short const *,class CWnd *,unsigned int)" (??0CResizableSheet##QAE#PBGPAVCWnd##I#Z) referenced in function "public: __thiscall CdataPropertySheet::CdataPropertySheet(unsigned short const *,class CWnd *,unsigned int)" (??0CdataPropertySheet##QAE#PBGPAVCWnd##I#Z)
ResizableLib.lib(ResizablePage.obj) : error LNK2001: unresolved external symbol "public: virtual int __thiscall CWnd::Create(char const *,char const *,unsigned long,struct tagRECT const &,class CWnd *,unsigned int,struct CCreateContext *)" (?Create#CWnd##UAEHPBD0KABUtagRECT##PAV1#IPAUCCreateContext###Z)
After reading through the MSDN pages on LNK2001 and LNK2019, I've realized I have no idea what's going on. These are not the sort of issues they've taught us how to deal with in school. I know my data structures, and that's about it. How I ended up where I am now is beyond me!
From my limited knowledge, it seems that the various debug and release versions of these modules are all tangled up in a web of preprocessor directives and #includes. There are a number of nested #ifdef checks and #define statements done in nearly every header and source file throughout the solution for environment variables, file names, macros, and possibly more. By making even small changes to my compiler settings, I seem to be redirecting large parts of the program to different libraries which have very different function definitions. This is my vague conceptual understanding of what's going on.
I feel as though I'm going to need a better understanding of how this code works before I stand any chance of troubleshooting these compiler errors. To that end, I've been trying to step through many of the files line by line to see where they lead, what objects and variables are in scope, and so on. Unfortunately, this doesn't get me very far, because every call to an external function is ambiguous, and I have no way of seeing through the preprocessor mess to know which version of any given function is supposed to be called.
I was looking around for magic solutions to map out the program and try to make sense of it. I tried one called Doxygen, but either I don't know how to use it properly or it's getting just as confused by the preprocessor stuff as I am.
My question is this:
What are my remaining options?
At this point it's a toss up between:
a.) Switch majors
b.) Jump off a bridge
Neither of these choices are going to help me better understand this code base and get it compiling. Does anybody have any better ideas? Similar experiences? Sage wisdom to share?
Thanks a ton,
-Alex
It appears you're using the CResizableSheet and CResizeablePage from CodeProject. If you're using the compiled static lib from that page, you could try downloading the source and compiling that with the matching /MDd setting and using the .lib it outputs in the linker input section of your project. I'd also suggest doing a clean all (go to build->batch build->select all then click clean) and then try building again to make sure everything is up to date.
I hear nursing is a great program ...
At the risk of being pedantic, what you are fighting with are linker errors, not compiler errors. My basic approach to this would be to create a new solution, and start adding projects one at a time, getting each one to build in turn.
I would also seriously consider trying to standardize the settings of each project as much as possible. The easiest way to do this is to create empty projects in your new solution, and copy the existing code into them.
To start with you should assume the following settings (related to MFC):
Debug: Use MFC in a shared DLL, /MDd
Release: Use MFC in a shared DLL, /MD
MDd and MD are the same mode, but one links against debug libraries with extra information for debugging.
Then all you can do is work on one project at a time. Note that if you create a new solution as suggested, you'll need to rebuild the dependency tree between projects. (Right click on a project and choose 'Dependencies', you'll see what I mean.)
When you run into problems doing this, you should make friends with a senior developer at your workplace =).
Compile everything with the same runtime libraries. End of story.