dlopen claiming that a linked library does not exist

For the following C program I get the output: "Error: /usr/local/bundle/ruby/3.0.0/gems/mitie-0.2.1/vendor/libmitie.so: cannot open shared object file: No such file or directory", but the file does exist, and seems to be a valid ELF binary (I did my best to verify with realelf).

Code:

---

#include <stdio.h>
#include <dlfcn.h>
 
int main(void) {
    void *handle = dlopen("/usr/local/bundle/ruby/3.0.0/gems/mitie-0.2.1/vendor/libmitie.so", RTLD_NOW);
    const char *err = dlerror();
 
    if (handle && !err) {
      printf("Handle: %ld\n", (long int)handle);
    }
    else {
      printf("Error: %s", err);
    }
 
    return 0;
}

---

Any thoughts? Thank you so much!

I should also note that this is running in a Docker container in a Debian based image.

Is the file in your docker container?

Quote:

---

Originally Posted by Salem

Is the file in your docker container?

---

Yes, it is

Within the docker container I got this output from the "file" command:

Code:

---

/usr/local/bundle/ruby/3.0.0/gems/mitie-0.2.1/vendor/libmitie.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=92cea087cb683f406382dc15e7cb5e6ddd466f5a, not stripped

---

So I was thinking it could be an issue with architecture mismatch since I'm building the image on a M1 Mac. So I tried building a multi-architecture image, but I still get the same results.

Can you do 'file' on other .so files ?
Can you dlopen any of those files?

Quote:

---

Originally Posted by Salem

Can you do 'file' on other .so files ?
Can you dlopen any of those files?

---

Thank you. I tried that, it turned out to be an architecture mismatch after all. I was confused because building a multi-architecture image didn't resolve the matter, but it turns out the Ruby library currently only supports x86 for Linux. I was able to resolve the matter by forcing the image to only support x86. Thank you again!

Quote:

---

Originally Posted by manpage

RETURN VALUE
On success, dlopen() and dlmopen() return a non-NULL handle for the loaded object. On error (file could not be found, was not readable, had the wrong format, or caused errors during
loading), these functions return NULL.

On success, dlclose() returns 0; on error, it returns a nonzero value.

Errors from these functions can be diagnosed using dlerror(3).

---

Would dlerror() have told you that?