1

I need to link my SO against libbfd, for the purpose of having human-readable backtraces.

Static linking against libbfd.a fails, because it's not compiled with -fPIC, so as I understand, it can participate in executable only.

Though linking against libbfd.so also gives some troubles.

I need to compile on both Ubuntu-14.04 and Debian Wheezy 7.8 And they have non-intersecting sets of binutils versions. In particular, Ubuntu has 2.24, and Debian has 2.22 and 2.25. And the problem is, gcc doesn't want to take symlink's name libbfd.so to reference it, and uses SONAME instead. So i end with either libbfd-2.24-system.so or libbfd-2.25-system.so in dependencies.

For now I see several approaches:

  1. There's some hidden flag which allows to override SONAME during linking. This is the preferred path

  2. I have no way other than compile libbfd by hand. I would evade this as much as possible.

  3. Manual dlopen+dlsym for everything I need.

I read answer gcc link shared library against symbolic link, but it suggests to change SONAME I'm not able to do.

Any suggestions?

Thanks.

EDIT: it seems that virtually all static libs in Ubuntu repos are not position-independent. Can't guess why. With the inability to override SONAME it makes things much more complicated.

Community
  • 1
  • 1
Target-san
  • 451
  • 3
  • 11
  • well, for me using `g++ loader.cc -lbfd` worked. the linker flag -lbfd specifies linking against libbfd. – clockw0rk Jul 26 '19 at 02:20

1 Answers1

0

Not sure whether i understand your (4 years old problem) correctly, but having similar problems with libbfd, I found this solution:

Using the linker flag -lbfd seems to work.

It is a linker flag that specifies g++ to link against libbfd.

My full command was g++ loader.cc -lbfd.

At least for me, errors at link-time a la "unknown function" are solved.

clockw0rk
  • 576
  • 5
  • 26