I use OSX10.12, I try to use OpenCV in tensorflow, I use the first method which is mentioned in this question.
I build my code successfully but there are some questions as following when I execute it:
dyld: lazy symbol binding failed: Symbol not found: __ZN2cv6String8allocateEm
Referenced from: /Users/philokey/Practice/github/tensorflow/./bazel-bin/tensorflow/examples/test_cv/test_cv
Expected in: flat namespace
The build file is as following:
cc_binary(
name = "test_cv",
srcs = [
"test_cv.cc",
],
deps = [
"#opencv//:opencv",
],
)
How can I solve this problem?
You need to make sure you updated following files under tensorflow directory, correctly:
in WORKSPACE - (./tensorflow/tensorflow/WORKSPACE) add following:
new_local_repository(
name = "opencv",
path = "/usr/local/",
build_file = "opencv.BUILD",
)
opencv.BUILD - (./tensorflow/tensorflow/opencv.BUILD) add following:
cc_library(
name = "opencv",
srcs = glob(["lib/*.dylib*"]), <<<<<<<
hdrs = glob(["include/**/*.hpp"]),
includes = ["include"],
visibility = ["//visibility:public"],
linkstatic = 1,
)
[NOTE] for different operating systems, different dynamic libraries are created, example:
linux -> *.so,
windows -> *.dll, and
on OSx -> *.dylib
Even then if you face any problems please set DYLD_PRINT_LIBRARY environment variable to check if the correct libraries are linked, at times different versions of libraries may keep you busy.
Related
I am trying to build a simple EFI app with Bazel on Linux, which apparently means I need to use a cross compiler: x86_64-w64-mingw32-gcc. Right now I have:
cc_binary(
name = "boot-loader",
srcs = ["efi-main.c"],
copts = ["-ffreestanding"],
linkopts = ["-nostdlib", "-dll", "--subsystem 10", "-e efi_main"],
deps = ["#efi//:headers"],
)
From my own research it seems that a toolchain configuration could work, but I only want this single package to be cross compiled.
What I would like to have is:
efi_binary(
name = "boot-loader",
srcs = ["efi-main.c"],
copts = ["-ffreestanding"],
linkopts = ["-nostdlib", "-dll", "--subsystem 10", "-e efi_main"],
deps = ["#efi//:headers"],
)
But I cannot figure out how I could create the efi_binary rule easily. Ideally, I would like to duplicate the cc_binary rule and change it's compiler and linker, but that's not a feature.
Is there anything that I've missed?
We are seeing duplicate builds of the same target in Bazel and wondering what could cause this.
Here is a sample output:
[52,715 / 55,135] 12 action running
Bazel package: some-pkg - Target: a_target - Generating files at bazel-out/host/bin/some-pkg/a_target_generate [for host]; 264s remote-cache, processwrapper-sandbox
Bazel package: some-pkg - Target: a_target - Generating files at bazel-out/k8-fastbuild/bin/some-pkg/a_target_generate; 264s remote-cache, processwrapper-sandbox
...
We have not been able to identify the issue. It looks like this is only happening on Linux but not on Macs.
The target a_target is a custom_rule target. It should be platform independent.
custom_rule = rule(
attrs = dict(
...
_custom_rule_java_binary = attr.label(
cfg = "host",
default = Label("//tools/bazel/build/rules/custom-rule:custom_rule_bin"),
executable = True,
),
_singlejar = attr.label(
cfg = "host",
default = Label("#bazel_tools//tools/jdk:singlejar"),
executable = True,
allow_files = True,
),
),
implementation = ...,
)
custom_rule_bin is defined as follow:
java_library(
name = "custom_rule",
srcs = glob(["src/main/java/**/*.java"]),
deps = [
...,
],
)
java_binary(
name = "custom_rule_bin",
visibility = ["//visibility:public"],
main_class = "...",
runtime_deps = [
"#org_slf4j_simple",
":custom_rule",
"//some-pkg:some_pkg", # same some-pkg where a_target is built twice
],
)
The difference is that one says "for host" and the other doesn't. Anyone knows what the extra "for host" build is?
I do have a feeling that it's somehow related to the cfg attribute on the custom rule. This is likely coming from some example code. We use the same value on all our rules which generate code. This custom rule is special because it requires code from the application being built by Bazel to run and generate additional code.
Any insights appreciated why host would be wrong and what would be the correct value.
Any ideas/tips how to debug this?
First, one note is that the host configuration is being mostly deprecated, and "exec" is usually preferred. Some info about that is here: https://bazel.build/rules/rules#configurations.
What's happening is that that target is being depended upon in multiple configurations, and so bazel will build that target in each configuration. You can use cquery to figure out what's going on
As a very simple example:
genrule(
name = "gen_bin",
outs = ["bin"],
srcs = [":gen_lib"],
exec_tools = [":gen_tool"],
cmd = "touch $#",
)
genrule(
name = "gen_tool",
outs = ["tool"],
srcs = [":gen_lib"],
cmd = "touch $#",
)
genrule(
name = "gen_lib",
outs = ["lib"],
cmd = "touch $#; sleep 10",
)
Building bin, bazel runs the gen_lib genrule twice (in parallel):
$ bazel build bin
INFO: Analyzed target //:bin (5 packages loaded, 16 targets configured).
INFO: Found 1 target...
[1 / 5] 2 actions running
Executing genrule //:gen_lib; 1s linux-sandbox
Executing genrule //:gen_lib; 1s linux-sandbox
bazel config gives the configurations that are currently in the in-memory build graph:
$ bazel config
Available configurations:
5b39bc31deb1f1d37f1f858e7eec3964394eacce5bede4456dd59d417af4a6e9 (exec)
723da02ae6d0c5577e98242c8f06ca1bd1c6d7b295c97345ac31b844bfe8f79c
8960923b9e7dc13418be101268efd8e57d80283213d18174705345598b699c6b
fd805cc1de357c04c7abac1b40bae600e3d9ee56a8d17af0c28b5031ca09bfb9 (host)
then cquery:
$ bazel cquery "rdeps(//..., gen_lib)"
INFO: Analyzed 3 targets (0 packages loaded, 1 target configured).
INFO: Found 3 targets...
//:gen_lib (5b39bc3)
//:gen_lib (8960923)
//:gen_tool (5b39bc3)
//:gen_bin (8960923)
//:gen_tool (8960923)
INFO: Elapsed time: 0.052s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions
(cquery gives the first 7 digits of the configuration hash)
--output=graph gives a dot graph which is a little more useful:
$ bazel cquery "rdeps(//..., gen_lib)" --output=graph > /tmp/graph
$ xdot /tmp/graph
So gen_bin is in the target configuration (8960923), and it depends on gen_lib, so gen_lib will also be built in the target configuration.
gen_bin also depends on gen_tool via the exec_tools attribute, and exec_tools builds everything in the exec configuration (5b39bc3).
gen_tool also depends on gen_lib, and since gen_tool is in the exec configuration, a version of gen_lib is built in the exec configuration.
(There's also another version of gen_tool in the target configuration in the output, and that's an artifact of using //... in the "universe" argument of rdeps(), since //... will capture every target. Similarly, doing bazel build //... would cause gen_tool to be built twice.)
I am beginning to use bazel 2.0
I am building with visual studio 2015
I have a cc_library with deps using select ":windows" and ":linux"
windows and linux were defined as follow
config_setting(
name = "windows",
constraint_values = ["#platforms//os:windows"]
)
config_setting(
name = "linux",
constraint_values = ["#platforms//os:linux"]
)
bazel build base was working (generating the lib)
unfortunately I need to differentiate under windows between 32 bits and 64 bits since I need those target to be built under 32 and 64 bits
I changed "windows" to "windows_x86_64" defined as follow
config_setting(
name = "windows_x86_64",
values = {
"cpu": "#platforms//cpu:x86_64",
"platforms": "#platforms//os:windows",
},
)
bazel build base \
--platforms=#platforms//os:windows \
--cpu=#platforms//cpu:x86_66 \
--incompatible_use_platforms_repo_for_constraints
gives me the following error message
ERROR: While resolving toolchains for target //lib/base:windows_x86_64: Target #platforms//os:windows was referenced as a platform, but does not provide PlatformInfo
ERROR: Analysis of target '//lib/base:base' failed; build aborted: Target #platforms//os:windows was referenced as a platform, but does not provide PlatformInfo
I know I am missing something. I cannot figure out what. I searched what could be this PlatformInfo and how to retrieve it, unsuccessfully.
Any help, pointer appreciated!!!
Thanks
Somewhat confusingly #platforms//... doesn't actually have any platforms defined in it, instead, it has a set of constraint_values that you can use to create a platform.
e.g.
# BUILD.bazel
platform(
name = "windows_x86_32",
constraint_values = [
"#platforms//cpu:x86_32",
"#platforms//os:windows",
],
)
platform(
name = "windows_x86_64",
constraint_values = [
"#platforms//cpu:x86_64",
"#platforms//os:windows",
],
)
# The rest of your build file...
You should then be able to build using the command;
bazel build base --platforms=//:windows_x86_32
# or
bazel build base --platforms=//:windows_x86_64
I'm getting a failure when I try to compile glog with gflags support using Bazel. A github repo reproducing this problem and showing the compilation error message is here: https://github.com/dionescu/bazeltrunk.git
I suspect that the problem occurs because glog is finding and using the "config.h" file published by gflags. However, I do not understand why this happens and why the current structure of the build files results in such errors. One solution I found was to provide my own BUILD file for gflags where the config was in a separate dependency (just how glog does it in my example).
I would appreciate any help with understanding the issue in this example.
The problem is that gflag's BUILD file is including its own config. Adding -H to glog.BUILD's copts yields:
. external/glog_archive/src/utilities.h
.. external/glog_archive/src/base/mutex.h
... bazel-out/local-fastbuild/genfiles/external/com_github_gflags_gflags/config.h
In file included from external/glog_archive/src/utilities.h:73:0,
from external/glog_archive/src/utilities.cc:32:
external/glog_archive/src/base/mutex.h:147:3: error: #error Need to implement mutex.h for your architecture, or #define NO_THREADS
# error Need to implement mutex.h for your architecture, or #define NO_THREADS
^
If you take a look at gflag's config.h, it went with a not-very-helful approach of commenting out most of the config:
// ---------------------------------------------------------------------------
// System checks
// Define if you build this library for a MS Windows OS.
//cmakedefine OS_WINDOWS
// Define if you have the <stdint.h> header file.
//cmakedefine HAVE_STDINT_H
// Define if you have the <sys/types.h> header file.
//cmakedefine HAVE_SYS_TYPES_H
...
So nothing is defined.
Options:
The easiest way is probably to generate the config.h in your glog.BUILD:
genrule(
name = "config",
outs = ["config.h"],
cmd = "cd external/glog_archive; ./configure; cd ../..; cp external/glog_archive/src/config.h $#",
srcs = glob(["**"]),
)
# Then add the generated config to your glog target.
cc_library(
name = "glog",
srcs = [...],
hdrs = [
":config.h",
...
This puts the .h file at a higher-precedence location than the gflags version.
Alternatively, you could do something like this in the genrule, if you want to use your //third_party/glog/config.h (#// is shorthand for your project's repository):
genrule(
name = "config",
outs = ["config.h"],
cmd = "cp $(location #//third_party/glog:config.h) $#",
srcs = ["#//third_party/glog:config.h"],
)
You'll have to add exports_files(['config.h']) to the third_party/glog/BUILD file, too.
I have a code generator tool that generates C/C++ code. This code generator tool is compiled with crosstool1. The generated C/C++ code needs to be compiled with crosstool2.
So the actions are:
Using Crosstool1 compile 'code_generator'.
Execute 'code_generator' and generate 'generated_code.cpp'
Using Crosstool2 compile 'generated_code.cpp'
Is it possible to make a cc_library() determine the crosstool to use? I saw that Skylark rules now allow a 'toolchains' parameter which I'm not sure how this is used, also I do not want to do the heavy lifting of C/C++ compiling bare bone with Skylark.
Is there an example of using a proper Host Crosstool and Target Crosstool except for the Tenserflow example? I get a headache each time I read it :D
Assume //crosstool1:toolchain is a label for cc_toolchain_suite rule describing first crosstool, //crosstool2:toolchain is a label for cc_toolchain_suite for second crosstool, and the build file for the project is:
cc_binary(
name = "generator",
srcs = [ "main.cc" ],
)
genrule(
name = "generate",
outs = ["generated.cc"],
cmd = "$(location :generator) > $#",
tools = [":generator"],
)
cc_binary(
name = "generated",
srcs = [ "generated.cc" ],
)
Then running:
bazel build --host_crosstool_top=//crosstool1:toolchain --crosstool_top=//crosstool2:toolchain :generated
will do exactly what you describe, it will use crosstool1 to build :generator, and crosstool2 to build generated. Genrules use host configuration by default, so all should just work.