Reduce exported symbols of a third party library

Question

I have code that works fine, but if I link my project to a third party lib libabc.so (source unavailable), then all of the sudden I get a segmentation fault.

I have a main that looks like this

#include <opencv2/imgcodecs.hpp>
#include "Abc.h"

int main(int argc, char **argv)
{
    Abc dummyAbc;
    auto img = cv::imread("dummy.png");
    cv::imwrite("123.png", img);
    return 0;
}

The CMakeList.txt is as follows

cmake_minimum_required(VERSION 3.1)
set(CMAKE_C_STANDARD 11)
find_package(OpenCV COMPONENTS core highgui imgcodecs)
include_directories(${OpenCV_INCLUDE_DIR})

add_executable(my_project Main.cpp)
target_link_libraries(my_project ${OpenCV_LIBRARIES} abc)

This compiles well, but segfault when running. If I remove the line

Abc dummyAbc;

then all works fine (i.e. there is no problem with missing file, or opencv).

If I inspect the stack of the segfault, I see that:

Thread 1 "my_project" received signal SIGSEGV, Segmentation fault.
0x00007fdea96836b3 in png_destroy_write_struct () from /usr/local/lib/libabc.so

where png_destroy_write_struct is being called by cv::imwrite.

Both libpng.so and libabc.so (!!) export png_destroy_write_struct it actually exports all of the libpng API (which I assume it was statically linked to?). I assume this is the problem? I do no want openCV to see whatever libabc.so exports... How can I do this?

I tried to use objcopy --prefix-symbols abc_ libabc.so but somehow it did not help, now the crash happens at abc_png_destroy_write_struct.

Employed Russian · Accepted Answer · 2019-11-24T20:47:33.193

4

I assume this is the problem?

Yes: that is very likely: libabc.so has statically linked (probably different version of) libpng, and introduces symbol conflict.

I do no want openCV to see whatever libabc.so exports... How can I do this?

You can't. You must contact libabc.so developer, and tell them to hide libpng symbols.

The only other option (for single process execution) is to dynamically load libabc.so.

This can be done via dlopen("liabc.so.", RTLD_LOCAL), and even that may not work (depending on exactly how libabc.so was linked) -- it may cause libabc.so to bind to your version of libpng, and crash.

On Linux, you could also possibly use dlmopen(LM_ID_NEWLM, "libabc.so", ...) which will completely isolate libabc.so from the rest of your code, and may work if libabc.so was linked to include all of its dependencies (or you can bring them into the new loader namespace explicitly).

Finally, as Eljay commented here, you could use inter-process communication and have a completely separate process load libabc.so. This will have much worse performance than using libabc.so directly, but is better than nothing.

edited Nov 24 '19 at 20:47

answered Nov 24 '19 at 20:20

Employed Russian

199,314
34
295
362

Thanks for your answer. Would it be possible somehow to create my wrapper around `libabc.so` so that I manually hide/expose some of the methods (say, only the ones in "abc.h") and link against this new wrapper? – Al Wld Nov 24 '19 at 20:26
@AlWld "Would it be possible ...". No. – Employed Russian Nov 24 '19 at 20:27
It would be possible, but it involves running it out-of-process and using interprocess communication. – Eljay Nov 24 '19 at 20:41
Why not mention manual modification of `.dynsym` as mentioned in your [other answer](https://github.com/yugr/Implib.so#reducing-external-interface-of-closed-source-library)? – yugr Nov 25 '19 at 08:44
1

@yugr The other answer (https://stackoverflow.com/questions/36273404/is-there-any-way-to-override-the-fvisibility-hidden-at-link-time/36274814#36274814) only applies when you can relink the `.so`. Modifying `.so` itself is likely to cause the hash tables to become inconsistent, causing a crash in `ld-linux`. – Employed Russian Nov 25 '19 at 15:11

score 1 · Answer 2 · answered Nov 25 '19 at 15:36

To add to EmployedRussian's answer about using dlmopen-based approach to isolate libabc.so from the rest of your code: to avoid messing with dlsym and function pointers in that case you could automatically generate wrappers for needed library functions via Implib.so:

$ cat mysymbols.txt
foo
bar
$ cat mycallback.c
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

#ifdef __cplusplus
extern "C"
#endif

// Dlopen callback that loads library to dedicated namespace
void *mycallback() {
  void *h = dlmopen(LM_ID_NEWLM, "libabc.so", RTLD_LAZY | RTLD_DEEPBIND);
  if (h)
    return h;
  fprintf(stderr, "dlmopen failed: %s\n", dlerror());
  exit(1);
}

$ implib-gen.py --dlopen-callback=mycallback --symbol-list=mysymbols.txt libabc.so
$ ... # Link your app with libabc.tramp.S, libabc.init.c and mycallback.c

score -1 · Answer 3 · answered Nov 24 '19 at 20:20

-1

I would try strip. See this for details: https://linux.die.net/man/1/strip

answered Nov 24 '19 at 20:20

Vlad Feinstein

10,960
1
12
27

`strip` does *nothing* for dynamic symbol tables. – Employed Russian Nov 24 '19 at 20:21

Reduce exported symbols of a third party library

3 Answers3