Using dlopen/dlsym to open C++ shared library - dlsym returns NULL

Question

I have not yet dealt with shared libraries in C++, and am having some trouble. I want to create a shared library and then have a C function pick up on that library. So here is my shared library file:

extern int nothing();
//sym.cpp
int nothing() {
    return 0;
}

Below is my dlopen/dlsym script:

//symtest.c
#include <stdio.h>
#include <dlfcn.h>
int main(){
    void *handle;
    handle = dlopen("/path/to/lib/sym.so",RTLD_NOW);
    int (*onload)(void *, void **, int);
    onload = (int (*)(void *, void **, int))(unsigned long) dlsym(handle,"nothing");
    if(onload==NULL) {
        printf("NULL");
    }
    return 0;
}

Compile and ran as following:

$ g++ -shared -fPIC -o sym.so sym.cpp
$ gcc symtest.c -ldl -o symtest
$ ./symtest
NULL

Why am I getting NULL? I am pretty sure this symbol is getting exported, at least by observing the output of the following commands.

nm:

$ nm -CD sym.so | grep " T "                        
0000000000000670 T nothing()
000000000000067c T _fini
0000000000000518 T _init

objdump:

$ objdump -T sym.so 

sym.so:     file format elf64-x86-64

DYNAMIC SYMBOL TABLE:
0000000000000518 l    d  .init  0000000000000000              .init
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000              _Jv_RegisterClasses
0000000000000000  w   D  *UND*  0000000000000000              _ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000              _ITM_registerTMCloneTable
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.2.5 __cxa_finalize
0000000000200970 g    D  .bss   0000000000000000  Base        _end
0000000000200968 g    D  .got.plt   0000000000000000  Base        _edata
0000000000200968 g    D  .bss   0000000000000000  Base        __bss_start
0000000000000518 g    DF .init  0000000000000000  Base        _init
000000000000067c g    DF .fini  0000000000000000  Base        _fini
0000000000000670 g    DF .text  000000000000000b  Base        _Z7nothingv

There is a bigger picture here (Creating C++ Redis Module - "does not export RedisModule_OnLoad() symbol") but I looked through some Redis source code to produce a minimalistic example. Anyone have any idea what I am doing wrong here?

As requested, nm without -C option:

$ nm -D sym.so
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 w _Jv_RegisterClasses
0000000000000670 T _Z7nothingv
0000000000200968 B __bss_start
                 w __cxa_finalize
                 w __gmon_start__
0000000000200968 D _edata
0000000000200970 B _end
000000000000067c T _fini
0000000000000518 T _init

Did you make `int nothing()` extern "C" ? Why you do not validate `handle`? — Slava, May 17 '18 at 17:49
You'll need to specify the mangled name `_Z7nothingv` -- I think? — G.M., May 17 '18 at 17:51
And what is the output if you remove the `-C` option from `nm` - the option that *demangles* C++ function names? — Andrew Henle, May 17 '18 at 18:01
@Slava I added an `extern int nothing();` at the top of my file. I edited my question to reflect that. Same issue, however. (Unless I am doing it wrong) — Sidd Singal, May 17 '18 at 18:05
I mean extern "C" not just extern, have you heard about name mangling in C++? — Slava, May 17 '18 at 18:07
@SiddSingal And in that new `nm` output, do you see any `nothing` symbol? Look up [C++ name mangling](https://en.wikipedia.org/wiki/Name_mangling). — Andrew Henle, May 17 '18 at 18:08
You have to supply C-style linkage to work with C code - and in general it is not only mangling, but ABI as well — Severin Pappadeux, May 17 '18 at 18:08
@Slava I have not. Am I going to do this: https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzarg/name_mangling.htm ? — Sidd Singal, May 17 '18 at 18:08
A note: you should be aware that C++ doesn't work well together with _(insert any technology here)._ If you can write your plugins in plain C, just do that. — Lorinczy Zsigmond, May 17 '18 at 18:48
As an aside, if you want `dlopen`/`dlsym`-like functionality with `C++` you might want to take a look at [`boost::dll`](https://www.boost.org/doc/libs/1_67_0/doc/html/boost_dll.html). — G.M., May 18 '18 at 08:20

score 2 · Accepted Answer · answered May 17 '18 at 18:40

C++ has function overloading so there can be multiple functions with the same name and just different parameters.

Since object files store only names, C++ applies what is called name mangling. It adds extra symbols representing email parameters the name to differentiate between different versions.

When using dlsym, one must use the mangled name to get at the function address.

Now since name mangling is platform specific it is often better to use C linkage (no name mangling)

This can be done with the extern "C" declaration.

Using dlopen/dlsym to open C++ shared library - dlsym returns NULL

1 Answers1