I've searched for the error LNK2005 "already defined in .obj" but can't find content related to the specific problem I am facing. Hope someone can help me on this...
I've a header foo.h
// foo.h
#ifndef FOO_H
#define FOO_H
void foo() {
print("foo\n");
}
#endif
and main file... main.cpp
// main.cpp
#include <thread>
#include "foo.h"
int main() {
std::thread t(foo);
t.join();
return 0;
}
Now, it compile without any errors and gives the gives output to the console...
foo
But if I create another file foo.cpp and just include the header foo.h and do nothing else...
// foo.cpp
#include "foo.h"
...I get linker error LNK2005 "void __cdecl foo(void)" (?foo##YAXXZ) already defined in main.obj
Don't know what's going wrong here.?!!
You must place only the prototype of the foo() function in the header file, and the implementation once in the .cpp.
Thus, foo.h must contain:
#pragma once
void foo();
And foo.cpp:
#include "foo.h"
void foo() {
printf("Whatever");
}
Related
I have an existing project in Rust / C and I want to migrate some low level hashing stuff to CUDA, but I can't get it to finish compiling.
I believe the compile part is working, as the error only appears in the linker if I call the function from the .cu file
build.rs
fn main() {
let mut cfg = cc::Build::new();
cfg.cuda(true);
cfg.include("project/include")
.include("project/src")
.file("project/src/HelloWorld.cu")
.file("project/src/Validate.c")
//more C files...
.out_dir(dst.join("lib"))
.flag("-O2")
.compile("libproject.a");
println!("cargo:root={}", dst.display());
println!("cargo:include={}", dst.join("include").display());
println!(
"cargo:rerun-if-changed={}",
env::current_dir().unwrap().to_string_lossy()
);
println!("cargo:rerun-if-env-changed=PC_CC");
if let Ok(cuda_path) = env::var("CUDA_HOME") {
println!("cargo:rustc-link-search=native={}/lib64", cuda_path);
} else {
println!("cargo:rustc-link-search=native=/usr/local/cuda/lib64");
}
println!("cargo:rustc-link-lib=dylib=cudart");
}
HelloWorld.h
#ifndef CUDA_HELLO_WORLD_H
#define CUDA_HELLO_WORLD_H
#include <stdio.h>
#include "cuda_runtime.h"
void cudaTest();
#endif
HelloWorld.cu
#include "HelloWorld.h"
__global__ void mykernel(void){
}
void cudaTest(){
mykernel<<<1,1>>>();
printf("Hello World!\n");
}
error:
error: linking with `cc` failed: exit status: 1
[...] really big compile command
= note: /usr/bin/ld: project/target/debug/deps/libproject-673a2f9d363593e3.rlib(File.o): in function `call_to_cuda_file`:
project/project/src/File.c:168: undefined reference to `cudaTest`
collect2: error: ld returned 1 exit status
There was a linking problem as CUDA uses C++ linkage
The solution was to modify HelloWorld.h to
#ifndef CUDA_HELLO_WORLD_H
#define CUDA_HELLO_WORLD_H
#ifdef __cplusplus
extern "C"
{
#endif
#include <stdio.h>
#include "cuda_runtime.h"
void cudaTest();
#ifdef __cplusplus
}
#endif
#endif
There was no need to modify anything on HelloWorld.cu
My code :
main.cpp
#include <iostream>
namespace file {
#include "file.cpp"
}
namespace file2 {
#include "file1.cpp"
}
int main() {
file::hello();
return 0;
}
file.cpp
#include <iostream>
void hello() {
std::cout << "hello";
}
file1.cpp
#include <iostream>
void hello() {
std::cout << "hello world";
}
My problem:
I use virtual studio, and i don't know why this does not work.I try it allready on CodeBlock and it was fine. But in VS i have error with at least one repeatedly defined symbol has been found.
Sorry for my english.
Since VS still builds and links file.cpp and file1.cpp to the executable you get the errors. You can exclude them from the project by changing its properties or make them regular header files and include them as such.
The include will literally just copy the content of the file into the name space declaration of main.cpp.
Please help to figure out whats wrong with this code.
main.cpp create Object3D which create Box and pass Object3D* pointer to Box.
And there are errors until i remove Object3D declarations from Box.
main.cpp
#include <iostream>
#include "stdafx.h"
#include "Object3D.h"
int _tmain(int argc, _TCHAR* argv[])
{
Object3D obj;
char c;
std::cin >> c;
return 0;
}
Object3D.cpp
#include "Object3D.h"
#include "Box.h"
Object3D::Object3D()
{}
Object3D::~Object3D()
{}
Object3D.h
#ifndef OBJECT3D_H
#define OBJECT3D_H
#include "Box.h"
class Object3D
{
public:
Object3D();
~Object3D();
private:
Box _box_obj; //<<<---ERROR HERE (C2146, C4430)
};
#endif
Box.cpp
#include "Box.h"
#include "Object3D.h"
int Box::Init(Object3D* _obj)
{
obj = _obj;
}
Box::Box()
{}
Box::~Box()
{}
Box.h
#ifndef BOX_H
#define BOX_H
#include "Object3D.h"
class Box
{
public:
Object3D* obj; //<<<---ERROR HERE (C2143, C4430)
int Init(Object3D* _obj); //<<<---ERROR HERE (C2061)
Box();
~Box();
};
#endif
Change Box.h:
#ifndef BOX_H
#define BOX_H
// forward reference possible since the class is not dereferenced here.
class Object3D;
class Box
{
public:
Object3D* obj;
int Init(Object3D* _obj);
Box();
~Box();
};
#endif
The class definition does not use any member of Object3D. Therefore you don't need to know the definition of Object3D but just the fact that it is a class. The forward reference is sufficient and an appropriate tool to resolve a circular dependency.
BTW: The circular reference of object usually includes some "master" objects that own the other objects. It makes sense to change the member name to show the relation rather the type. I would suggest a
Object3D* owner;
when the box owns the obj.
I have a simple question. I want to compile the following c file:
#include <linux/kernel.h>
#include <linux/module.h>
#include <sys/syscall.h>
extern void *sys_call_table[];
asmlinkage int (*original_sys_open)(int);
asmlinkage int our_fake_open_function(int error_code)
{
/*print message on console every time we
* *are called*/
printk("HEY! sys_open called with error_code=%d\n",error_code);
/*call the original sys_exit*/
return original_sys_open(error_code);
}
/*this function is called when the module is
* *loaded (initialization)*/
int init_module()
{
/*store reference to the original sys_exit*/
original_sys_open=sys_call_table[__NR_open];
/*manipulate sys_call_table to call our
* *fake exit function instead
* *of sys_exit*/
sys_call_table[__NR_open]=our_fake_open_function;
}
/*this function is called when the module is
* *unloaded*/
void cleanup_module()
{
/*make __NR_exit point to the original
* *sys_exit when our module
* *is unloaded*/
sys_call_table[__NR_open]=original_sys_open;
}
The problem is that gcc -I/usr/src/kernels/2.6.32-279.el6.x86_64/include myfile.c generates a unsolvabe include dependency which can be found in .
Please tell me how to fix this gcc compiler problem I am encountering today. Thank you very much for your insight.
How to build external modules is documented in the documentation:
$ make -C <path_to_kernel_src> M=$PWD
I have a problem lunching a thread within a class A for example where the class A is a static member of class B with in a dll. I am using Visual Studio 9 and boost 1.40. Please consider the following code:
mylib.h:
#include <boost/thread.hpp>
#include <windows.h>
#ifdef FOO_STATIC
#define FOO_API
#else
#ifdef FOO_EXPORT
#define FOO_API __declspec(dllexport)
#else
#define FOO_API __declspec(dllimport)
#endif
#endif
class FOO_API foo{
boost::thread* thrd;
public:
foo();
~foo();
void do_work();
};
class FOO_API bar{
static foo f;
public:
static foo& instance();
};
mylib.cpp:
#include "mylib.h"
foo::foo()
{
thrd = new boost::thread(boost::bind(&foo::do_work,this));
}
foo::~foo(){
thrd->join();
delete thrd;
}
void foo::do_work(){
printf("doing some works\n");
}
foo& bar::instance(){return f;}
foo bar::f;
in the executable application, I have:
main.cpp:
#include "mylib.h"
void main(){
bar::instance();
}
If I link mylib statically to the executable app, It prints out "doing some works", while if I link it dynamically (dll), it does nothing.
I really appreciate any help.
Your program could be exiting before the thread completes. You might try waiting after the bar::instance() call, or joining the thread in main. Something else to try would be to flush stdout after the printf call.
From the MSDN documentation:
If your DLL is linked with the C
run-time library (CRT), the entry
point provided by the CRT calls the
constructors and destructors for
global and static C++ objects.
Therefore, these restrictions (*) for
DllMain also apply to constructors and
destructors and any code that is
called from them.
(*) The restrictions include communicating with threads.
It's best to make the global variable a pointer, and construct and release the object in dedicated callback routines.
See also this helpful SO answer.