Why not always use cc_library instead of cc_import?

[andreas....@tweag.io]

Hi,

In short, my question is: What is the purpose of cc_import, and when should it be preferred over cc_library?

cc_import has several known issues and their workaround seems to always be to use cc_library instead.

I've frequently encountered the following two issues:

1. cc_import does not have a `strip_include_prefix` attribute [1].

   E.g. you'd have to change `#include "zlib.h"` to `#include "external/zlib/zlib.h"`, or similar.

2. cc_import does not work with shared libraries that don't match their soname [2].

   E.g. if `libz.so` has soname `libz.so.1`, then execution of the final cc binary will fail.

Both these issues can be worked around by using cc_library instead of cc_import.

See [3] for the `strip_issue_prefix` issue, and [4] for the soname issue.

This begs the question: Why not always use cc_library instead of cc_import?

Is there some functionality that is only provided by cc_import?

As I understand the discussion in [2] the new Starlark C++ API should replace the current implementations for cc_import and cc_library. In that context, does it make sense to provide both functions, or would cc_library alone suffice?

I've previously raised this question in [4]. I'm writing to this list as suggested by @mboes.

Best, Andreas

[1]: https://github.com/bazelbuild/bazel/issues/4748

[2]: https://github.com/bazelbuild/bazel/issues/1534

[3]: https://github.com/bazelbuild/bazel/issues/4748#issuecomment-370707938

[4]: https://github.com/tweag/rules_nixpkgs/issues/60

[Andrew Suffield]

I do have one slightly byzantine use case which (so far as I've been able to figure out), requires cc_import.

Assume that you have libfoo.so and libbar.so. libbar calls a function from libfoo. For reasons surpassing credible explanation, you do not want to link these libraries into a binary, but instead you want to dlopen() them from the binary. However, you do want a DT_NEEDED entry for libfoo added to libbar, so that dlopen() will follow dependency chains.

In this scenario, you can produce a shared library with cc_library and then pass it through cc_import, as a way to strip out the providers which would otherwise result in directly linking the whole lot into a binary, but still generate the linker flags to get the DT_NEEDED entries.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/a9a53bfb-1601-4750-9669-1e8d6109c29e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yun Peng]

One thing cc_import has and cc_library doesn't have is the "interface_library" attribute. This attribute helps import a DLL (shared library on Windows) and allow other targets to depend on it.

Therefore cc_import library provided an irreplaceable role in https://github.com/bazelbuild/bazel/pull/7252/files 

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAJ3KJgZm%2BjACM-Bg6ujYbANF0VFuHX7ykJ-vUhSKHA5BezMk0w%40mail.gmail.com.