CODEWITHSUNDEEP
linuxgccshared-librariesrpath
Nohappy
Nohappy

Reputation: 274

RPATH and overlay filesystem

If I have an A.so file, and it requires B.so in runtime. If the RPATH of A.so is not set, I assume it will look for B.so under /lib/ during runtime. In addition, if I also set up an overlay filesystem over /lib/ and there is another B.so (Let's call this one B'.so) on the upper directory. Which one of the B.so will A.so link to in runtime? I assumed A.so will link to B'.so in runtime, but it seems that I was wrong after I made some experiments.

Upvotes: 1

Views: 232

Answers (1)

Jakob Stark
Jakob Stark

Reputation: 3845

Let's do an example. We create directories with

$ mkdir upper
$ mkdir lower
$ mkdir merged
$ mkdir work

Then we write code

// libupper.c
#include <stdio.h>
void print_hello(void) {
    printf("hello from upper\n");
}

// liblower.c
#include <stdio.h>
void print_hello(void) {
    printf("hello from lower\n");
}

// main.c
void print_hello(void);
int main(void) {
    print_hello();
}

Compile it with

$ gcc --shared -o lower/lib.so liblower.c
$ gcc --shared -o upper/lib.so libupper.c

Mount the overlay

$ sudo mount -t overlay overlay -o "upperdir=upper,lowerdir=lower,workdir=work" merged

Compile the main program

$ gcc -o main main.c merged/lib.so

And run it

$ ./main

will print

hello from upper

So as you assumed, the library from the upper directory is called as it shadows the lower one.

BIG FAT NOTE I can only guess what your "experiments" looked like, because you did not provide any further information, but I guess you produced some undefined behaviour by modifying the underlying filesystems, which is explicitly prohibited for overlay filesystems (see here). While the overlay fs is mounted, you should not make changes in the upper or lower directories, but only in the merged directory.

Upvotes: 0

Related Questions