i just started ACE with a "HELLO WORLD" program. It compiled successfully but while building it produces some of the errors.Can anyone help me.
CODE:
#include <stdio.h>
#include "ace/Log_Msg.h"
#include "ace/OS_main.h"
int ACE_TMAIN(int argc, ACE_TCHAR *argv[])
{
ACE_DEBUG((LM_DEBUG, "Hello World\n"));
return 0;
}
ERROR:
/tmp/cccwdbA0.o: In function `main':
hello.cpp:(.text+0xa): undefined reference to `ACE_Log_Msg::last_error_adapter()'
hello.cpp:(.text+0x13): undefined reference to `ACE_Log_Msg::instance()'
hello.cpp:(.text+0x43): undefined reference to `ACE_Log_Msg::conditional_set(char const*, int, int, int)'
hello.cpp:(.text+0x5f): undefined reference to `ACE_Log_Msg::log(ACE_Log_Priority, char const*, ...)'
collect2: ld returned 1 exit status
Compilation failed.
Without seeing the build commands it's hard to tell but it looks like you didn't add a link-time reference to the ACE library.
It's hard to tell what you've done to make this not work. If I were to guess, it looks as if you've updated your include path in your makefile but forgotten to link libACE.so to your project. This would result in the undefined compilation behaviour you're seeing.
Related
Please check my short code below.
pwrapper.h
#include <stdio.h>
#include <stdarg.h>
extern"C" int mm_printfA(const char *fmt, ...);
extern"C" int mm_printfW(const wchar_t *fmt, ...);
pwrapper.cpp
#include "pwrapper.h"
int mm_printfA(const char *fmt, ...)
{
va_list args;
va_start(args, fmt);
int ret = vprintf(fmt, args);
va_end(args);
return ret;
}
int mm_printfW(const wchar_t *fmt, ...)
{
va_list args;
va_start(args, fmt);
int ret = vwprintf(fmt, args);
va_end(args);
return ret;
}
main.cpp
#include "pwrapper.h"
// cl /MT /D _NO_CRT_STDIO_INLINE main.cpp pwrapper.cpp
void main()
{
mm_printfA("What is %d?\n", 123);
}
#if 0
void usedull()
{
vprintf(NULL, NULL);
vwprintf(NULL, NULL);
}
#endif
For some reason, I need to compile it with _NO_CRT_STDIO_INLINE, like this:
cl /MT /D _NO_CRT_STDIO_INLINE main.cpp pwrapper.cpp
But link stage fails saying unresolved external symbol vwprintf and vprintf .
A very weird workaround I find out is: Enable the usedull() function body -- although never be called, and, link through pwrapper.lib, using bb.bat below:
#setlocal EnableDelayedExpansion
#set CFLAGS=/D _NO_CRT_STDIO_INLINE
cl /nologo /c /MT %CFLAGS% pwrapper.cpp
#if errorlevel 1 exit /b 4
lib /nologo /out:pwrapper.lib pwrapper.obj
#if errorlevel 1 exit /b 4
cl /nologo /c /MT main.cpp
#if errorlevel 1 exit /b 4
link /nologo main.obj pwrapper.lib
#if errorlevel 1 exit /b 4
Well, this really works, but why?
This is not a pleasant workaround, because each exe project needs to include a "useless" usedull() function. So, is there any better way?
I really can't tell why this workaround works, an explanation of it is very welcome.
==== Some Clarification ====
There were two main.cpp in my original post. Let me name them separately for later reference in case someone would bother to answer this weird question.
main.0.cpp refers to the one without usedull().
main.1.cpp refers to the one with usedull().
In this question, I use VC++ headers and libs for application(not for kernel), and
I compile main.0.cpp and main.1.cpp without _NO_CRT_STDIO_INLINE.
I always compile pwrapper.cpp with _NO_CRT_STDIO_INLINE.
Whether having pwrapper.obj go through pwrapper.lib produce the same result in this issue.
In short:
compiling pwrapper.cpp with -D _NO_CRT_STDIO_INLINE tells the compiler you are going to provide your own implementation of vprintf and vwprintf at link time, and
compiling main.cpp without -D _NO_CRT_STDIO_INLINE tells the compiler to include implementations of vprintf and vwprintf which are used at link time to satisfy both the references from usedull and mm_printfA/mm_printfW
so, this particular combination works to resolve all undefined symbols at link time. See below for more discussion however.
Discussion
In stdio.h, vprintf (which I'll focus on, but vwprintf is configured in the same way) is defined like so:
_Check_return_opt_
_CRT_STDIO_INLINE int __CRTDECL vprintf(
_In_z_ _Printf_format_string_ char const* const _Format,
va_list _ArgList
)
#if defined _NO_CRT_STDIO_INLINE
;
#else
{
return _vfprintf_l(stdout, _Format, NULL, _ArgList);
}
#endif
Note that
if _NO_CRT_STDIO_INLINE is defined, this becomes a forward declaration
whereas if it is not defined, the full body is included in the compilation of the including translation unit.
Additionally, in corecrt_stdio_config.h whether _NO_CRT_STDIO_INLINE is defined determines the value of _CRT_STDIO_INLINE; if it is defined, _CRT_STDIO_INLINE is defined as empty, otherwise it is defined as __inline.
Putting these together,
if _NO_CRT_STDIO_INLINE is not defined, these functions will be candidates for inline expansion,
otherwise a separate implementation of that function will need to be provided at link time.
Default Compilation (no /O1, /O2, no _NO_CRT_STDIO_INLINE)
The above works with the specific compile and link invocations you are using, as without optimization the compiler will simply include the function body in the compilation of main.1.obj. You can see this using dumpbin; running dumpbin -symbols main.1.obj | find "| vprintf" prints:
01D 00000000 SECT8 notype () External | vprintf
showing that main.1.obj provides vprintf as an externally available symbol.
Checking pwrapper.obj, we get:
00A 00000000 UNDEF notype () External | vprintf
showing that vprintf is undefined in this object file, and will need to be provided at link time.
Optimisation for Inline Expansion
However, if we change the optimisation option for inline expansion, we get different results. Using even the first level of optimisation (-Ob1, included in -O1 and -O2) like so:
cl -c -Ob1 main.1.cpp
causes the compiler to incorporate the body of vprintf directly into usedull, and remove the separate implementation of vprintf, which can be confirmed using dumpbin. So, as you would now expect, attempting to link main.1.obj and pwrapper.obj together will once again give your original error:
pwrapper.obj : error LNK2019: unresolved external symbol vwprintf referenced in function mm_printfW
pwrapper.obj : error LNK2019: unresolved external symbol vprintf referenced in function mm_printfA
main.exe : fatal error LNK1120: 2 unresolved externals
Multiple Implementations?
So, following on from that it is apparent that compiling both files with -D _NO_CRT_STDIO_INLINE will fail as there will be no implementations of the relevant methods. What about if both are compiled without this definition?
If we check the object files, both have defined symbols for vprintf:
01D 00000000 SECT8 notype () External | vprintf
and:
01A 00000000 SECT7 notype () External | vprintf
which under normal circumstances would result in errors due both to multiple definitions of a symbol and violations of the One Definition Rule. However, when performing inline expansion, the compiler and linker have your back. As per 2:
Rather than expand an inline function defined in a header file, the compiler may create it as a callable function in more than one translation unit. The compiler marks the generated function for the linker to prevent one-definition-rule (ODR) violations.
I'm working with Visual Studio Code, Platformio extension, Arduino framework. Have NodeMCU v3 board with ESP8266.
I wrote some simple program, which gets data from sensor and blinks some LED. Everythink went fine, code compiled and worked on the nodeMCU.
Great, so as a next step I wanted to connect it to Azure. So as multiple examples were showing, I included some libraries and wrote/copied simple code. After removing some first compilation errors:
missing blob.h -> https://github.com/Azure/azure-iot-arduino/issues/101
error in Arduino.h, round(x) -> https://github.com/Azure/azure-iot-arduino#simple-sample-instructions
MQTT_Protocol' was not declared -> https://github.com/Azure/azure-iot-arduino/issues/108
I've stucked with another error. After cutting code down, you can see a very easy code here:
#include <Arduino.h>
#include "config.h"
#include <ESP8266WiFi.h>
#include <AzureIoTHub.h>
#include <AzureIoTProtocol_MQTT.h>
#include <AzureIoTUtility.h>
#include <ArduinoJson.h>
#include "iothubtransportmqtt.h"
static IOTHUB_CLIENT_LL_HANDLE iotHubClientHandle;
void setup() {
pinMode(PIN_GREEN_LED, OUTPUT);
digitalWrite(PIN_GREEN_LED, LOW);
static IOTHUB_CLIENT_TRANSPORT_PROVIDER protocol = MQTT_Protocol;
iotHubClientHandle = IoTHubClient_LL_CreateFromConnectionString("connectionString", protocol);
}
void loop() {
digitalWrite(PIN_GREEN_LED, LOW);
}
Without calling IoTHubClient_LL_CreateFromConnectionString function, which I guess can't be skipped to make connection to Azure IoT Hub, code builds. I had to add iothubtransportmqtt.h, so the MQTT_Protocol is available.
My platformio.ini file (changing the board to esp12e makes no difference):
[env:nodemcuv2]
platform = espressif8266
board = nodemcuv2
framework = arduino
lib_deps =
DHT
AzureIoTHub
ArduinoJson
This is how the build starts:
CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/nodemcuv2.html
PLATFORM: Espressif 8266 2.5.1 > NodeMCU 1.0 (ESP-12E Module) [or Espressif ESP8266 ESP-12E for esp12e board]
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES:
- framework-arduinoespressif8266 3.20701.0 (2.7.1)
- tool-esptool 1.413.0 (4.13)
- tool-esptoolpy 1.20800.0 (2.8.0)
- toolchain-xtensa 2.40802.200502 (4.8.2)
Dependency:
Dependency Graph
DHT 1.0.0
AzureIoTHub 1.3.8
AzureIoTUtility 1.3.8.1
ESP8266WiFi 1.0
ArduinoJson 6.15.2
AzureIoTProtocol_MQTT 1.3.8
Here the terminal output with dozens of warnings before:
Linking .pio\build\nodemcuv2\firmware.elf
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothub_client_core_ll.c.o):(.text.initialize_iothub_client+0x6c): undefined reference to IoTHubClient_LL_UploadToBlob_Destroy'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothub_client_core_ll.c.o):(.text.initialize_iothub_client+0x78): undefined reference toIoTHubClient_LL_UploadToBlob_Create'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothub_client_core_ll.c.o): in function initialize_iothub_client':
iothub_client_core_ll.c:(.text.initialize_iothub_client+0x1de): undefined reference toIoTHubClient_LL_UploadToBlob_Destroy'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: iothub_client_core_ll.c:(.text.initialize_iothub_client+0x3ea): undefined reference to IoTHubClient_LL_UploadToBlob_Create'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: iothub_client_core_ll.c:(.text.initialize_iothub_client+0x486): undefined reference toIoTHubClient_LL_UploadToBlob_Destroy'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: iothub_client_core_ll.c:(.text.initialize_iothub_client+0x547): undefined reference to IoTHubClient_LL_UploadToBlob_Destroy'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o):(.text.mqtt_operation_complete_callback+0x20): undefined
reference toretry_control_reset'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o): in function mqtt_operation_complete_callback':
iothubtransport_mqtt_common.c:(.text.mqtt_operation_complete_callback+0xd3): undefined reference toretry_control_reset'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o):(.text.free_transport_handle_data+0x0): undefined reference to retry_control_destroy'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o):(.text.free_transport_handle_data+0x1f): undefined reference toretry_control_destroy'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o):(.text.IoTHubTransport_MQTT_Common_SetRetryPolicy+0x8): undefined reference to retry_control_create'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o): in functionIoTHubTransport_MQTT_Common_SetRetryPolicy':
iothubtransport_mqtt_common.c:(.text.IoTHubTransport_MQTT_Common_SetRetryPolicy+0x37): undefined reference to retry_control_create'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: iothubtransport_mqtt_common.c:(.text.IoTHubTransport_MQTT_Common_SetRetryPolicy+0x60): undefined reference toretry_control_destroy'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o): in function IoTHubTransport_MQTT_Common_Create':
iothubtransport_mqtt_common.c:(.text.IoTHubTransport_MQTT_Common_Create+0x1ae): undefined reference toretry_control_create'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o):(.text.IoTHubTransport_MQTT_Common_DoWork+0x64): undefined reference to retry_control_should_retry'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o):(.text.IoTHubTransport_MQTT_Common_DoWork+0xca): undefined reference toretry_control_should_retry'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o):(.text.IoTHubTransport_MQTT_Common_SetOption+0x50): undefined reference to retry_control_set_option'
c:/users/mmielnic/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: .pio\build\nodemcuv2\lib1b2\libAzureIoTHub_ID480.a(iothubtransport_mqtt_common.c.o): in functionIoTHubTransport_MQTT_Common_SetOption':
iothubtransport_mqtt_common.c:(.text.IoTHubTransport_MQTT_Common_SetOption+0x192): undefined reference to `retry_control_set_option'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\nodemcuv2\firmware.elf] Error 1
I've found a reason of that issue. I did not resolve previous problem with lack of blob.h file corectly. The workaround with adding new parameters to platform.txt did not work, So I had to modify file iothub_client_ll_uploadtoblob.c manually by removing:
#include "internal/blob.h" line of code and all it affected there.
The second problem was, that there was file missing: iothub_client_retry_control.c for nodemcuv2 environment. I do not know why it wasn't there, but I used file from esp12e env, so simply copied:
.pio\libdeps\esp12e\AzureIoTHub_ID480\src\iothub_client_retry_control.c
to
.pio\libdeps\nodemcuv2\AzureIoTHub_ID480\src\iothub_client_retry_control.c
After that, code compiled and I was able to connect to wifi and send messages to the Azure ioT Hub.
Hope it helps to someone.
I am building an ASTMatcher-based tool that I would like to run over my sources:
int main(int argc, const char** argv) {
CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
ClangTool Tool(OptionsParser.getCompilations(),
OptionsParser.getSourcePathList());
MatchFinder Finder;
// Repeated calls to Finder.addMatcher(...);
Tool.run(newFrontendActionFactory(&Finder).get());
// Handle the results of the matching.
}
Running this over a source file that depends on other headers yields the following error:
~$ /path/to/my/tool /path/to/my/file.cpp --
/path/to/my/file.cpp:8:10: fatal error: 'string' file not found
#include <string>
^~~~~~~~
1 error generated.
Error while processing /path/to/my/file.cpp.
I do not want to include any other headers in this processing, lest my matchers find content in those headers that I do not want to handle.
I tried passing -fsyntax_only to the tool, but I get the same result as above:
~$ /path/to/my/tool /path/to/my/file.cpp -- -fsyntax-only
I noticed in the ASTMatcher tutorial that there is a clang::SyntaxOnlyAction. However, I have been unable to figure out how MatchFinder and SyntaxOnlyAction can be used in conjunction with one another. Likewise, I have been able to do an AST dump from the command line of the same file, no problem, so I know it's possible.
Is it possible to configure a MatchFinder-based tool to honor the syntax-only behavior?
I am using Flex and Bison to create a compiler. As I am trying to create an AST (Abstract Syntax Tree) for my program, I need to port it to C++. So far I have been successful, until a encountered a rather obscure error from my compiler:
Kraken.o: In function Kraken::FlexScanner::FlexScanner()':
Kraken.cc:(.text._ZN6Kraken11FlexScannerC2Ev[_ZN6Kraken11FlexScannerC5Ev]+0x26): undefined reference to vtable for Kraken::FlexScanner'
Kraken.o: In function Kraken::FlexScanner::~FlexScanner()':
Kraken.cc:(.text._ZN6Kraken11FlexScannerD2Ev[_ZN6Kraken11FlexScannerD5Ev]+0xb): undefined reference to vtable for Kraken::FlexScanner'
Here is all the relevant code:
Kraken.cc:
#include "KrakenScanner.hh"
#include "KrakenParser.hh"
int main(int argc, char * argv[]) {
Kraken::Parser parser;
return parser.parse();
}
KrakenScanner.hh:
#ifndef KRAKENSCANNER_HH_
#define KRAKENSCANNER_HH_
#if ! defined(yyFlexLexerOnce)
#include <FlexLexer.h>
#endif
#undef YY_DECL
#define YY_DECL int Kraken::FlexScanner::yylex()
#include "parser.hh"
namespace Kraken {
class FlexScanner : public yyFlexLexer {
public:
int yylex(Kraken::BisonParser::semantic_type* lval);
private:
int yylex();
Kraken::BisonParser::semantic_type* yylval;
};
}
#endif /* KRAKENSCANNER_HH_ */
KrakenScanner.cc:
#include "KrakenScanner.hh"
int Kraken::FlexScanner::yylex(Kraken::BisonParser::semantic_type* lval) {
yylval = lval; return yylex();
}
Makefile:
OBJS := Kraken.o parser.o scanner.o KrakenScanner.o KrakenParser.o
%.cc: %.y
bison -o $(#:%.o=%.d) $<
%.cc: %.l
flex -o$(#:%.o=%.d) -i $<
all: $(OBJS)
g++ -okraken $(OBJS)
Kraken.o: Kraken.cc KrakenScanner.o KrakenParser.o
KrakenScanner.o: KrakenScanner.hh KrakenScanner.cc parser.o
parser.o: parser.hh parser.cc
parser.cc: parser.y
scanner.o: scanner.cc
scanner.cc: scanner.l
KrakenParser.o: KrakenParser.hh KrakenParser.cc KrakenScanner.o`
I don't know if this will help, but FlexLexer.h defines the classes FlexLexer and yyFlexLexer. FlexLexer declares just a virtual destructor, and yyFlexLexer defines both a constructor and destructor. Also, when I attempt to overload the constr. and destr. in Kraken.cc, I get an error saying that the two are "implicitly defined".
Try a clean rebuild (rm *.o) and recompile. The compiler is supposed to generate this stuff automatically. Some compilers have special non-portable magic to influence v-table linking, but I don't see anything like that in your code.
Also, I see in your makefile that you've written a rule for linking with g++, but you haven't written any rule for compilation. So make is using its built-in rules, which might by the C++ compiler provided by your OS, not g++.
Another thing is that makefile rules should put the primary source first. For example:
wrong:
KrakenScanner.o: KrakenScanner.hh KrakenScanner.cc parser.o
right:
KrakenScanner.o: KrakenScanner.cc KrakenScanner.hh
Finally, object files aren't used to build other object files, only during linking.
First off, that error message is from your linker, not your compiler. It looks like you aren't linking in KrakenScanner.o. It also helps to apply the name demangler for your compiler to your compiler/linker error output.
What compiler are you using?
I am new in OpenCV and have some problems when using videoInput.lib,please help me.I am using winXP SP3+Cmake2.8.2+OpenCV 2.1+Visual Studio 2008.I have made every configuration and now OpenCv can be used when I am coding.I heard videoInput.lib has been included since OpenCV2.0 and I want to use it,so I tried codes below to quick test.
// Test2.cpp : Defines the entry point for the console application.
//
#include "videoInput.h"
#include "stdafx.h"
#include "cv.h"
#include "highgui.h"
#include "cxcore.h"
int main(int ,char * *)
{
int width=320;
int height=240;
IplImage *pRgb=cvCreateImage(cvSize(width,height), IPL_DEPTH_8U, 3);
videoInput video;
video.setupDevice(0, width, height);
video.showSettingsWindow(0);
while(1)
{
if(video.isFrameNew(0))
{
video.getPixels(0, (unsigned char *)pRgb->imageData, false, true);
//cvFlip(pRgb,NULL,1);
char c=cvWaitKey(1);
if(c==27) break;
cvShowImage("Video", pRgb);
}
}
}
However when I build the codes,I got following error
1>------ Build started: Project: Test2, Configuration: Debug Win32 ------
1>Compiling...
1>Test2.cpp
1>c:\opencv2.1\vc2008\include\opencv\cvcompat.h(803) : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss
1>Linking...
1>Test2.obj : error LNK2019: unresolved external symbol "public: __thiscall videoInput::~videoInput(void)" (??1videoInput##QAE#XZ) referenced in function _main
1>Test2.obj : error LNK2019: unresolved external symbol "public: bool __thiscall videoInput::getPixels(int,unsigned char *,bool,bool)" (?getPixels#videoInput##QAE_NHPAE_N1#Z) referenced in function _main
1>Test2.obj : error LNK2019: unresolved external symbol "public: bool __thiscall videoInput::isFrameNew(int)" (?isFrameNew#videoInput##QAE_NH#Z) referenced in function _main
1>Test2.obj : error LNK2019: unresolved external symbol "public: void __thiscall videoInput::showSettingsWindow(int)" (?showSettingsWindow#videoInput##QAEXH#Z) referenced in function _main
1>Test2.obj : error LNK2019: unresolved external symbol "public: bool __thiscall videoInput::setupDevice(int,int,int)" (?setupDevice#videoInput##QAE_NHHH#Z) referenced in function _main
1>Test2.obj : error LNK2019: unresolved external symbol "public: __thiscall videoInput::videoInput(void)" (??0videoInput##QAE#XZ) referenced in function _main
1>C:\Documents and Settings\SKSC\My Documents\Visual Studio 2008\Projects\Test2\Debug\Test2.exe : fatal error LNK1120: 6 unresolved externals
1>Build log was saved at "file://c:\Documents and Settings\SKSC\My Documents\Visual Studio 2008\Projects\Test2\Test2\Debug\BuildLog.htm"
1>Test2 - 7 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I have been googling for a long time but still can not find the solution,I am gonna mad.Does anyone know how to fix these problems?
Thanks in advance.
I think you still need to link with videoInput.lib, OpenCV uses videoInput.lib but it doesn't mean you can use all functions of videoInput.lib from OpenCV
Yes, you have to explicitly link to videoInput.lib from the Linker.
Here you will find what you need.
Here is how you can solve it:
"Go to Project Properties -> Confuguration Properties -> Linker -> Input and add videoinput.lib along with the usual OpenCV library files." This is the solution from the site mentioned above. I tried it and it works.