Overriding functions from dynamic libraries - gcc

Hello I have a program with a global function that I'd like to customize at run time. Say, there are many versions of function foo() scattered over shared libraries. Now, based on system configuration detected at run time I'd like to use function from appropriate library.
File loader.cpp:
#include <dlfcn.h>
#include <iostream>
void __attribute__((weak)) foo();
int main(int argc, char *argv[])
{
void* dl = dlopen("./other.so", RTLD_NOW | RTLD_GLOBAL);
if (!dl)
{
std::cerr << dlerror() << std::endl;
return 1;
}
if (foo)
{
foo();
}
else
{
std::cerr << "No foo?" << std::endl;
}
dlclose(dl);
return 0;
}
File other.cpp:
#include <iostream>
void foo()
{
std::cout << "FOO!" << std::endl;
}
I compile the program with
g++ -Wall -fPIC -o loaded loader.cpp -ldl
g++ -Wall -fPIC -shared -o other.so other.cpp
However the weak symbol is not overriden. Any hints?

Symbols are resolved during load time of the image in which they are referenced. So when your executable is loaded, the reference to foo is already resolved. A later dlopen won't go and rebind all symbols - it only may affect later loads.
You'll have to use dlsym instead, or set LD_PRELOAD:
martin#mira:/tmp$ LD_PRELOAD=/tmp/other.so ./loaded
FOO!

You compiled the shared lib with g++.
As a result, the name of the function is mangled:
$ nm -S other.so |grep foo
0000000000000690 000000000000002e T _Z3foov
If you make it a pure C code and compile with
gcc instead of g++, you'll find it working as you expect.
Alternatively, define it as follows:
extern "C" void foo()
{
std::cout << "FOO!" << std::endl;
}

Related

std::async blocks even with std::launch::async flag depending on whether the returned future is used or ignored [duplicate]

This question already has an answer here:
Why C++ async run sequentially without future?
(1 answer)
Closed 2 years ago.
Description of the problem
std::async seems to block even with std::launch::async flag:
#include <iostream>
#include <future>
#include <chrono>
int main(void)
{
using namespace std::chrono_literals;
auto f = [](const char* s)
{
std::cout << s;
std::this_thread::sleep_for(2s);
std::cout << s;
};
std::cout << "start\n";
(void)std::async(std::launch::async, f, "1\n");
std::cout << "in between\n";
(void)std::async(std::launch::async, f, "2\n");
std::cout << "end\n";
return 0;
}
output shows that the execution is serialized. Even with std::launch::async flag.
start
1
1
in between
2
2
end
But if I use returned std::future, it suddenly starts to not block!
The only change I made is removing (void) and adding auto r1 = instead:
#include <iostream>
#include <future>
#include <chrono>
int main(void)
{
using namespace std::chrono_literals;
auto f = [](const char* s)
{
std::cout << s;
std::this_thread::sleep_for(2s);
std::cout << s;
};
std::cout << "start\n";
auto r1 = std::async(std::launch::async, f, "1\n");
std::cout << "in between\n";
auto r2 = std::async(std::launch::async, f, "2\n");
std::cout << "end\n";
return 0;
}
And, the result is quite different. It definitely shows that the execution is in parallel.
start
in between
1
end
2
1
2
I used gcc for CentOS devtoolset-7.
gcc (GCC) 7.2.1 20170829 (Red Hat 7.2.1-1)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
My Makefile is:
.PHONY: all clean
all: foo
SRCS := $(shell find . -name '*.cpp')
OBJS := $(SRCS:.cpp=.o)
foo: $(OBJS)
gcc -o $# $^ -lstdc++ -pthread
%.o: %.cpp
gcc -std=c++17 -c -g -Wall -O0 -pthread -o $# $<
clean:
rm -rf foo *.o
Question
Is this behaviour in the specification?
Or is it a gcc implementation bug?
Why does this happen?
Can someone explain this to me, please?
The std::future destructor will block if it’s a future from std::async and is the last reference to the shared state. I believe what you’re seeing here is
the call to async returns a future, but
that future is not being captured, so
the destructor for that future fires, which
blocks, causing the tasks to be done in serial.
Explicitly capturing the return value causes the two destructors to fire only at the end of the function, which leaves both tasks running until they’re done.

Can I use "this" with delegating constructors?

