Is there symbol conflict when loading two shared libraries with a same symbol

Question

An application (app) depends on two shared librarys: liba.so and libb.so.
liba and libb have the same function of void Hello() but with different implementations. Load the two shared libraries at runtime and try to access the two versions of Hello().
I load liba.so and libb.so by poco C++ shared-library, but eventually it calls dlopen() to load shared libraries. Here's the code:

#include "Poco/SharedLibrary.h"
using Poco::SharedLibrary;
typedef void (*HelloFunc)(); // function pointer type


int main(int argc, char** argv)
{
    std::string path("liba");
    path.append(SharedLibrary::suffix()); // adds ".so"
    SharedLibrary library(path);
    HelloFunc func = (HelloFunc) library.getSymbol("hello");
    func();

    std::string path2("libb");
    path2.append(SharedLibrary::suffix()); // adds ".so"
    SharedLibrary library2(path2);
    HelloFunc func2 = (HelloFunc) library2.getSymbol("hello");
    func2();

    library.unload();
    library2.unload();

    return 0;
}

My question is, when app loads liba.so and libb.so by dlopen(), will there be any symbol conflict for the two Hello() implementations?
In fact, the code goes well, but I wonder whether there's any potential risk to load libraries like that.

Answer 1

My question is, when app loads liba.so and libb.so by dlopen(), will there be any symbol conflict for the two Hello() implementations?

There is none. These are addresses returned, and both dynamically loaded libraries will live in a separate address space.

Even the dlsym function cannot be confused since you pass the handle returned by the dlopen function, so it would not by any mean become ambiguous.

(This would not even be an issue with overloading within the same library, respectively)