I'm making a C++ Shared Library and when I compile a main exe that uses the library the compiler gives me:
main.cpp:(.text+0x21): undefined reference to `FooClass::SayHello()'
collect2: ld returned 1 exit status
Library code:
fooclass.h
#ifndef __FOOCLASS_H__
#define __FOOCLASS_H__
class FooClass
{
public:
char* SayHello();
};
#endif //__FOOCLASS_H__
fooclass.cpp
#include "fooclass.h"
char* FooClass::SayHello()
{
return "Hello Im a Linux Shared Library";
}
Compiling with:
g++ -shared -fPIC fooclass.cpp -o libfoo.so
Main:
main.cpp
#include "fooclass.h"
#include <iostream>
using namespace std;
int main(int argc, char const *argv[])
{
FooClass * fooClass = new FooClass();
cout<< fooClass->SayHello() << endl;
return 0;
}
Compiling with:
g++ -I. -L. -lfoo main.cpp -o main
The machine is an Ubuntu Linux 12
Thanks!
g++ -I. -L. -lfoo main.cpp -o main
is the problem. Recent versions of GCC require that you put the object files and libraries in the order that they depend on each other - as a consequential rule of thumb, you have to put the library flags as the last switch for the linker; i. e., write
g++ -I. -L. main.cpp -o main -lfoo
instead.
Related
I want to know how I can use a static library in C++ which I created, first the lib:
// header: foo.h
int foo(int a);
.
// code: foo.cpp
#include foo.h
int foo(int a)
{
return a+1;
}
then I compile the library first:
g++ foo.cpp
ar rc libfoo.a foo.o
now I want to use these library in some file like:
// prog.cpp
#include "foo.h"
int main()
{
int i = foo(2);
return i;
}
how must I compile these now?
I made:
g++ -L. -lfoo prog.cpp
but get an error because the function foo would not be found
You want:
g++ -L. prog.cpp -lfoo
Unfortunately, the ld linker is sensitive to the order of libraries. When trying to satisfy undefined symbols in prog.cpp, it will only look at libraries that appear AFTER prog.cpp on the command line.
You can also just specify the library (with a path if necessary) on the command line, and forget about the -L flag:
g++ prog.cpp libfoo.a
Consider the following setup consisting of two shared libraries which both use a static library:
static.cpp
#include "static.h"
static int a = 0;
int getA()
{
return a++;
}
static.h
#pragma once
int getA();
shareda.cpp
#include <iostream>
#include "shareda.h"
#include "static.h"
void printA()
{
std::cout << getA() << std::endl;
}
shareda.h
#pragma once
void printA();
sharedb.cpp
#include <iostream>
#include "sharedb.h"
#include "static.h"
void printB()
{
std::cout << getA() << std::endl;
}
sharedb.h
#pragma once
void printB();
main.cpp
#include "shareda.h"
#include "sharedb.h"
int main()
{
printA();
printA();
printB();
printA();
printB();
return 0;
}
I compiled and ran these files with the following commands (using Clang 3.8.0, compiled from source, and 64-bit Debian with GNU ld 2.25):
clang++ -c static.cpp -o static.o -fPIC
ar rcs libstatic.a static.o
clang++ -c shareda.cpp -o shareda.o -fPIC
clang++ -shared -o libshareda.so shareda.o libstatic.a
clang++ -c sharedb.cpp -o sharedb.o -fPIC
clang++ -shared -o libsharedb.so sharedb.o libstatic.a
clang++ -L. -lshareda -lsharedb -o main main.cpp
LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./main
To my surprise, the output was the following:
0
1
2
3
4
My expectation was this:
0
1
0
2
1
Apparently, despite the static keyword in front of a in static.cpp, only one instance of a exists. Is there a way to have two instances of a, one for each of the shared libraries?
Apparently, despite the static keyword in front of a in static.cpp, only one instance of a exists.
That is incorrect: two instances of a exist, but only one is actually used.
And that is happening because (contrary to your expectations) printB calls the first getA available to it (the one from libshareda.so, not the one from libsharedb.so). That is one major difference between UNIX shared libraries and Windows DLLs. UNIX shared libraries emulate what would have happened if your link was:
clang++ -L. -o main main.cpp shareda.o sharedb.o libstatic.a
So what can you do to "fix" this?
You could link libsharedb.so to prefer its own getA, by using -Bsymbolic.
You could hide getA inside libsharedb.so completely (as if it's a private implementation detail):
clang++ -c -fvisibility=hidden -fPIC static.cpp
ar rcs libstatic.a static.o
clang++ -shared -o libsharedb.so sharedb.o libstatic.a
You could achieve similar result using linker version script.
P.S. Your link command:
clang++ -L. -lshareda -lsharedb -o main main.cpp
is completely backwards. It should be:
clang++ -L. -o main main.cpp -lshareda -lsharedb
The order of sources/object files and libraries on command line matters, and libraries should follow object files that reference them.
This question already has answers here:
"undefined reference" when linking against a static library
(4 answers)
Closed 8 years ago.
my main.cpp:
#include <iostream>
int foo(int arg);
using namespace std;
int main()
{
int x = foo(22);
cout << x;
return 0;
}
compile command line (Ubuntu 13.10):
g++-4.8 -L. -lfoo main.cpp -o main_app
libfoo.a contains int foo(int)
but I always get the same compiler error:
/tmp/cciAyTSP.o: In function `main':
main.cpp:(.text+0x19): undefined reference to `foo(int)'
collect2: error: ld returned 1 exit status
Of course it's impossible to be sure without a reproducible case, but a common error is that if the function foo is written in C then you need to put
extern "C" { int foo(int); }
in the .h file for the C++ program to let it know that the function was not written in C++.
To write a cross-language header file that will be good for both C and C++ the common approach is
#ifdef __cplusplus
extern "C" {
#endif
... C declarations ...
#ifdef __cplusplus
}
#endif
In addition to 6502's answer and Xephon's suggestion, also be aware that the order of the options matter. Instead of:
g++-4.8 -L. -lfoo main.cpp -o main_app
You should write:
g++-4.8 main.cpp -o main_app -L. -lfoo
That's because ld is a single pass linker. It won't revisit library libfoo to use a symbol from it for main_app.o.
I have a question about making static libraries that use other static libraries.
I set up an example with 3 files - main.cpp, slib1.cpp and slib2.cpp. slib1.cpp and slib2.cpp are both compiled as individual static libraries (e.g. I end up with slib1.a and slib2.a) main.cpp is compiled into a standard ELF executable linked against both libraries.
There also exists a header file named main.h which prototypes the functions in slib1 and slib2.
main.cpp calls a function called lib2func() from slib2. This function in turn calls lib1func() from slib1.
If I compile the code as is, g++ will return with a linker error stating that it could not find lib1func() in slib1. However, if I make a call to lib1func() BEFORE any calls to any functions in slib2, the code compiles and works correctly.
My question is simply as follows: is it possible to create a static library that depends on another static library? It would seem like a very severe limitation if this were not possible.
The source code for this problem is attached below:
main.h:
#ifndef MAIN_H
#define MAIN_H
int lib1func();
int lib2func();
#endif
slib1.cpp:
#include "main.h"
int lib1func() {
return 1;
}
slib2.cpp:
#include "main.h"
int lib2func() {
return lib1func();
}
main.cpp:
#include <iostream>
#include "main.h"
int main(int argc, char **argv) {
//lib1func(); // Uncomment and compile will succeed. WHY??
cout << "Ans: " << lib2func() << endl;
return 0;
}
gcc output (with line commented out):
g++ -o src/slib1.o -c src/slib1.cpp
ar rc libslib1.a src/slib1.o
ranlib libslib1.a
g++ -o src/slib2.o -c src/slib2.cpp
ar rc libslib2.a src/slib2.o
ranlib libslib2.a
g++ -o src/main.o -c src/main.cpp
g++ -o main src/main.o -L. -lslib1 -lslib2
./libslib2.a(slib2.o): In function `lib2func()':
slib2.cpp:(.text+0x5): undefined reference to `lib1func()'
collect2: ld returned 1 exit status
gcc output (with line uncommented)
g++ -o src/slib1.o -c src/slib1.cpp
ar rc libslib1.a src/slib1.o
ranlib libslib1.a
g++ -o src/slib2.o -c src/slib2.cpp
ar rc libslib2.a src/slib2.o
ranlib libslib2.a
g++ -o src/main.o -c src/main.cpp
g++ -o main src/main.o -L. -lslib1 -lslib2
$ ./main
Ans: 1
Please, try g++ -o main src/main.o -L. -Wl,--start-group -lslib1 -lslib2 -Wl,--end-group.
Group defined with --start-group, --end-group helps to resolve circular dependencies between libraries.
See also: GCC: what are the --start-group and --end-group command line options?
The order make the difference. Here's from gcc(1) manual page:
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.
I try to write a wrapper class for leveldb. Basically the part of the header file which generates my problem is (CLevelDBStore.h:)
#include "leveldb/db.h"
#include "leveldb/comparator.h"
using namespace leveldb;
class CLevelDBStore {
public:
CLevelDBStore(const char* dbFileName);
virtual ~CLevelDBStore();
/* more stuff */ 67 private:
private:
CLevelDBStore();
static leveldb::DB* ldb_;
};
The corresponding code in the CLevelDBStore.cpp file is:
#include "CLevelDBStore.h"
DB* CLevelDBStore::ldb_;
CLevelDBStore::CLevelDBStore(const char* dbFileName) {
Options options;
options.create_if_missing = true;
DB::Open((const Options&)options, (const std::string&) dbFileName, (DB**)&ldb_);
Status status = DB::Open(options, dbFileName);
}
I now try to compile my test file (test.cpp), which basically is
#include "leveldb/db.h"
#include "leveldb/comparator.h"
#include "CLevelDBStore.h"
int main() {
std::cout << "does not compile" << std::endl;
return 0;
}
Note, I don't even use the wrapper class yet. It's just to generate the compilation error.
The compilation
g++ -Wall -O0 -ggdb -c CLevelDBStore.cpp -I/path/to/leveldb/include
g++ -Wall test.cpp -O0 -ggdb -L/path/to/leveldb -I/path/to/leveldb/include \
-lleveldb -Wall -O2 -lz -lpthread ./CLevelDBStore.o -llog4cxx \
-o levelDBStoretest
yields
CLevelDBStore.cpp:27: undefined reference to `leveldb::DB::Open(leveldb::Options const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, leveldb::DB**)'
I looked at the leveldb code where leveldb::DB::Open is defined and it turned out to be a static method.
class DB {
public:
static Status Open(const Options& options,
const std::string& name,
DB** dbptr);
/* much more stuff */
}
Could this somehow generated problemes when linking?
I think this is library link order. Try placing -leveldb after CLevelDBStore.o:
g++ -Wall test.cpp -O0 -ggdb -L/path/to/leveldb -I/path/to/leveldb/include
-Wall -O2 ./CLevelDBStore.o -lleveldb -lz -lpthread -llog4cxx
-o levelDBStoretest
From GCC Options for Linking:
-llibrary
Search the library named library when linking. It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o' searches libraryz' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be loaded.