Cannot link to library whose basename is not the same as its soname

When I have the following library as a dep of foo:

cc_library(
  name = "library",
  srcs = [
    "libfreeimageplus-3.17.0.so,
  ]
)

cc_binary(
  name = "foo.so",
  deps = [
    ":library",
  ]

Bazel writes the following ELF header in foo.so:

Dynamic section at offset 0xc839d0 contains 32 entries:
  Tag        Type                         Name/Value
 ...
 0x0000000000000001 (NEEDED)             Shared library: [libfreeimageplus.so.3]
 ...
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../../_solib_k8/_U@adrenosdk_S_S_Ctextureconverter___Uexternal_Sadrenosdk_SBin_Sx64:$ORIGIN/../../_solib_k8/_U@freeimageplus_S_S_Clibrary___Uexternal_Sfreeimageplus:$ORIGIN/../../_solib_k8/_U@pvrtextool_S_S_Clibrary___Uexternal_Spvrtextool_SLibrary_SLinux_Ux86_U64]

Sadly there is no file libfreeimageplus.so.3 anywhere. The correct libfreeimageplus-3.17.0.so is available in the execroot, though. Does anyone have an idea how to prevent Bazel from changing the filename?

[lberki]

Regrettably, I can’t provide a good solution at the moment other than “we need to make it possible to link with libraries whose basename is not their soname”.

Internally, we hardly ever use precompiled libraries, so this hasn’t been an important issue for us, but we of course can’t live with that in bazel.

[hlopko]

It depends on how do you define “near” future 😃 We’re focusing on skylarkifying C++ rules atm. I can imagine that cc_import (hopefully the sufficient place where this logic will reside) is fully rewritten in Skylark by mid-2018. Then the external contribution for this feature should not be too hard. If it’s left at us, I cannot promise we’ll get to it in 2018, there are more pressing features that should be done but are not done, like transitive libraries. Sorry I don’t have better news.