Ubuntu 16.0.2下64位共享库dlopen加载失败求助

Alright, let's figure out why your dlopen call is failing even after you've copied the 64-bit shared library to /usr/local/lib and updated the linker cache with ldconfig. I'll walk you through step-by-step troubleshooting tailored to your Ubuntu 16.04.2 system:

The most critical step is to know why dlopen is failing—right now we're guessing. Add a call to dlerror() in your code to print the detailed error:

#include <dlfcn.h>
#include <stdio.h>

int main() {
    void* lib_handle = dlopen("foobar.so", RTLD_LAZY);
    if (!lib_handle) {
        fprintf(stderr, "dlopen failed: %s\n", dlerror());
        return 1;
    }
    // Success! Clean up
    dlclose(lib_handle);
    return 0;
}

Compile this test program with the dynamic linker library:

gcc -o test_dlopen test_dlopen.c -ldl

Run it and note the error message—this will point us directly to the root cause (e.g., missing dependencies, architecture mismatch, permission issues).

You mentioned compiling 64-bit libraries, but let's confirm everything lines up:

• Check your system's architecture:

  uname -m
  

  It should output x86_64 for a 64-bit system.
• Check the library's architecture:

  file /usr/local/lib/foobar.so
  

  Look for ELF 64-bit LSB shared object, x86-64 in the output. If it says 32-bit, you accidentally compiled a 32-bit library, which won't load on a 64-bit system by default.

Even if you ran ldconfig, it's worth verifying the library is in the system linker cache:

• Search the cache for your library:

  ldconfig -p | grep foobar
  

  If you don't see foobar.so in the results, do these checks:
  • Ensure /usr/local/lib is listed in one of the .conf files referenced by ld.so.conf:

    cat /etc/ld.so.conf.d/*.conf | grep "/usr/local/lib"
    

    Most Ubuntu systems include this path in /etc/ld.so.conf.d/libc.conf by default.
  • Re-run ldconfig in verbose mode to see if it processes your library:

    sudo ldconfig -v
    

    Look for a line like foobar.so -> foobar.so under the /usr/local/lib section. If it's missing, double-check the library's permissions (next step).

The linker needs read access to the library:

• Check the library's permissions:

  ls -l /usr/local/lib/foobar.so
  

  You should see permissions like -rwxr-xr-x (read/execute for all users). If not, fix them with:

  sudo chmod 755 /usr/local/lib/foobar.so
  

• Ensure the file isn't owned by a user/group that restricts access (e.g., a private user account). root:root or your user account is fine, as long as permissions allow global read access.

Try using the full path to the library in dlopen to rule out path resolution issues:

dlopen("/usr/local/lib/foobar.so", RTLD_LAZY);

If this works but the relative name fails, check the library's SONAME:

• View the library's SONAME (the name the linker uses to reference it):

  readelf -d /usr/local/lib/foobar.so | grep SONAME
  

  If there's no SONAME output, you forgot to set it during compilation. Recompile with the linker flag to set the SONAME:

  gcc -shared -fPIC -Wl,-soname,foobar.so -o foobar.so your_source_files.c
  

  Re-copy the library to /usr/local/lib and re-run sudo ldconfig—this should make the library visible via its short name.

Sometimes dlopen fails because the library itself depends on other libraries that aren't found. Use ldd to check:

ldd /usr/local/lib/foobar.so

Look for any lines marked not found. If you see these, you'll need to install those missing libraries (via apt) or copy them to a path the linker recognizes (like /usr/local/lib) and run sudo ldconfig again.

Ubuntu 16.04 uses AppArmor by default, which can sometimes block programs from loading libraries in certain paths. Test this by temporarily stopping AppArmor:

sudo systemctl stop apparmor

Run your program again—if it works now, you'll need to update your AppArmor profile to allow loading libraries from /usr/local/lib.

内容的提问来源于stack exchange，提问作者rohitsan