I have an application that loads a library with dlopen, it looks like this:
#include <iostream>
#include <dlfcn.h>
void foo()
{
std::cout << "foo";
}
int main()
{
void* libbar = dlopen("./libbar.so", RTLD_LAZY);
if (!libbar)
{
std::cerr << dlerror() << std::endl;
return 1;
}
void(*bar)() = (void(*)())dlsym(libbar, "bar");
if (!bar)
{
std::cerr << dlerror() << std::endl;
return 1;
}
bar();
dlclose(libbar);
}
And here is libbar:
#include <iostream>
void foo();
extern "C"
void bar()
{
foo();
std::cout << "bar" << std::endl;
}
Output:
./libbar.so: undefined symbol: _Z3foov
Expected output:
foobar
How to make foo visible to libbar?
I'm actually using C++ and the real problem is with undefined symbols from constructors/member functions, but this should be very similar. I'm working on Linux with GCC 4.7.
You should compile and link main.cc with
g++ -rdynamic -Wall main.cc -o prog -ldl
The -rdynamic flag is important at link time.
And you'll better declare extern "C" those functions which you want to pass to dlsym.
See also the Program Library HowTo.
Related
… or is it enough to declare them at the module interface unit?
test.cpp:
module;
#include <iostream>
export module M;
export
template<typename>
class T
{
public:
void foo() const
{ std::cout << "T" << std::endl; }
};
// export <-- NOT exported
template<>
class T<int>
{
public:
void foo() const
{ std::cout << "T<int>" << std::endl; }
};
main.cpp:
import M;
int main()
{
T<int> x;
x.foo();
return 0;
}
Output:
$ rm -f gcm.cache/* && $(HOME)/gcc-master/bin/g++ -O3 -fmodules-ts test.cpp main.cpp -o foo && ./foo
T<int>
$ $(HOME)/gcc-master/bin/g++ --version
g++ (GCC) 11.0.0 20210128 (experimental)
Exporting affects only name lookup and linkage. Neither of those is relevant to any kind of template specialization or instantiation, so they never need exporting.
This question already has answers here:
Why full specialization of template function is not picked up from the .cpp file without declaration?
(3 answers)
Closed 4 years ago.
Here's my program:
print.hpp:
#pragma once
#include <iostream>
template<size_t p>
void print()
{
std::cout << "" << __FILE__ << "" << __LINE__ << "" << std::endl;
exit(0);
}
print.cpp:
#include "print.hpp"
template<>
void print<13>()
{
std::cout << "Unlucky." << std::endl;
}
main.cpp:
#include <iostream>
#include "print.hpp"
int main()
{
std::cout << "Started." << std::endl;
print<13>();
std::cout << "Exiting." << std::endl;
}
When I compile that with g++ main.cpp print.cpp -O0 -std=c++11 && ./a.out it works fine (output is:
Started.
Unlucky.
Exiting.
).
However, if'd I compile that with g++ main.cpp print.cpp -O1 -std=c++11 && ./a.out it would give me a segmentation fault with the output:
Started.
Unlucky.
Speicherzugriffsfehler //German for memory access error
Almost the same with clang++, without optimization it would do its job just fine
and with -O1 or higher it outputs that:
Started.
Unlucky.
./print.hpp8
Why is that?
You need to declare the template specialization in the .hpp file.
template<size_t p>
void print()
{
std::cout << "" << __FILE__ << "" << __LINE__ << "" << std::endl;
exit(0);
}
// Declare the specialization.
template<> void print<13>();
Without the declaration in the .hpp file, I get a linker error with g++ 6.4.0.
.../Local/Temp/cctCC5MK.o:print.cc:(.text+0x0): multiple definition of `void print<13ul>()'
.../Local/Temp/ccgodRUG.o:socc.cc:(.text$_Z5printILm13EEvv[_Z5printILm13EEvv]+0x0): first defined here
collect2: error: ld returned 1 exit status
I am not sure how you are able to successfully build your program without the declaration.
I have problem when compiling code below on aix machine with gcc compiler (version 4.7.3):
SomeThread.h
#ifndef SomeThread_H
#define SomeThread_H
class SomeThread {
public:
SomeThread(void);
virtual ~SomeThread(void);
void runThread();
}; // SomeThread
#endif // _SomeThread_H_
SomeThread.cpp
#include "SomeThread.h"
#include <thread>
#include <iostream>
using namespace std;
namespace {
void foo_thread_function() {
for (int i = 0; i < 10; ++i) {
cout << "Some threaded text" << endl;
}
}
}
SomeThread::SomeThread() {
} // SomeThread
SomeThread::~SomeThread() {
} // ~SomeThread
void SomeThread::runThread() {
thread foo_thread_01(foo_thread_function);
thread foo_thread_02(foo_thread_function);
thread foo_thread_03(foo_thread_function);
foo_thread_01.join();
foo_thread_02.join();
foo_thread_03.join();
}
The error which I get is following:
SomeThread.cpp: In member function 'void SomeThread::runThread()':
SomeThread.cpp:58:4: error: reference to 'thread' is ambiguous
In file included from /usr/include/sys/ptrace.h:28:0,
from /usr/include/sys/proc.h:42,
from /usr/include/sys/pri.h:43,
from /usr/include/sys/sched.h:38,
from /usr/include/sched.h:51,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include-fixed/pthread.h:76,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/powerpc-ibm-aix7.1.0.0/pthread/ppc64/bits/gthr-posix.h:41,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/powerpc-ibm-aix7.1.0.0/pthread/ppc64/bits/gthr-default.h:30,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/powerpc-ibm-aix7.1.0.0/pthread/ppc64/bits/gthr.h:150,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/ext/atomicity.h:34,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/memory:75,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/thread:40,
from SomeThread.cpp:5:
/usr/include/sys/thread.h:105:8: error: candidates are: struct thread
In file included from SomeThread.cpp:5:0:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/thread:60:9: error: class std::thread
SomeThread.cpp:58:11: error: expected ';' before 'foo_thread_01'
SomeThread.cpp:59:4: error: reference to 'thread' is ambiguous
In file included from /usr/include/sys/ptrace.h:28:0,
from /usr/include/sys/proc.h:42,
from /usr/include/sys/pri.h:43,
from /usr/include/sys/sched.h:38,
from /usr/include/sched.h:51,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include-fixed/pthread.h:76,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/powerpc-ibm-aix7.1.0.0/pthread/ppc64/bits/gthr-posix.h:41,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/powerpc-ibm-aix7.1.0.0/pthread/ppc64/bits/gthr-default.h:30,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/powerpc-ibm-aix7.1.0.0/pthread/ppc64/bits/gthr.h:150,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/ext/atomicity.h:34,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/memory:75,
from /opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.7.3/include/c++/thread:40,
from SomeThread.cpp:5:
I compile the above files with following command line:
g++ -maix64 -DTARGET=target_thread -DGENDATE=04_01_2017 -DTT_LIB_DLLSUFFIX=\".so\" -DOSNAME=\"AIX\" -D_GNU_SOURCE -D_REENTRANT -DAIX -Wno-deprecated -I. -std=gnu++11 -maix64 -pthread -mminimal-toc -fpermissive -Wno-write-strings -Winvalid-offsetof -O3 -c -oSomeThread.o SomeThread.cpp
The problem is, that there are multiple implementations of thread with your compiler options and includes. Maybe it would be just enough to correct the code to this.
SomeThread.cpp
#include "SomeThread.h"
#include <thread>
#include <iostream>
//Stop using namespace std, please
namespace SomeNamespace {
void foo_thread_function() {
for (int i = 0; i < 10; ++i) {
cout << "Some threaded text" << endl;
}
}
}
SomeThread::SomeThread() {
} // SomeThread
SomeThread::~SomeThread() {
} // ~SomeThread
void SomeThread::runThread() {
std::thread foo_thread_01(SomeNamespace::foo_thread_function);
std::thread foo_thread_02(SomeNamespace::foo_thread_function);
std::thread foo_thread_03(SomeNamespace::foo_thread_function);
foo_thread_01.join();
foo_thread_02.join();
foo_thread_03.join();
}
Ambiguous means that there are multiple interpretations of the same word.
Example:
namespace Bla{
struct SomeStruct{
}
}
namespace Blub{
struct SomeStruct{
}
}
int main(){
using namespace Bla;
using namespace Blub;
SomeStruct ImAmbiguous; // Problem now, which struct should the compiler choose now?
Bla::SomeStruct structFromBla; //Now the compiler knows which struct should be choosen
return 0;
}
Using g++, when two compilation units "a1.o" and "a2.o" both define and use the same weak symbol, the linker will silently resolve to the first occurrence of the symbol wherever it is used. As a result, the behavior of the application will depend on the order of the object files on the linker command line. What can be done to ensure that these symbols are resolved locally to each compilation unit?
For instance, as a minimalist example, if I have the following source files:
a1.cpp:
#include <iostream>
struct A
{
void foo() {std::cerr << __FILE__ << std::endl;}
};
void bar1() {A a; a.foo();}
a2.cpp:
#include <iostream>
struct A
{
void foo() {std::cerr << __FILE__ << std::endl;}
};
void bar2() {A a; a.foo();}
main.cpp:
void bar1();
void bar2();
int main()
{
bar1();
bar2();
}
and compile them with:
for i in a1 a2 main ; do g++ -c -o $i.o $i.cpp ; done
The output will depend on the relative position of a1.o and a2.o on the linker command line:
g++ -o main main.o a{1,2}.o ; ./main
a1.cpp
a1.cpp
g++ -o main main.o a{2,1}.o ; ./main
a2.cpp
a2.cpp
I'd like to get the same result as if using the '-fno-weak' command line option:
for i in a1 a2 main ; do g++ -fno-weak -c -o $i.o $i.cpp ; done
g++ -o main main.o a{1,2}.o ; ./main
a1.cpp
a2.cpp
but '-fno-weak' seems to lead to other complications. What are the alternatives (besides not inlining and fixing collisions)?
For those wondering what could be a typical use case: when writing mock components it is sometimes convenient to have header-only implementations. Different test fixtures end-up having different mock implementations of the same component type, which becomes an issue when all the fixtures are linked into a single test runner.
You asked:
What are the alternatives (besides not inlining and fixing collisions)?
Use local namespaces or anonymous namespaces.
a1.cpp:
#include <iostream>
namespace A1_namespace
{
struct A
{
void foo() {std::cerr << __FILE__ << std::endl;}
};
}
using namespace A1_namespace;
void bar1() {A a; a.foo();}
or
#include <iostream>
namespace
{
struct A
{
void foo() {std::cerr << __FILE__ << std::endl;}
};
}
void bar1() {A a; a.foo();}
Make similar changes to a2.cpp.
Is it possible to have a unique address allocated for a constexpr variable, i.e. the same for all translation units where the variable is available (usually through a header)? Consider the following example:
// foo.hh
#include <iostream>
constexpr int foo = 42;
// a.cc
#include "foo.hh"
void a(void) { std::cout << "a: " << &foo << std::endl; }
// b.cc
#include "foo.hh"
extern void a(void);
int main(int argc, char** argv) {
a();
std::cout << "b: " << &foo << std::endl;
}
Compiling a.cc and b.cc separately, and linking them together using gcc 4.7, I see two different addresses printed. If I add the keyword extern in the header, I get a linker error duplicate symbol _foo in: a.o and b.o which I find kind of surprising, because I thought that adding extern would more likely cause the compiler to import that symbol from another object instead of exporting it from the current object. But it seems my understanding of how things work was wrong here.
Is there a reasonable way to have a constexpr declared in one header, such that all translation units can use it in their constant expressions, and such that all translation units agree as to the address of that symbol? I would expect some additional code to denote the single translation unit where this symbol actually belongs to, just like with extern and non-extern variables without constexpr.
If you need to take the address of constexpr variable, declare it as a static member variable. It can be used as a constant expression this way (as opposed to using a function returning a const).
foo.h:
#ifndef FOO_H
#define FOO_H
struct Foo {
static constexpr int foo { 42 }; // declaration
};
#endif // FOO_H
foo.cpp:
#include "foo.hpp"
constexpr int Foo::foo; // definition
bar.cpp:
#include "foo.hpp"
const int* foo_addr() {
return &Foo::foo;
}
int foo_val() {
return Foo::foo;
}
main.cpp:
#include <iostream>
#include "foo.hpp"
extern const int* foo_addr();
extern int foo_val();
constexpr int arr[Foo::foo] {}; // foo used as constant expression
int main() {
std::cout << foo_addr() << " = " << foo_val() << std::endl;
std::cout << &Foo::foo << " = " << Foo::foo << std::endl;
}
Output:
$ g++ -std=c++11 foo.cpp bar.cpp main.cpp -o test && ./test
0x400a44 = 42
0x400a44 = 42
C++17 inline variables
This awesome C++17 feature allow us to:
conveniently use just a single memory address for each constant
store it as a constexpr: How to declare constexpr extern?
do it in a single line from one header
main.cpp
#include <cassert>
#include "notmain.hpp"
int main() {
// Both files see the same memory address.
assert(¬main_i == notmain_func());
assert(notmain_i == 42);
}
notmain.hpp
#ifndef NOTMAIN_HPP
#define NOTMAIN_HPP
inline constexpr int notmain_i = 42;
const int* notmain_func();
#endif
notmain.cpp
#include "notmain.hpp"
const int* notmain_func() {
return ¬main_i;
}
Compile and run:
Compile and run:
g++ -c -o notmain.o -std=c++17 -Wall -Wextra -pedantic notmain.cpp
g++ -c -o main.o -std=c++17 -Wall -Wextra -pedantic main.cpp
g++ -o main -std=c++17 -Wall -Wextra -pedantic main.o notmain.o
./main
GitHub upstream.
See also: How do inline variables work?
C++ standard on inline variables
The C++ standard guarantees that the addresses will be the same. C++17 N4659 standard draft
10.1.6 "The inline specifier":
6 An inline function or variable with external linkage shall have the same address in all translation units.
cppreference https://en.cppreference.com/w/cpp/language/inline explains that if static is not given, then it has external linkage.
Inline variable implementation
We can observe how it is implemented with:
nm main.o notmain.o
which contains:
main.o:
U _GLOBAL_OFFSET_TABLE_
U _Z12notmain_funcv
0000000000000028 r _ZZ4mainE19__PRETTY_FUNCTION__
U __assert_fail
0000000000000000 T main
0000000000000000 u notmain_i
notmain.o:
0000000000000000 T _Z12notmain_funcv
0000000000000000 u notmain_i
and man nm says about u:
"u" The symbol is a unique global symbol. This is a GNU extension to the standard set of ELF symbol bindings. For such a symbol the dynamic linker will make sure that in the entire process
there is just one symbol with this name and type in use.
so we see that there is a dedicated ELF extension for this.
I think constexpr is meant more for functions whose return value is constant. You can bind a constant variable to the return value of a constexpr function and expose that externally instead. For example:
// constexpr.h
#ifndef __CONSTEXPR_H
#define __CONSTEXPR_H
extern const int foo;
#endif // __CONSTEXPR_H
// constexpr.cpp
#include "constexpr.h"
constexpr int foo_expr()
{
return 42;
}
const int foo = foo_expr();
// unit1.cpp
#include <iostream>
#include "constexpr.h"
void unit1_print_foo()
{
std::cout << &foo << " = " << foo << std::endl;
}
// unit2.cpp
#include <iostream>
#include "constexpr.h"
void unit2_print_foo()
{
std::cout << &foo << " = " << foo << std::endl;
}
// main.cpp
extern void unit1_print_foo();
extern void unit2_print_foo();
int main(int, char**)
{
unit1_print_foo();
unit2_print_foo();
}
My result is:
$ g++-4.7 -std=c++11 constexpr.cpp unit1.cpp unit2.cpp main.cpp -o test && ./test
0x400ae4 = 42
0x400ae4 = 42
However, it should usually be sufficient to make the foo_expr function itself externally visible, and callers would use foo_expr() to get the value instead of treating it like a variable.