I downloaded OpenCV 3.0.0-rc1 and build it using CMAKE-gui 3.2.2 using VS2012 Win64 compiler. Binaries and libraries got generated and I set it up with Qt 64 bit. All programs are working fine except when I try to use the feature cv::LineSegmentDetector it shows a compile error in private.hpp file. The error says
unexpected end-of-line
My code is as follows
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgcodecs/imgcodecs.hpp>
#include <opencv2/features2d/features2d.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include <opencv2/core/private.hpp>
#include <opencv2/core/utility.hpp>
using namespace std;
int main()
{
cv::Mat image = cv::imread("C:\\Users\\IMAGE\\Desktop\\PROJ\\SAMPLE.png");
cv::imshow("TEST",image);
cv::waitKey();
cv::LineSegmentDetector lsd;
return 0;
}
And on following the error I found the 2nd line of the following part of the code in private.hpp as error highlighted.
#ifdef HAVE_EIGEN
# if defined __GNUC__ && defined __APPLE__
# pragma GCC diagnostic ignored "-Wshadow"
# endif
# include <Eigen/Core>
# include "opencv2/core/eigen.hpp"
#endif
# if defined __GNUC__ && defined __APPLE__
Please let me know if I am doing some implementation mistake or some changes in the private.hpp can fix this error. I am using windows 8 64 bit.
oh, never try to use something, that is called "private", i guess...
#include <opencv2/opencv.hpp> // includes all others
#include <opencv2/core/utility.hpp> // getTickCount, etc.
int main()
{
// LineSegmentDetector is an abstract class, you can't create an
// instance on the stack, but need to use Ptr and factory:
cv::Ptr<cv::LineSegmentDetector> lsd = cv::createLineSegmentDetector();
return 0;
}
Related
I'm writing a project in Vulkan and it compiles and runs fine. The code is the same as it always was, but after some software updates (Steam, Visual Studio, etc.) an error has been popping up.
I mention steam as that was causing a separate runtime error. The same error as here: https://www.reddit.com/r/vulkan/comments/8ybq6f/need_some_help_debugging/e29qptx/
Anyway, the line:
const std::vector<const char*> validationLayers = { "VK_LAYER_LUNARG_standard_validation" };
and ones like that using std::vector and std::array give me the error: Ambiguous symbol 'const std::vector<const char*>'
My includes and defines are as follows:
#define GLFW_INCLUDE_VULKAN
#define GLM_FORCE_RADIANS
#define STB_IMAGE_IMPLEMENTATION
#include <glfw3.h>
#include <glm.hpp>
#include <gtc/matrix_transform.hpp>
#include <stb/stb_image.h>
#include <iostream>
#include <stdexcept>
#include <functional>
#include <vector>
#include <set>
#include <algorithm>
#include <fstream>
#include <string>
#include <array>
#include <chrono>
#ifdef NDEBUG
const bool enableValidationLayers = false;
#else
const bool enableValidationLayers = true;
#endif
So if there's a way to suppress this particular error highlighting, or if there is a genuine conflict, I'd love to know where it is / how to do it.
Like I say, it still runs fine, but it is annoying to look at my scroll bar and see a bunch of red markers that would normally indicate my program not compiling.
This turned out to be an issue with the version of ReSharper I was using. It is also reported here: https://resharper-support.jetbrains.com/hc/en-us/community/posts/360000430159-Intellisense-issue-with-C-17-standard?flash_digest=bbcceaf4d5a9c12c634a59aba32fc2143a325734
The solution is to turn it off or upgrade to R++ 2018.2
This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Problems importing libraries to my c++ project, how to fix this?
(2 answers)
Closed 4 years ago.
I am working with OpenSSL to try and get the SHA512 Hash function to work. When I am writing the code, Visual Studio's intellisense finds the function SHA512as well as all of the parameters that are included with it, but when I go to build the project, I get the error, "unresolved external symbol SHA512 referenced in function main." Here is what I have so far, it's based on a small example here.
stdafx.h
// stdafx.h : include file for standard system include files,
// or project specific include files that are used frequently, but
// are changed infrequently
//
#pragma once
#include "targetver.h"
#include <stdio.h>
#include <tchar.h>
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
#define _AFX_NO_MFC_CONTROLS_IN_DIALOGS // remove support for MFC controls in dialogs
#ifndef VC_EXTRALEAN
#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
#endif
#include <afx.h>
#include <afxwin.h> // MFC core and standard components
#include <afxext.h> // MFC extensions
#ifndef _AFX_NO_OLE_SUPPORT
#include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls
#endif
#ifndef _AFX_NO_AFXCMN_SUPPORT
#include <afxcmn.h> // MFC support for Windows Common Controls
#endif // _AFX_NO_AFXCMN_SUPPORT
#include <iostream>
// TODO: reference additional headers your program requires here
#include <openssl/sha.h>
test.cpp
#include "stdafx.h"
#include <stdio.h>
#include <string.h>
int main() {
unsigned char digest[SHA512_DIGEST_LENGTH];
char string[] = "hello world";
SHA512((unsigned char*)&string, strlen(string), (unsigned char*)&digest);
char mdString[SHA512_DIGEST_LENGTH * 2 + 1];
for (int i = 0; i < SHA512_DIGEST_LENGTH; i++)
sprintf(&mdString[i * 2], "%02x", (unsigned int)digest[i]);
printf("SHA512 digest: %s\n", mdString);
return 0;
}
I have even checked and confirmed that SHA512 is in the sha.h file that is included in the stdafx.h file as well.
I'm using Crypto++ to encrypt files in C++. And I'm using the code below.
It doesn't contain the headers files so I added my own :
#include <iostream>
#include <string>
#include <vector>
#include <algorithm>
#include <fstream>
#include <cryptopp/cryptlib.h>
#include <cryptopp/sha.h>
#include <cryptopp/secblock.h>
#include <cryptopp/files.h>
#include <cryptopp/queue.h>
#include <cryptopp/hex.h>
#include <cryptopp/base64.h>
#include <cryptopp/filters.h>
#include <cryptopp/osrng.h>
#include <cryptopp/integer.h>
#include <cryptopp/dh.h>
#include <cryptopp/sha.h>
#include <cryptopp/modes.h>
#include <cryptopp/eax.h>
#include <cryptopp/tea.h>
#include <cryptopp/blowfish.h>
#include <cryptopp/pssr.h>
#include <cryptopp/rsa.h>
#include <cryptopp/nbtheory.h>
#include <cryptopp/eccrypto.h>
#include <cryptopp/oids.h>
#include <cryptopp/modes.h>
#include <cryptopp/gzip.h>
#include <cryptopp/blowfish.h>
#include <cryptopp/rsa.h>
#include <cryptopp/rng.h>
#include <cryptopp/cryptlib.h>
#include <cryptopp/filters.h>
#include <cryptopp/rdrand.h>
using namespace std;
using namespace CryptoPP;
But unfortunately the code doesn't work
Saying that the GlobalRNG is not declared !
error: ‘GlobalRNG’ was not declared in this scope
I googled and kept looking for a solution for 2 days i found that it's a bug and fixed but i'm having the latest version : 5.6.3 !
So i really don't know why this error is showing !
In the version 5.6.3 GlobalRNG is defined in the file validate.h, as:
// Functions that need a RNG; uses AES inf CFB mode with Seed.
CryptoPP::RandomNumberGenerator & GlobalRNG();
Just add this inclusion:
#include <cryptopp/validate.h>
to solve definition problem.
GloablaRNG is part of testing and bench-marking. It should not be part of the library proper (i.e., libcryptopp.a or libcryptopp.so). If your programs are complaining about a missing GloablaRNG, then the library was cross-contaminated with some of the testing and bench-marking gear.
These are the files used for testing and bench-marking. They should not be included in your build of the library or your project:
validate.h
bench.h
test.cpp
bench1.cpp, bench2.cpp
validat0.cpp, validat1.cpp, validat2.cpp, validat3.cpp
datatest.cpp, regtest.cpp, fipsalgt.cpp, dlltest.cpp
You are free to use a function called GlobalRNG(). Here's how its used in the library's test and bench-marking gear. But you might consider using an AutoSeededRandomPool instead. The AutoSeededRandomPool is a PGP-style generator, and its seeded from /dev/urandom, /dev/srandom, /dev/random or the Windows entropy pool.
Declaration in validate.h
NAMESPACE_BEGIN(CryptoPP)
NAMESPACE_BEGIN(Test)
CryptoPP::RandomNumberGenerator & GlobalRNG();
NAMESPACE_END // Test
NAMESPACE_END // CryptoPP
Definition in test.cpp
NAMESPACE_BEGIN(CryptoPP)
NAMESPACE_BEGIN(Test)
ANONYMOUS_NAMESPACE_BEGIN
OFB_Mode<AES>::Encryption s_globalRNG;
NAMESPACE_END
RandomNumberGenerator & GlobalRNG()
{
return dynamic_cast<RandomNumberGenerator&>(s_globalRNG);
}
NAMESPACE_END // Test
NAMESPACE_END // CryptoPP
Seeding in test.cpp
// Don't do this in production because it creates a deterministic generator
OFB_Mode<AES>::Encryption& aesg = dynamic_cast<OFB_Mode<AES>::Encryption&>(Test::GlobalRNG());
aesg.SetKeyWithIV((byte *)seed.data(), 16, (byte *)seed.data());
A lot of folks have had this problem over the years. At Crypto++ 6.0, we moved GlobalRNG() into the Test namespace. Test is a new namespace, and we hope Test::GlobalRNG() will provide the signals that something is amiss in your library build or project configuration.
Also see Issue 379, Add Test namespace within CryptoPP namespace and Commit 73836e58a5f5c11c.
I have built the LLVM using CMake using VS 2012 in keeping with documentation. I am trying to build a toy compiler with flex, bison and LLVM. The final stage of my compiler my main class looks like this:
#include <iostream>
#include "codegen.h"
#include "node.h"
#include "llvm/Target/Targetmachine.h"
using namespace std;
extern int yyparse();
extern NBlock* programBlock;
void createCoreFunctions(CodeGenContext& context);
int main(int argc, char **argv)
{
yyparse();
std::cout << programBlock << endl;
InitializeNativeTarget();
CodeGenContext context;
createCoreFunctions(context);
context.generateCode(*programBlock);
context.runCode();
return 0;
}
As stated in my previous post LLVM 3.4 linker errors in VS 2012. To workaround the solution I manually added the x86 files I was missing (taking clue from the errors). I ended up adding the following to the main:
#include "llvm-3.4/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.h"
#include "llvm-3.4/lib/Target/X86/InstPrinter/X86ATTInstPrinter.h"
#include "llvm-3.4/lib/Target/X86/InstPrinter/X86IntelInstPrinter.h"
#include "X86MCAsmInfo.h"
#include "llvm/ADT/Triple.h"
#include "llvm/MC/MCCodeGenInfo.h"
#include "llvm/MC/MCInstrAnalysis.h"
#include "llvm/MC/MCInstrInfo.h"
#include "llvm/MC/MCRegisterInfo.h"
#include "llvm/MC/MCStreamer.h"
#include "llvm/MC/MCSubtargetInfo.h"
#include "llvm/MC/MachineLocation.h"
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/Host.h"
#include "llvm/Support/TargetRegistry.h"
#include "X86GenRegisterInfo.inc"
#include "X86GenInstrInfo.inc"
#include "X86GenSubtargetInfo.inc"
But I noticed that the following are missing from my system:
"X86MCAsmInfo.h"
"X86GenRegisterInfo.inc"
"X86GenInstrInfo.inc"
"X86GenSubtargetInfo.inc"
I looked through the online documentation but I am a beginner on the topic, most of it did not make too much sense to me. I would appreciate if someone could guide me or point me to the right tutorial which gives me a better understanding of what I am doing wrong here.
I am trying to implement a test project using the Point Cloud Library and OpenCV with multiple files. When I try to compile, I get the "already defined error" message. Probably I'm doing something stupid that cannot realize for some reason - I tried out a couple of solutions found here, none of them seemed to be help in my case.
What I have:
A libs.h file, where I load the lib files (in Project properties, I only set up the .lib paths and load the libs "by hand", like the headers):
#pragma once
#ifndef PCLTEST_LIBS
#define PCLTEST_LIBS
#ifdef _DEBUG
#pragma comment(lib, "pcl_apps-gd.lib")
#pragma comment(lib, "pcl_common-gd.lib")
// a bunch of other debug libs
#else
// the release libs
#endif
#endif
A main file from which I basically deleted everything at this point to debug:
// load the libs
#ifndef PCLTEST_LIBS
#include "libs.h"
#endif
// pcltest includes
// if only this first one is #included, everything is OK
#include "opencvOperations.h"
// #including this one causes the error
#include "files.h"
// these ones are not working also
//#include "cloudOperations.h"
//#include "visualize.h"
// c++ headers
#include <stdio.h>
#include <string>
//#include <sstream>
//#include <iostream>
void writeInfo()
{
// some std::cout calls
}
int main( int argc, char* argv[] )
{
writeInfo();
// this function is in opencvOperations.h and works OK
pcltest::openLena();
}
Then I get several error messages in my main.obj that some (PCL related) symbols are already defined in files.obj. I use PCL related calls both in opencvOperations and files, the first one is OK, the second one does not work.
Edit:
To add more detail, my files.h header:
#pragma once
#ifndef PCLTEST_FILES
#define PCLTEST_FILES
// pcl headers
#ifndef PCL_COMMON_H_
#include <pcl/common/common_headers.h>
#endif
#ifndef PCL_IO_FILE_IO_H_
#include <pcl/io/file_io.h>
#endif
#ifndef PCL_IO_PCD_IO_H_
#include <pcl/io/pcd_io.h>
#endif
#ifndef PCL_IO_PLY_IO_H_
#include <pcl/io/ply_io.h>
#endif
// boost headers
#ifndef BOOST_FILESYSTEM_OPERATIONSX_HPP
#include <boost/filesystem/operations.hpp>
#endif
#endif
namespace pcltest
{
// function to open PCL or binary PLY files
pcl::PointCloud<pcl::PointXYZ>::Ptr openCloud(std::string filename);
// function to save the point cloud to PCD format
void saveCloud();
}
Before splitting the code into separate files, everything worked well (with the same project settings).
Edit2:
I located the source of the problem,
#include <pcl/io/ply_io.h>
causes this. For now, I got rid of everything related to PLY and everything works fine. I'll look at it later, this might be a PCL library specific issue. Still strange to me why this call causes linker error in an other file, where I don't even use PLY related functions/variables.
I had the same problem as you had. I had a surface.h and surface.cpp file, and I found out that I had to include the ply_io.h file from surface.cpp rather than surface.h and now it compiles fine. I hope that helps or makes sense! haha
If a constant is being instantiated in an include one can also use selectany, per http://msdn.microsoft.com/en-us/library/5tkz6s71%28v=vs.80%29.aspx -- in my case:
const int CSdata[] = {1, 2, 3, 4};
when included in more than one source part produces LNK2005 at link time, avoided via:
const __declspec(selectany) int CSdata[] = {1, 2, 3, 4};
Non-portable, yeah ...