C++11 introduced the possibility of delegating construction from one constructor to another - "delegating constructors".
But - when doing that, can we use the this pointer? e.g. as an argument to one of the constructors we're delegating to? It's not trivial to assume that we can while the "real constructor" has not actually been invoked yet.
For a definitive answer one would need to read the standard (and even there it might not be entirely clear, see #BenjaminBanner's comment). But in practice - yes, apparently we can use this in constructor delegation.
The following example:
#include <iostream>
struct A {
A(int x_, void* p_) : x(x_), p(p_) { }
A(void* p_) : A(0, p_) { }
A() : A(this) { }
int x;
void* p;
};
int main() {
A a;
std::cout << "&a == " << &a << "\n";
std::cout << "a.p == " << a.p << "\n";
}
compiles (GodBolt) with all of GCC, clang and MSVC. They do not warn about doing this, even with -Wall -Wpedantic -Wextra or /W4 for MSVC.
It also runs (coliru.com) and produces the expected output (at the link you have the g++-compiled version, clang++ can be checked there as well).

EIGEN library with MKL rvalue references warning

I am trying to the use the EIGEN library linked with the MKL library (icc version 17.0.4) with the code:
#define EIGEN_USE_MKL_ALL
#define lapack_complex_float std::complex<float>
#define lapack_complex_double std::complex<double>
#include <iostream>
#include <Eigen/Dense>
#include <Eigen/Eigenvalues>
#include <complex>
#include <Eigen/PardisoSupport>
using namespace Eigen;
using Eigen::MatrixXd;
int main()
{
int size = 3;
MatrixXd A(size,size);
A(0,0)=1.0; A(0,1)=-0.5; A(0,2)=0.2;
A(1,0)=0.7; A(1,1)=-1.3; A(1,2)=-2.0;
A(2,0)=0.7; A(2,1)=-1.3; A(2,2)=-2.0;
std::cout << A << std::endl;
VectorXd vec(3);
vec(0) = 2;
vec(1) = 3;
vec(2) = 4;
std::cout << A*vec << "\n";
std::cout << A.eigenvalues() << "\n";
}
I compile via
icc -I${MKLROOT}/include -L${MKLROOT}/lib -Wl,-rpath,${MKLROOT}/lib \
-lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lpthread -lm -ldl \
-L/Users/user/eigen -I/Users/user/eigen
However I receive the error message:
/Users/user/eigen/Eigen/src/Core/DenseStorage.h(372): warning #3495: rvalue references
are a C++11 feature DenseStorage(DenseStorage&& other) EIGEN_NOEXCEPT
How to solve this warning?
Eigen seems to detect that your compiler supports rvalue references. You can either disable that by defining -DEIGEN_HAS_RVALUE_REFERENCES=0 via the command line or before including Eigen in your source by:
#define EIGEN_HAS_RVALUE_REFERENCES 0
Preferably, tell icc that it shall compile with C++11 support (I assume -std=c++11 works for icc as well).

GCC ignores calling convention attribute

does anyone know why this doesnt work?
void test() [[stdcall]] {
std::cout << "Hello World" << std::endl;
}
when I try to compile with C++11 dialect it says:
"warning: 'stdcall' attribute directive ignored [-Wattributes]"
Why is that? I have a function that really needs to have the stdcall calling convention. The default calling convention in GCC is cdecl. Any suggestions?
The following should work:
#include <iostream>
[[gnu::stdcall]]
void test()
{
std::cout << "Hello World" << std::endl;
}
or you can use the old syntax __attribute__((stdcall)). Compiling with g++ -std=c++11 -m32 I get no warning.

SDL2: undefined references to strange functions

i have written this small piece of Code for testing purposes:
#include <iostream>
#include "SDL2/SDL.h"
int main(int argc, char* argv[]) {
if (SDL_Init(SDL_INIT_EVERYTHING) != 0) {
printf("Unable to initialize SDL: %s\n", SDL_GetError());
return 1;
}
// Betriebssystem ermitteln
std::string PlatFormString;
PlatFormString = SDL_GetPlatform();
std::cout << PlatFormString << "\n";
// Separator ermitteln
char Separator = '/';
if (PlatFormString == "Windows") {
Separator = '\\';
}
std::cout << "Separator: " << Separator << "\n";
// Installationspfad ermitteln
std::string InstallPath;
InstallPath = SDL_GetBasePath();
std::cout << InstallPath << "\n";
// Benutzerverzeichnis ermitteln
char* UserPath;
UserPath = SDL_GetPrefPath("TFF", "Blaster");
if (UserPath == nullptr) {
std::cout << "No Userpath aviable !! \n";
}
else {
std::cout << UserPath << "\n";
}
SDL_Quit();
return 0;
};
Under Linux eerthing works fine.
But under Windows, i am getting these strange errors ...
-------------- Build: Debug in Test (compiler: GNU GCC Compiler)---------------
g++.exe -LD:\mingw64 -LD:\mingw64\bin -LD:\mingw64\include -LD:\mingw64\include\SDL2 -LD:\mingw64\lib -o bin\Debug\Test.exe obj\Debug\src\Test.o -lmingw32 -lSDL2main -lSDL2 -lSDL2_image -lSDL2_mixer ..\..\mingw64\lib\libSDL2main.a ..\..\mingw64\lib\libSDL2.a
..\..\mingw64\lib\libSDL2.a(SDL_systimer.o): In function `timeSetPeriod':
/Users/slouken/release/SDL/SDL2-2.0.3-source/foo-x64/../src/timer/windows/SDL_systimer.c:58: undefined reference to `__imp_timeBeginPeriod'
/Users/slouken/release/SDL/SDL2-2.0.3-source/foo-x64/../src/timer/windows/SDL_systimer.c:52: undefined reference to `__imp_timeEndPeriod'
/Users/slouken/release/SDL/SDL2-2.0.3-source/foo-x64/../src/timer/windows/SDL_systimer.c:58: undefined reference to `__imp_timeBeginPeriod'
and so on. I dont know whats going on there. Can anyone help ?
I#m using Codeblocks 13.12, minGW64 (4.8.1), SDL 2.0.3 and Windows 7 64bit
You need to link against winmm.lib.
Try adding
#pragma comment(lib, "winmm.lib")
to your source.
I am posting this about a year later but for the future searchers here is the solution. Replace libSDL2.a with libSDL2.dll.a and it will compile just fine. The issue has something to do with dynamic and static linking with a windows machine or something I personally do I understand it completely but it works.
I came across the solution by reading this article: http://tech.yipp.ca/sdl/how-to-fix-libsdla-undefined-reference/
However this goes on a whole other solution I read between the lines or more particularly.
This is a really a rare problem that would occur only when you try to link with libSDL.a static library instead of the dynamic library SDL.dll. Then you have to add those library that SDL.dll normally links against which are the three above.

Resources