3

I'm trying to build and package LCM with Bazel. This works for the "build" part, but the end result is a library not usable by external consumers (i.e. "package" fails, because the package is broken).

LCM uses glib, which I am importing with pkg_config_package (gory details). More particularly, LCM uses glib internally, but does not expose this to users. This means that consumers should not need to link glib; liblcm.so should do that, and consumers should only need to link to LCM itself.

This all works great with upstream (which uses CMake and Does The Right Thing). Bazel, however, seems to be not linking liblcm.so to glib, for some unknown reason. If I build an executable with Bazel within the same overall environment, Bazel seems to know that users of LCM also need to link to glib. However, when I try to package this LCM for external use, it is broken, because liblcm.so isn't linked to glib, which forces consumers to deal with LCM's private glib dependency.

Why is Bazel not linking the LCM library to glib, and how do I fix it?

(p.s. We have similar issues with libbot...)

Matthew
  • 2,593
  • 22
  • 25

2 Answers2

2

Apparently, this is a known issue: https://github.com/bazelbuild/bazel/issues/492.

I can't just make the cc_library a cc_binary, either, because — while that would fix the under-linking — then I can't use the library in other Bazel targets. Nor can I make a cc_binary that wraps a cc_library, because then internal and external consumers aren't using the same library.

Matthew
  • 2,593
  • 22
  • 25
  • Well, not strictly true, although hackish - you can still put the .so into srcs of a cc_library/cc_binary and it will work (that's the current mechanism to let bazel know about precompiled library). But it's not expressive enough, that's why we work on 'transitive libraries' mentioned in issue #492. All in all, bazel has a lot to improve in 'developing in the open source world' area. – hlopko Sep 01 '17 at 07:58
-1

Static libraries do not link with other static libraries. When building through Bazel, Bazel keeps track of the dependencies and will link against all dependent libraries when building the executable.

There's more information here about linking static libraries: Linking static libraries to other static libraries

One interesting suggestion brought up is unarchiving both libraries and then creating a new library with all the .o files. This could possibly be achieved in a genrule.

zlalanne
  • 894
  • 5
  • 11
  • I'm not *producing* a static library... This behavior is wrong and broken for shared libraries. Are you saying that Bazel cannot produce non-broken shared libraries due to sojme static library legacy? – Matthew Jun 26 '17 at 14:35
  • The existing behavior is not there to produce shared libraries for external consumption. It's there to make TDD roundtrip faster, e.g. when editing the test, only the test is recompiled and relinked, not it's dependencies. In many cases the static linking of the test together with all dependencies will take more time than linking of the test + loading. – hlopko Sep 01 '17 at 08:02