[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Interested in Debian Bazel efforts

Hi Olek,

Please do share!

I tried it with a larger project [1], and it works. Awesome!

By the way, I saw that you are interested in RISC-V [2]. I also have some interest in it and I may work with it in the future.

Bazel defaults to `linkstatic=True` for cc_binary targets. [1] I believe that's what you're talking about? That's certainly not required however. The Bazel C++ components in the bazel-bootstrap package, for example, are dynamically linked.

Yeah. However, in practice, it is difficult to set it to `False`. I got something like this:


$ readelf -d bazel-bin/rtorrent


 0x0000000000000001 (NEEDED)             Shared library: [liblibrtorrent_Ucommon.so]  0x0000000000000001 (NEEDED)             Shared library: [libexternal_Scurl_Slibcurl.so]  0x0000000000000001 (NEEDED)             Shared library: [libexternal_Sboringssl_Slibssl.so]  0x0000000000000001 (NEEDED)             Shared library: [libexternal_Slibtorrent_Slibtorrent.so]  0x0000000000000001 (NEEDED)             Shared library: [libexternal_Sboringssl_Slibcrypto.so]  0x0000000000000001 (NEEDED)             Shared library: [libexternal_Szlib_Slibzlib.so]  0x0000000000000001 (NEEDED)             Shared library: [libexternal_Sncurses_Slibncursesw.so]



The executable is not usable outside of the build directory.

Correct, Debian Policy [2] requires software to use dynamic linking wherever possible. That is mostly due to distribution-wide security considerations.

Switching to dynamic linking in a Bazel build is easy but there are numerous other considerations for Debian packaging. The most important being that nothing external to Debian is allowed to be downloaded during the build. We are currently working with Bazel upstream to determine the best generic solution for that. Without a generic solution, any software that you wanted to package for Debian would need to specify local versions of dependencies, such as with Bazel's distrib_cc_binary rule [3]. Note that the distrib_cc_binary rule and distrib_* friends are a very effective interim solution and much better than trying to create your own!

I didn't know distrib_* before. Those rules are very interesting. However, I noticed that they are kinda tailored/hacked for Debian, and they are not really simpler than manual `cc_import` or `cc_library` at the moment. In fact, as far as I can see, currently they are just aliases of `cc_*` with Debian hacks [3]. FYI this is a rule I use when I do need to link against a library of the system:


_CPPUNIT = """
load("@rules_cc//cc:defs.bzl", "cc_library")
  name = "cppunit",
  srcs = ["lib/x86_64-linux-gnu/libcppunit.so"],
  hdrs = glob(["include/cppunit/**"]),
  includes = ["include"],
  visibility = ["//visibility:public"],

    name = "cppunit",
    build_file_content = _CPPUNIT,
    path = "/usr",


I think we can definitely make things easier. Perhaps we can have some rules that generate something like `*.pc (pkgconfig)` to install to system, so they can be parsed and turned into Bazel targets later. Then we can override targets of a project with system-provided ones, via naming conventions or mappings or patches.



[1]: https://github.com/masc-ucsc/livehd

[2]: https://lists.debian.org/debian-bazel/2021/03/msg00002.html

[3]: https://github.com/bazelbuild/bazel/blob/09c621e4cf5b968f4c6cdf905ab142d5961f9ddc/tools/distributions/distribution_rules.bzl#L45

Attachment: OpenPGP_0xA102C2F15053B4F7.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: