Closed akshitj1 closed 4 years ago
What revision of drake (e.g., git rev-parse HEAD
)?
@jamiesnape 5ded94c36d18be43fbcc12b088351188c25c9190
Try the following: Upgrade to Xcode 11.2 and ensure you have run it at least once. Checkout a clean version of drake. Then
$ brew update
$ brew upgrade
$ brew cleanup
$ ./setup/mac/install_prereqs.sh
$ xcode-select --switch /Applications/Xcode.app/Contents/Developer
$ bazel clean --expunge
$ bazel build --subcommands //examples/acrobot:run_lqr
If it fails anywhere, paste the output into a gist and post a link to the gist here.
Hi @jamiesnape , so I thought that xcode command line tools would do just fine as It contains basic macos:SDKs and clang tools. But I was wrong, there is an requirement for entire actual xcode.app. I am still not sure why there is such a heavy dependency(8Gigs) which is majorly IDE and ios devices development SDKs, but anyway now those wrapped_clang errors are gone. Now there is some issue with tinyxml, tinyxml@2. I encountered these 2 separate times after successive clean --expunge
,
ERROR: /Volumes/external/repos/drake/multibody/parsing/BUILD.bazel:41:1: undeclared inclusion(s) in rule '//multibody/parsing:package_map':
this rule is missing dependency declarations for the following files included by 'multibody/parsi ng/package_map.cc':
'external/tinyxml2/include/_usr_local_Cellar_tinyxml2_7.1.0_include/tinyxml2.h'
ERROR: /Volumes/external/.cache/bazel/3abb13651c12473ffdebbe1237e5a120/external/sdformat/BUILD.ba zel:24:1: undeclared inclusion(s) in rule '@sdformat//:urdfdom':
this rule is missing dependency declarations for the following files included by 'external/sdform at/src/urdf/urdf_parser/urdf_model_state.cpp':
'external/tinyxml/include/_usr_local_opt_tinyxml_include/tinyxml.h'
Both these libararies were installed from install_prereqs.sh. I have reinstalled these but errors persist.
Hi, I am not an avid user of bazel, but are bazel builds known to be indeterministic? This is what I am seeing while trying to debug. Steps to reproduce:
mkdir bar; pushd bar
echo -e "#include<tinyxml.h>\nint main(){return 0;}" > bar.cc
echo "cc_binary(name=\"bar\",srcs=[\"bar.cc\"],deps=[\"@tinyxml\"])" > BUILD.bazel
popd
bazel build //bar:bar --verbose_failures
Initially it gives error:
ERROR: /Volumes/external/repos/drake/bar/BUILD.bazel:1:1: undeclared inclusion(s) in rule '//bar:bar':
this rule is missing dependency declarations for the following files included by 'bar/bar.cc':
'external/tinyxml/include/_usr_local_opt_tinyxml_include/tinyxml.h'
Which I tried to fix by replacing glob("include/**")
to glob('include/**/*.h')
in tools/workspace/pkg_config.bzl
This on first run fails with error: gist
While on second(sometimes third) run, the build succeeds??? How is this possible when I haven't changed anything between these successive runs. From what I suspect, the cause might be that in pkg_config.bzl, we are referencing to the files(paths) generated from symlink using glob. While in glob doc it states that:
1. Since glob() runs during BUILD file evaluation, glob() matches files only in your source tree, never generated files.
I am not sure, if symlink paths was meant by while stating generated files but some assumption of execution order(glob after symlink) seems to be breaking here. Can you suggest any workaround, that will let me build for source in any way(build all, run install_external_tools first). Meanwhile, I will look at continuous integration scripts as things are fine there.
I was able to reproduce this issue in ubuntu:bionic with this container.
Inspect with bazel aquery 'inputs(".*tinyxml.*", deps(//bar:bar))'
to quickly reproduce. First time finds no matching action while finds matches second time. Temporary workaround is to artificially trigger loading phase once with:
bazel aquery 'deps(//examples/acrobot:run_lqr)' > /dev/null
bazel build //examples/acrobot:run_lqr
I think bazel fetch
or bazel sync
should also do the job. Probably state this in documentation somewhere till fixed. Not sure for a fix, as similar approach is used here: rules_go
I have read the above, but I'm still unclear -- what is the bug in Drake that this issue is trying to highlight? What are the steps to reproduce, the expected results, and the actual result?
I was setting bazel cache path to external drive as I don't have enough space in machine. May be
different file system(symlinking capabilities) on external drive could have caused this issue and subsequent reproduction in docker container. Today, freshly built this repo by setting cache path with option --output_user_root
on Apple Journal formatted drive. Build was successful in first go without any workarounds. Closing this issue.
Hi, Till now I have been using drake with cmake installed(drake binary). Now that I had to do some changes in source itself, I tried building from source. But bazel build seems to be breaking.
System Info:
Build Command:
>bazel build //examples/acrobot:run_lqr
Build failed with error:
ERROR: An error occurred during the fetch of repository 'cc': Not a regular file: <bazel_tmp_build_path>/external/local_config_cc/wrapped_clang
Upon looking into recent changes in PR I tried to revert back that line to :cc_wrapper.sh This fixed the cc toolchain error, but then fcl library fails:looking up into this error, stumbled upon this link . In comment stated that, FCL_EXPORT may not be defined, but I am not sure how to fix this. I thought that this might be related to first wrapped_clang bug, and might be old compiler issue but that does not seems to be case:
as it is using llvm 11. Any hint on how I can fix this.