support for pure C programs?

[rtsai]

Please provide the following information. The more we know about your system and use case, the more easily and likely we can help.

Description of the problem / feature request / question:

We would like to have better support for building pure C programs (not C++). Specifically, we are cross-compiling to a target platform where the boot-time file system does not have libstdc++, but the cc_binary output for that C program has a dynamic link dependency on -lstdc++. The CROSSTOOL linker_flag points to -lstdc++, which is what we want for all the other C++ programs that run after the root file system has been mounted. We can work around this by using "-static" for that particular program, but then we also lose dynamic linking for other things we do have (e.g., libc.so).

If possible, provide a minimal example to reproduce the problem:

Write and build a pure C program. "ldd" on the resulting output will show a dependency on libstdc++

Environment info

• Operating System: Ubuntu-16.04.2 LTS
• Bazel version (output of bazel info release): 0.4.5

Have you found anything relevant by searching the web?

#2548

Anything else, information or logs or outputs that would be helpful?

https://groups.google.com/d/msg/bazel-discuss/iYzl5XfMDWE/HGV9MUx3AAAJ

One thing we think might work is to create a new CROSSTOOL that is basically a copy of the regular one, but with "linker_flag -lstdc++" removed. This seems to work, but is undesirable, since we do in fact predominantly use C++. Using a different crosstool_top for different packages is undesirable because package-type rules ("create a tarball") don't seem to support depending on outputs of a different build configuration ("create a package of mostly C++ programs, except for this C program").

So the next step might be to introduce a new cc_{binary,library} attribute "lang"

cc_binary(..., lang="c | c++", ...) which defaults to "c++".

The implementation for "c" would then forbid depending on "c++" providers

The CROSSTOOL configuration would have to add a "cxx_linker_flag" field to be used only when linking C++ programs. The existing "linker_flag" can continue to be used for both C and C++ programs.

[kchodorow]

@katre, could you comment on this from a configurations perspective? Right now, Bazel can only use one toolchain for a build, although we are working on fixing that.

One thing you might be able to work around this is to go ahead and create a custom C toolchain without the -lstdc++ flag and then create a macro like:

def cpp_library(name, srcs, hdrs, deps):
  native.cc_library(
    name = name,
    srcs = srcs,
    hdrs = hdrs,
    deps = deps,
    linkopts = ['-lstdc++'],
  )

Then use cpp_library whenever you use C++ and cc_library for pure C.

[katre]

I'm working on #2219, which leads to exposing specific toolchains for different rule types. For the cc rules, this will basically allow wrapping the existing CROSSTOOL functionality in a way that is easier to switch, but it will still be a single choice of toolchain for an invocation, not allowing using different toolchains in the same build.

We have had discussions about allowing specifying the toolchain on a target-by-target basis, which would allow what you want here, but that's unlikely to land in the next half year or so.

[rtsai]

We will have to pursue the custom macro.

My feedback as a user is that C/C++ are similar enough to warrant something built-in and less-heavyweight than having to switch crosstools (e.g., something similar to the macro described above) - they are more similar than, say, cc_library and python_library. That will have impact on whatever syntax is used for including those artifacts in dependencies ("tarball of C/C++ programs"), etc. We are pulling in a decent number of third_party open-source projects that happen to be pure C programs, but through accident of bazel are actually being built as C++ programs.

Thank you!

[kchodorow]

Agreed that C and C++ rules should be close cousins! Sorry for the inconvenience.

[ulfjack]

I think we should make it so the cc_* rules automatically detect if there are only .c files in srcs, and then not add -lstdc++ to the final link. That should be straightforward to do and doesn't require any configuration shenanigans.

[hlopko]

One possible approach that works already is to define a crosstool feature adding "-lstdc++" (let's call it cxxstdlib), but instead of implying it from the action_configs you'd enable it from .bazelrc (--features=cxxstdlib) so it's enabled by default, and then disable it for individual packages (package(..., features = ["-cxxstdlib"])) or rules (cc_library(..., features = ["-cxxstdlib"]...).

[rtsai]

Thank you very much for the suggestion. Things seem to be working.

Can you please confirm this is correct? My CROSSTOOL diff (basically the same as that in @local_config_cc/CROSSTOOL):

@@ -39,7 +40,6 @@ toolchain {
   target_system_name: "local"
   cxx_flag: "-std=c++0x"
-  linker_flag: "-lstdc++"
   linker_flag: "-lm"
   linker_flag: "-fuse-ld=gold"
   linker_flag: "-Wl,-no-as-needed"
@@ -84,6 +84,19 @@ toolchain {
   tool_path {name: "gcc" path: "/usr/bin/gcc" }
   tool_path {name: "ar" path: "/usr/bin/ar" }
 
+  feature {
+    # See https://github.com/bazelbuild/bazel/issues/2954
+    name: 'cxxstdlib'
+    flag_set {
+      action: 'c++-link-executable'
+      flag_group {
+        flag: '-lstdc++'
+      }
+    }
+  }
+

My BUILD file:

diff --git a/BUILD b/BUILD
index 0589bbd..de81b7e 100644
--- a/BUILD
+++ b/BUILD
@@ -1,4 +1,7 @@
-package(default_visibility = ["//visibility:private"])
+package(
+    default_visibility = ["//visibility:private"],
+    features = ["-cxxstdlib"],
+)

Are there any "reserved words" for feature names that I should avoid using? :)

Thank you so much!

[hlopko]

You might want to add the feature to c++-link-dynamic-library action too. Otherwise looks good, hope it will work :)

[jheaff1]

I too would like to be able to compile a pure C application without linking to libstdc++. Any progress on this issue?

[jheaff1]

Resolved by #14736

[fmeum]

@sgowroji Can be closed based on #2954 (comment)

[sgowroji]

We are closing this issue w.r.t the above comment. Thanks!