I'm still having issues with an ongoing project that just won't compile. I've narrowed it down to the Includes but can't figure out what is going on. I've read that i need to add a WinMain entry point but that doesnt add up - I have classmates that didnt encounter this shit error at all.
So I've created a new empty project:
#include <cstdlib> //include c library
//using namespace std;
//using namespace cv;
namespace sp {
int main() {
return 0;
}
}
With the following includes:
Under GCC C++ Compiler Includes:
C:\Users\Amit\Desktop\opencv\build\include
C:\opencv_contrib-3.0.0\modules\xfeatures2d\include
Under MinGW C++ Linker Libraries:
libopencv_core310
libopencv_imgcodecs310
libopencv_imgproc310
libopencv_xfeatures2d310
libopencv_features2d310
libopencv_highgui310
Under MinGW C++ Linker Library search path:
C:\Users\Amit\Desktop\opencv\build\x86\mingw\lib
Still, without calling any function from those libraries, I'm getting this error:
09:45:43 **** Incremental Build of configuration Debug for project testing ****
Info: Internal Builder is used for build
g++ "-IC:\\opencv_contrib-3.0.0\\modules\\xfeatures2d\\include" "-IC:\\Users\\Amit\\Desktop\\opencv\\build\\include" -O0 -g3 -Wall -c -fmessage-length=0 -o "src\\testing.o" "..\\src\\testing.cpp"
g++ "-LC:\\Users\\Amit\\Desktop\\opencv\\build\\x86\\mingw\\lib" -o testing.exe "src\\testing.o" -llibopencv_core310 -llibopencv_imgcodecs310 -llibopencv_imgproc310 -llibopencv_xfeatures2d310 -llibopencv_features2d310 -llibopencv_highgui310
c:/mingw/bin/../lib/gcc/mingw32/4.9.3/../../../libmingw32.a(main.o):(.text.startup+0xa7): undefined reference to `WinMain#16'
collect2.exe: error: ld returned 1 exit status
09:45:43 Build Finished (took 396ms)
Can anyone save me?
Thanks,
Amit.
When you create an executable the linker expects a function named main in the global namespace. You have placed the function inside a namespace instead of the global namespace so the linker will not find it.
So either move your main outside of the sp namespace or tell the linker where the function is (at least that is possible with MS linker but not sure how it is done with g++).
namespace sp {
int main() {
return 0;
}
}
declares an sp::main function, not main. This leaves you without a main function to serve as the program entry point.
Solution: Remove main from the sp namespace.
int main() {
return 0;
}
Related
This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed last month.
I'm trying to use Visual Studio for a specific project but I can't get files to link properly.
When including a header file with a defined function in another cpp file im getting an error undefined reference to testFunc() collect2.exe: error: ld returned 1 exit status
Thing is, this exact same code works perfectly in Eclipse. Can someone tell me what I'm doing wrong?
Test.cpp
#include "Other.h"
int main(){
testFunc();
return 0;
}
Other.h
#pragma once
void testFunc();
Other.cpp
#include "Other.h"
#include <iostream>
using namespace std;
void testFunc(){
cout << "HelloWorld";
}
When Buildung, this occours:
Starting build...
C:\MinGW\bin\g++.exe -fdiagnostics-color=always -g C:\Users\johan\cu-workspace\TEst\Test.cpp -o C:\Users\johan\cu-workspace\TEst\Test.exe
C:\Users\johan\AppData\Local\Temp\cck3aAZo.o: In function `main':
C:/Users/johan/cu-workspace/TEst/Test.cpp:5: undefined reference to `testFunc()'
collect2.exe: error: ld returned 1 exit status
Build finished with error(s).
If you build Other.h and Other.cpp as a project, then you need to configure the linker to add Other.lib into test project.
For a simple scenario, you can have all 3 files in one project and they should build just fine.
According to your build info:
C:\MinGW\bin\g++.exe -fdiagnostics-color=always -g C:\Users\johan\cu-workspace\TEst\Test.cpp -o C:\Users\johan\cu-workspace\TEst\Test.exe
You can see that Other.cpp is not in your project, so you might need to add it into your project.
Since you are using VS code, you can write a simple command in terminal to build your code:
C:\MinGW\bin\g++.exe -g C:\Users\johan\cu-workspace\TEst\Test.cpp C:\Users\johan\cu-workspace\TEst\Other.cpp -o C:\Users\johan\cu-workspace\TEst\Test.exe
[Juce][1] is the framework for Audio/Media application
It created the XCode project linking with Juce library.
I start from making test dynamic library.
I exported project to Xcode from Juce and added source.cpp
#include<iostream>
using namespace std;
int helloJuce(){
cout<<"Hello,From Juce!"<<endl;
return 1;
}
Now NewProject.dylib is compiled.
And confirmed that entry point is registered.
$nm NewProject.dylib |grep hello
00000000000021b0 t __Z9helloJucev
in testJuce.cpp
#include
int helloJuce();
int main() {
helloJuce();
std::cout << "Test Finish!\n";
return 0;
}
then, try to compile
$ g++ -o testJuce testJuce.cpp -L ./ -lNewProject
ld: library not found for -lNewProject
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I tested these patterns, but in vain.
cp NewProject.dylib libNewProject.dylib
cp NewProject.dylib libNewProject.so
In generally speaking, lib***.so style is common for dylib??
Does anyone help me?
Any suggestion appreciated.
I´m using Eclipse 3.8.1 on Ubuntu 14.02 with 2 projects for the first time. I´m coming from c# world so that can be an Eclipse error or a C++ concept error.
testmonitor: A sample C++ project. Code:
#include <iostream>
using namespace std;
int main() {
cout << "Test program" << endl;
log_access::test();
return 0;
}
log_access is a shared library: log_access.cpp
#include <iostream>
namespace log_access {
void test()
{
std::cout << "It worked!!!" << std::endl;
}
}
I´m trying to build a shared library and link it to the main project. I went to Project -> Properties -> Project References and clicked on the project (shared lib) I want to reference.
Not worked....
Then I went to Project -> Properties -> C/C++ General -> Paths and Symbols -> References Tab and clicked on the project (shared lib) I want to reference.
Not worked...
Currently I´m getting the following error:
Invoking: GCC C++ Compiler
g++ -std:c++0x -I"home/projects/dev/sample/workspace/log_access" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/testproject.d" -MT"src/testmonitor.d" -o "src/testmonitor.o" "../src/testmonitor.cpp"
../src/testmonitor.cpp: In function 'int main()':
../src/testmonitor.cpp:34.3: error: 'log_access' has not been declared
log_access:test();
^
make: *** [src/testmonitor.o] Error 1
13:56:39 Build Finished (took 1s.246ms)
Obs: The log_access compiles fine...
I appreciate very much some help on that...
You'll need to include your definition of log_access::test in your main file via
#include "log_access.h"
Assuming you have a header file named log_access (you shouldn't include .cpp files; use them for implementing methods declared within the header file. See here for why).
I've written some C++ code for an embedded system which works like a charm. The current task is to emulate the behaviour of this device on a PC. Some of the code has to be ported: For a first test I'm using mingw (g++) while the Embedded system is an STM32 and uses the KEIL µVision toolchain.
I've run into a problem that is not really related to functional behaviour rather than a compiler specific weirdness. I have 2 classes defined in an anonymous namespace because they are included throughout the whole project. Now on the embedded device this compiles and runs without a problem. g++ complains about an undefined reference!
When I remove the anonymous namespace arround the class it compiles and runs! But why? Here is some example code that reproduces the situation:
main.cpp:
#include "notmain.h"
#include "theclass.h"
A *ourA=NULL;
int main()
{
theA = new A();
theA->dostuff(1024);
sunshine sun;
sun.Init();
}
notmain.cpp:
#include "notmain.h"
#include "theclass.h"
void sunshine::Init()
{
theA->dostuff(127);
}
notmain.h:
#ifndef NOTMAIN_H_
#define NOTMAIN_H_
class sunshine
{
public:
void Init();
};
#endif
theclass.h:
#ifndef THECLASS_H_
#define THECLASS_H_
#include <stdio.h>
#define theA ourA
namespace
{
class A
{
public:
void dostuff(int b)
{
a = b;
printf("Hello: %d\n",a);
}
private:
int a;
};
}
extern A *ourA;
#endif
Compiler/Linker Output:
09:09:57 ** Incremental Build of configuration Debug for project Testo **
Info: Internal Builder is used for build
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o main.o "..\main.cpp"
g++ -O0 -g3 -Wall -c -fmessage-length=0 -o notmain.o "..\notmain.cpp"
g++ -o Testo.exe notmain.o main.o
notmain.o: In function ZN8sunshine4InitEv':
D:\Projekte\Testo\Debug/../notmain.cpp:6: undefined reference toourA'
collect2.exe: error: ld returned 1 exit status
09:09:57 Build Finished (took 702ms)
Removing that namespace fixes the problem but why does it compile, link, work in KEIL? Can anyone explain this to me?
I would suggest that that is an abuse of the anonymous namespace feature. It does exactly the opposite of what you are trying to achieve.
Anonymous namespaces are used to localise a definition to a single translation unit. If you place one in a header file, then include that header in multiple translation units, that will result in multiple independent definitions in your code.
What is happening here VC++ is that a global ourA has been instantiated as a pointer to one local definition of A defined in main.cpp, then later that local definition is no longer visible but is distinct from the currently visible local version in notmain.cpp. The name mangling of ZN8sunshine4InitEv distinguishes between independent definitions, but name mangling is compiler defined, and I guess ARM's RealView compiler (used by uVision) has a different scheme that fails to spot this error.
It is unclear in fact what the result if this error is in RealView, but it cannot be correct or at least well defined.
RealView is in fact rather poor at issuing warnings that other compilers do normally, and is somewhat permissive when it comes to undefined behaviour I have found. It is always worth using another toolchain such as MinGW/GCC with -Werror -Wall or using a static analysis tool to clean up your code.
To solve this problem you should use an explicitly named namespace, or no namespace at all.
I know there are many questions related to shared libraries on Linux but maybe because I'm tired of having a hard day trying to create a simple dynamic library on Linux (on Windows it would have taken less than 10 minutes) I can't find what happens in this case.
So, I am trying to create a library to be linked at build-time and used at run-time (not a static library, not a library to be embedded into the executable, in other words). For now it contains a simple function. These are my files:
1.
// gugulibrary.cpp
// This is where my function is doing its job
#include "gugulibrary.h"
namespace GuGu {
void SayHello() {
puts("Hello!");
}
}
2.
// gugulibrary.h
// This is where I declare my shared functions
#include <stdio.h>
namespace Gugu {
void SayHello();
}
3.
// guguapp.cpp
// This is the executable using the library
#include "gugulibrary.h"
int main() {
GuGu::SayHello();
return 0;
}
This is how I try to build my project (and I think this is what is wrong):
gcc -Wall -s -O2 -fPIC -c gugulibrary.cpp -o gugulibrary.o
ld -shared -o bin/libGugu.so gugulibrary.o
gcc -Wall -s -O2 guguapp.cpp -o bin/GuGu -ldl
export LD_LIBRARY_PATH=bin
This is saved as a .sh file which I click and execute in a terminal. The error I get when trying to link the library is this:
/tmp/ccG05CQD.o: In function `main':
guguapp.cpp:(.text.startup+0x7): undefined reference to `SayHello'
collect2: ld returned 1 exit status
And this is where I am lost. I want the library to sit in the same folder as the executable for now and maybe I need some symbols/definitions file or something, which I don't know how to create.
Thanks for your help!
In your C++ file, GuGu::SayHello is declared as a C++ symbol. In your header, you are wrapping it in an extern "C" block. This is actually undefined, as you aren't allowed to use C++ syntax (namespace) in that context. But my guess is that what the compiler is doing is ignoring the namespace and generating a C symbol name of "SayHello". Obviously such a function was never defined by your library. Take out the extern "C" bits, because your API as defined cannot be used from C anyway.
You are inconsistent with your GuGu, there are also Gugu's running around, this needs to be made consistent, then it works (At least on my computer are some Gugu's now)