I encountered the problem that I wanted to have a debug, then I wanted to build a debug version of tensorflow, using the following command:
bazel build --compilation_mode=dbg -s //tensorflow/tools/pip_package:build_pip_package
but it will trigger the longtime link in protobuf for almost oneday, and still not finished.
and my intension is to build some other package which is used by tensorflow with debug mode, could I configure the bazel build file to get some debug package separately?
To understand the issue better, try running the neverending action manually:
start the debug build, wait for it to get stuck in the protobuf linking action
interrupt the build (Ctrl+C)
run the build again with the -s flag, so Bazel shows the command line it executes (you could've ran step 1. with the -s flag, but then there's a lot more output and it's harder to find the right information)
interrupt the build again
cd into the directory shown in the by command and set environment variables
try running the command that failed (you may need to change the output paths because they are sometimes not user-writable) and see if it still never finishes
What you just did is running the same command Bazel was running and getting stuck on. If the command is stuck in this manual mode too, then the error might be with the linker (I doubt this is the case though). But if it succeeds, then the problem is with Bazel.
Related
I want to run a program on my Macbook.
First I run it with go run main.go. It is compiled successfully but indicates permission denied when running.
So I switch to sudo go run main.go. but it fails in the compiling stage, showing compile: version "go1.17.8" does not match go tool version "go1.18".
then after some tries, I find this file named ～/Library/Application\ Support/go/env which sets the configuration GOROOT=~/sdk/go1.17.8.
I cannot figure out what leads to these.
I am using git inside of a vsproj file as generated from CMake. It is producing a CUSTOMBUILD target that itsself is a command sequence that checks out a git repo from google chromium source.
CUSTOMBUILD : warning : subprocess '"git" "-c" "core.deltaBaseCacheLimit=512m" "clone" "--no-checkout" "--progress" "https://chromium.googlesource.com/external/webrtc.git" "build\_gclient_src_kpgzmk"' in build failed; will retry after a short nap... [webrtc-src.vcxproj]
Now if I run
git -c core.deltaBaseCacheLimit=512m clone --no-checkout --progress https://chromium.googlesource.com/external/webrtc.git build/_gclient_src_kpgzmk
it succeeds every single time, even if I give it a new folder as it does each time (with the stamp on the name)..
I am unable to get stdout from MSBuild on this issue it just says failed, trying after nap. Honestly this is pretty head scratching because its the same command line console 'Developer Command Prompt' console environment on Windows 11 with VS.NET 2022 tools installed. Again this is merely a shell command, git-scm installed and working.
[EDIT]
Went from 512m to 128m, thinking it could be a restriction on process memory invoked from MSBuild, but it errors in the same timeframe (around 11 seconds)
[/EDIT]
I am currently trying to get going with developing additional functionality for the MonetDB DBMS. I have been reading through the code and tried to debug the code using VSCODE which actually works fine. However, I encountered difficulties when trying to run tests that are already present in the repo using Mtest.py.
To come to the current point, I have forked the latest version of MonetDB (11.40.0) and proceeded with installing it on my ubuntu 20.04 by following the shipped debian documentation:
CONFIGURE_OPTIONS="-DCMAKE_BUILD_TYPE=Debug -DASSERT=ON -DSTRICT=ON"
cd build
cmake $CONFIGURE_OPTIONS
cmake --build .
cmake --build . --target install
The above statements install the applications in the default location. I have also tried to alter the installation direction using -DCMAKE_INSTALL_PREFIX flag. However, this lead to the same results and problems running the tests.
For running specific test cases I have tried the following two thing:
cmake: cmake --build . --target mtest
Mtest.py: Mtest.py sql/test/Tests/
Both attempts lead to the same console output:
Perl available, but MonetDB driver or DBI module not available
abort: there is no Mercurial repository here (.hg not found)
cannot write timeout message mserver5 --debug=10 --set gdk_nr_threads=0 --set mapi_listenaddr=all --set mapi_port=30201 --set mapi_usock=/var/tmp/mtest-16710/.s.monetdb.30201 --forcemito --dbpath=/usr/local/var/MonetDB/mTests
Mtest.py: ERROR: No output from mserver5 when checking for Bits, Modules & Threads!?
It states that the started mserver5 instance is not responding properly somehow. I have currently no clue how to tackle this issue. Can anyone tell me if I might missed out on something?
I have checked the build flags and the corresponding TESTING flag is set on default. Is there anything I messed up with mserver5 or I might have to configure separately?
Looking forward to hearing from you,
Martin
I finally found the reason for my issue with running MonetDB's tests. Thanks to #Joeri van Ruth for making playing around with mserver5 application.
The problem was that I commented in the definition of _SQL_COMPILE in the file sql_execute.sql in order to view the generated MAL code and other debug output generated along compilation. The problem with this is that it calls mnstr_printf and is printing to stdout. This debug output to somehow interferes the required communication and mserver5 cannot respond correctly.
I'm running a project using Go Modules with 1.11.4 on Ubuntu, running in WSL.
My problem is that I'm having getting incremental builds to work as I expect. Perhaps this is due to me misunderstanding how it's supposed to, but I'd be glad if someone could clarify if that is the case.
Just as an example, if I do go build ./... then everything is built, as expected.
If I now do go build ./... again without any changes, my expectation was that due to the incremental builds, this time nothing would be built. But it builds everything again. I tried doing go build -i ./... (even though my understanding is that -i isn't needed anymore from 1.10), but the result is the same. This has been puzzling me for some time, as after reading the documentation I indeed expected the go build command to produce incremental builds.
The other day I realized that if instead I do go install ./... first, and then go install ./... again a second time, the second time around nothing is built, as I would expect. If I change a single module and run go install ./... again, then only that module is rebuilt, again what I would expect. So this gives me incremental builds.
So my questions are
1) Did I misunderstand go build ./... and how it handles incremental builds? Do I need to use go install instead?
2) Typically, we build the modules one by one, using the -o flag to specify an output path. Using go install instead, there is no -o option to specify an output path. Is there anything I can do to achieve something similar to -o using go install?
Thanks!
Trying to build go application using bazel. It fails due to multiple packages and source files present within the application.
OS: Mac OS (High Sierra)
Bazel version : 0.11.1 (homebrew)
Go rules: 0.11.0
Defined local_repository in WORKSPACE to get external dependencies
Running following command
bazel build //go-app
leads to error
Action failed to execute: java.io.IOException: Cannot run program
"/usr/bin/sandbox-exec" (in directory
"/TEMP_DIR/PATH"):
error=7, Argument list too long
Target //go-app:go-app failed to build
I came across https://docs.bazel.build/versions/master/skylark/lib/Args.html#use_param_file and thought it would fix my issue. Could anyone point me in the direction of how and where to implement this in my BUILD file and make it work? Thanks.
I think it's not in your BUILD file but rather in rules_go.
I'd recommend opening them an issue since AFAIK this is something the rule implementation needs to support.
For example in rules_scala we write the arguments to a file and then pass that file to the worker exactly like how you mention above.
https://github.com/bazelbuild/rules_scala/blob/master/scala/private/rule_impls.bzl#L274