not finding cc headers from other packages

[justi...@gmail.com]

I'm having trouble compiling a cc_library that depends on headers from another package. I've read the docs on http://bazel.io/docs/build-encyclopedia.html#cc_library but apparently I'm still doing something wrong. What needs fixing?

### sw/A/BUILD
package(default_visibility = ["//visibility:public"])

cc_library(
name="A",
srcs=['a.h', 'a.c'],
hdrs=['a.h'],
)

### sw/B/BUILD
package(default_visibility = ["//visibility:public"])

cc_library(
name="B",
srcs=['b.h', 'b.c'],
hdrs=['b.h'],
deps=['//sw/A'],
)

bazel build //sw/B
INFO: Found 1 target...
INFO: From Compiling sw/B/b.c:
sw/B/b.c:1:10: fatal error: 'a.h' file not found
#include "a.h"
^
1 error generated.

Thanks in advance,
Justin

[Damien Martin-guillerez]

Header path is relative to the workspace root. You should include "sw/A/a.h".  Or you can add an include directory via the includes attribute of the cc_library rule, see http://bazel.io/docs/build-encyclopedia.html#cc_library.includes

--
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-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/22d9b27e-5628-4eb3-83cb-f9e5ae06ac71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[justi...@gmail.com]

Thanks for the fast reply! Changing the include directive fixed the compilation.

However, linking failed with a missing symbol error until I added

linkopts=['//sw/A']

to my cc_library invocation in sw/B/BUILD. Since the docs say:

deps: The list of other libraries to be linked in to the binary target.

I was not expecting to have to also specify linkopts. Is this the expected behavior?

Thanks,
Justin

> To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

[Greg Estren]

I don't expect you to need custom linkopts. Can you share your new build structure and what the failing invocation looks like?

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/aaaa0a74-7a6f-4355-b7d5-485e1e25e8bc%40googlegroups.com.

[justi...@gmail.com]

Sure:

(venv)dovah:gerrit justin$ cat sw/A/BUILD

package(default_visibility = ["//visibility:public"])

cc_library(
name="A",
srcs=['a.h', 'a.c'],
hdrs=['a.h'],
)

(venv)dovah:gerrit justin$ cat sw/B/BUILD

package(default_visibility = ["//visibility:public"])

cc_library(
name="B",
srcs=['b.h', 'b.c'],
hdrs=['b.h'],
deps=['//sw/A'],

# linkopts=['//sw/A'], # commenting this out breaks the build!
)


(venv)dovah:gerrit justin$ cat sw/A/
BUILD a.c a.h
(venv)dovah:gerrit justin$ cat sw/A/a.h

int afunc(void);

(venv)dovah:gerrit justin$ cat sw/A/a.c

int afunc(void) {
return 42;
}

(venv)dovah:gerrit justin$ cat sw/B/b.h

int bfunc(void);

(venv)dovah:gerrit justin$ cat sw/B/b.c
#include "sw/A/a.h"

int bfunc(void) {
return afunc();
}

(venv)dovah:gerrit justin$ bazel build //sw/B --verbose_failures
INFO: Found 1 target...
INFO: From Linking sw/B/libB.so:
Undefined symbols for architecture x86_64:
"_afunc", referenced from:
_bfunc in b.pic.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ERROR: /Users/justin/git/gerrit/sw/B/BUILD:3:1: Linking of rule '//sw/B:B' failed: gcc failed: error executing command
(cd /private/var/tmp/_blaze_justin/b6a111fd3f2695a4aa1c6bdefefa0d6f/gerrit && \
exec env - \
/usr/bin/gcc -shared -o bazel-out/local_darwin-fastbuild/bin/sw/B/libB.so bazel-out/local_darwin-fastbuild/bin/sw/B/_objs/B/sw/B/b.pic.o -lstdc++ -B/usr/bin -Wl,-S): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1: gcc failed: error executing command
(cd /private/var/tmp/_blaze_justin/b6a111fd3f2695a4aa1c6bdefefa0d6f/gerrit && \
exec env - \
/usr/bin/gcc -shared -o bazel-out/local_darwin-fastbuild/bin/sw/B/libB.so bazel-out/local_darwin-fastbuild/bin/sw/B/_objs/B/sw/B/b.pic.o -lstdc++ -B/usr/bin -Wl,-S): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
Target //sw/B:B failed to build
INFO: Elapsed time: 0.103s, Critical Path: 0.04s

[Greg Estren]

Hmm, this appears to be a platform issue. I just did your build from an Ubuntu machine and it linked no problem (with the same exact gcc command: /usr/bin/gcc -shared -o bazel-out/local_darwin-fastbuild/bin/sw/B/libB.so bazel-out/local_darwin-fastbuild/bin/sw/B/_objs/B/sw/B/b.pic.o -lstdc++ -B/usr/bin -Wl,-S).

I'm going to try the same from a Mac to see what happens.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/4747ee96-7691-4201-b3fa-94db0480e039%40googlegroups.com.

[Greg Estren]

So I think you're exposing some quirks we need to iron out. :)

In particular, I'm not sure our Mac toolchain is handling shared libraries right at the moment. Do you specifically need to build a shared library (which is an implicit consequence of requesting //sw/B)? Could you make B a cc_binary that otherwise has the same dependency structure?

There might be another issue with .c vs. .cc files (that we need to look into). When I ran your build as described on a Mac I got the same problem. When I changed B to a cc_binary I had a similar problem. But by changing the .c files to .cc files I got it to properly build.

Sorry for these hiccups! Let me know if these help.

[Damien Martin-guillerez]

Side node: normally mac handles shared library. But you need to pull today's update to have it work correctly.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CABdTCQV3D%3D__uUnYngBEy3Vt7kB5DEQvvJa-igzQdfyrxwH5hg%40mail.gmail.com.

[Greg Estren]

On Thu, Mar 26, 2015 at 3:40 PM, Greg Estren <gre...@google.com> wrote:

There might be another issue with .c vs. .cc files (that we need to look into). When I ran your build as described on a Mac I got the same problem. When I changed B to a cc_binary I had a similar problem. But by changing the .c files to .cc files I got it to properly build.

Okay, on further investigation, we're not aware of a .c / .cc issue. Just make sure to apply extern "C" when mixing the two.