Symbol conflict in transitive dependencies of two dynamic libraries

Question

I am using two third party dynamic libraries: liba.so and libb.so. They both call a function named common included in another dynamic library, but liba.so should use the one from libsuba.so while libb.so the one from libsubb.so.

I have no access to the source code of these dynamic libraries and I am thus unable to change the function name of one library and recompile it to resolve the conflict.

I am aware that macOS provides a two level namespace that seems to solve the issue, but I didn't found anything similar in ld man pages.

// exe.c
extern void func_a(void);
extern void func_b(void);

void main(void) {
    func_a();
    func_b();
}

// lib(a|b).c
extern void common(void);

void func_(a|b)(void) {
    common();
}

// libsub(a|b).c
#include <stdio.h>

void common(void) {
    printf("Common (A|B)\n");
}

all: exe

exe: exe.c liba.so libb.so
    gcc -L. -Wl,-rpath=. -o $@ $< -la -lb

liba.so: liba.c libsuba.so
    gcc -shared -fPIC -Wl,-rpath=. -L. -o $@ $< -lsuba

libb.so: libb.c libsubb.so
    gcc -shared -fPIC -Wl,-rpath=. -L. -o $@ $< -lsubb

libsub%.so: libsub%.c
    gcc -shared -fPIC -o $@ $<

Is there any way to solve this issue?

Edit: The current output value is:

$ ./exe 
Common A
Common A

and I would like the output to be:

$ ./exe 
Common A
Common B

`LD_PRELOAD=libsubb.so`. Also see [What is the LD_PRELOAD trick?](https://stackoverflow.com/q/426230/608639) and [`ld.so(8)`](https://linux.die.net/man/8/ld-linux) man page. — jww, Jun 19 '19 at 18:17
It forces the `common` function to be the one from `libsubb.so`. I would like `func_a` to use the `common` function from `libsuba.so` and `func_b` the one from `libsubb.so`. — John Doe, Jun 19 '19 at 18:20

score 1 · Accepted Answer · answered Jun 20 '19 at 14:10

1

You should report the issue to the respective vendors of those libraries. I think they are missing namespaces for exported symbols (for sure, if libsuba and libsubb both export a symbol called "common").

Have you thought about using objcopy --redefine-sym (see this answer)? However, objcopy does not seem to modify the dynamic symbol talbe, rendering this approach useless :(

answered Jun 20 '19 at 14:10

Vladislav Ivanishin

2,092
16
22

`objcopy` indeed seem to update only `.symtab` and not `.dynsym`. I reported the issue and in the meantime, I will try to load one of the two libraries using `dlsym()` and `RTLD_LOCAL` hoping that the lookup scopes are different (they are according to dsohowto.pdf). – John Doe Jun 20 '19 at 16:31

Symbol conflict in transitive dependencies of two dynamic libraries

1 Answers1