I am using travis-ci and biicode to build my project who is depending on boost log. But boost log times are longer than 10 min so I get this message:
No output has been received in the last 10 minutes, this potentially indicates a
stalled build or something wrong with the build itself.
The build has been terminated
The build is working correctly, it's just that boost log is really long to compile with limited resources (I tried to compile it on a VM with 1 CPU and 2GB of RAM and it took almost more than 15 min)
I know this is happening because there is not enough verbose going on so I tried the following flags:
>bii cpp:build -- VERBOSE=1
In the CMakeList.txt, set BII_BOOST_VERBOSE ON as mentionnened here
Set BOOST_LOG_COMPILE_FAST_ON as explained here
Using travis_wait
Actually travis_wait seems to be the correct solution but when I put it in my .travis.yml like this
script: travis_wait bii cpp:build
It does actually doesn't output logs like usually and just time out after 20 min. I don't think the actual building is taking place
What is the correct way to handle this problem?
This is a known issue, Boost.Log takes a long time to compile.
You can use travis_wait to call bii cpp:configure, but I'm with you, I need log feedback (No pun intended). However, I have tried that too and leaded to >50min build, which means travis aborts build on free accounts :( Of course my repo does not build Boost.Log only.
Just as a note, here's part of the settings.py file from the boost-biicode repo:
#Boost.Log takes so much time to compile, leads to timeouts on Travis CI
#It was tested on Windows and linux, works 'ok' (Be careful with linking settings)
if args.ci: del packages['examples/boost-log']
I'm currently working on a solution, launching asynchronous builds while printing progress. Check this issue. It will be ready for this week :)
To speed-up your build, try to play with BII_BOOST_BUILD_J variable to set the number of threads you want for building Boost components. Here's an example:
script:
- bii cpp:configure -DBII_BOOST_BUILD_J=4
Be careful, more threads means more RAM needed to compile at a time. Be sure you don't make the travis job VM go out of memory.
Related
I want to compile Chromium for windows with different patches from different projects for myself (at least for today). I follow this official instruction:
https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md
All steps successfully passed, but i get awful low perfomance. In speeDOMeter benchmark (https://browserbench.org/Speedometer2.0/) my build get only 5 points, while official build get 116! This is commands for GIT what i use:
gclient
mkdir chromium && cd chromium
fetch --no-history chromium
cd src
gn gen --ide=vs out/Default "--args=target_cpu=\"x86\""
autoninja -C out/Default chrome -j 6
What i was try and this is not help:
Delete depot tools folder, and start over
Decrease -j from 10 to 8 and to 6
Delete argument --ide=vs
Fetch with history
Use command "gn gen" without --args part
Disable windows defender & firewall
As Asesh correctly noted, the problem was in debug mode. But adding key "is_debug=false" to gn gen command is not enough. The best solution will be the adding "is_official_build=true" key. Here is description:
is_official_build
Current value (from the default) = false
From //build/config/BUILDCONFIG.gn:136
Set to enable the official build level of optimization. This has nothing
to do with branding, but enables an additional level of optimization above
release (!is_debug). This might be better expressed as a tri-state
(debug, release, official) but for historical reasons there are two
separate flags.
IMPORTANT NOTE: (!is_debug) is *not* sufficient to get satisfying
performance. In particular, DCHECK()s are still enabled for release builds,
which can halve overall performance, and do increase memory usage. Always
set "is_official_build" to true for any build intended to ship to end-users.
Thanks Asesh for pointing me in the right direction.
I want to build a PetaLinux Image for my Ultra96v2.
I followed this guide up until building my application project in Vitis. It looks promising but then while building the application project for my custom platform, Vitis throws this error:
18:08:28 **** Incremental Build of configuration Debug for project dpu_appl_system ****
make all
Generating bif file for the system project
Executing command '::scw::generate_bif -xpfm /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_demo/export/dpu_demo/dpu_demo.xpfm -domains linux_domain -bifpath /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/system.bif' on XSCT
sdcard_gen --xpfm /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_demo/export/dpu_demo/dpu_demo.xpfm --sys_config dpu_demo --bif /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/system.bif --bitstream /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl/_ide/bitstream/dpu_hardware.bit --sd_file /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl/Debug/dpu_appl.elf
creating BOOT.BIN using /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl/_ide/bitstream/dpu_hardware.bit
Running /home/user/Xilinx/Vitis/2021.2/bin/bootgen -arch zynqmp -image /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif -w -o i BOOT.BIN
ERROR:BootGen - syntax error
Line #13, "/media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif".
... emo/sw/atf,dpu_demo/boot/bl31.elf
^
[ERROR] : BIF file parsing failed with code 1
Error writing SD card data : Error when running '/home/user/Xilinx/Vitis/2021.2/bin/bootgen -arch zynqmp -image /media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif -w -o i BOOT.BIN'
make: *** [makefile:42: package] Error 1
18:08:36 Build Finished (took 7s.643ms)
It specifically shows me, that there is a comma in the path where it searches for the file. The files are available
at the "normal" location, without the "atf,", "dtb,", etc
at the "weird" location. I created the path so the requested path exists for every file that throws an error message, like
/media/user/6b04b610-ff80-4702-a575-b0b1a78fbafb/dpu_pkg/dpu_appl_system/Debug/sd_card_temp/boot.bif". ... emo/sw/atf,dpu_demo/boot/bl31.elf
I created the path with the weird artefact "arf,dpu_demo", with the komma in the path, but still it wont work. Is this some kind of problem with Vitis, like some env variables not set correctly, or is the building mechanism just acting weird? I cant resolve this issue, because I am not able to change the paths it is supposed to look for the files. This hinders me in advancing my project. I work on Ubuntu 20.04.
Can anyone help me out here, please? I would really appreciate it!
I asked this question in the Xilinx Community, too, but unfortunately there was no resonance at all.
Thank you so much in advance!
PLEASE READ THE WHOLE ANSWER FOR ACTUAL SOLUTION
I think I got it now, though I did not verify whether the image actually works on my Ultra96v2, yet.
I noticed, that the weird path with commata is inside of the boot.bif and system.bif.
So the first time I tried to build it, the bif wasnt there, but got created (I assume). The bif was ready then but only had a weird path inside, so I took the makefile (you can find it in debug/sd_card), copied it, and just commented out the line GENERATE_BIF_XSCT_CMD = ${GENERATE_BIF} -xpfm ${XPFM_PATH} -domains ${DOMAINS} -bifpath ${BIF_PATH}.
Then I edited the boot.bif and system.bif and changed the atf,boot, uboot,boot, and dts,boot to just boot, so the BootGen wouldnt look into the directories with the commata anymore, but only the boot-directory which was specified.
Once that was set up, I executed the edited makefile in my console, by going into the sd_card-directory and executing the following command:
make -f <your_edited_makefile>
This means, that you cant press "build" in Vitis, it wont work. You build the content on your own and wont get a green check mark beside the project! Then the sd_card-directory was populated with (I assume) all necessary data to boot the Ultra96v2 from SD card. This was the content:
boot.scr
BOOT.BIN
dpu_appl.elf (your application project name, I guess)
README.txt
system.dtb
The underlying issue seem to have been that the ::scw::generate_bif created a path to look after, which didnt exist. Really weird issue, in my opinion.
UPDATE:
I just made some changes to the PetaLinux config with the petalinux-config command and rebuilt everything. Once I go to the Vitis part, I changed the system.bif within Vitis itself, and the project compiled successfully, also populating the sd_card directory, as it seems.
UPDATE 2:
Everything failed, so I tried to get to the *.bif of the Application System project. I opened it (linux.bif) and edited the "atf,", "dtb," and "uboot," out of it. Since this is only created once and references by the following files, this fixed my issue and the build was completed successfully in Vitis. So just ignore my originial answer and update.
I hope this is working and hope it will help some of you.
I don't know if someone else is running into this problem. I have this main.go file:
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
when I run go build, it takes 5 secs to run it (regardless if it is the first time I run it or if it is the second time)
PS> Measure-Command {Start-Process go build -wait}
Days : 0
Hours : 0
Minutes : 0
Seconds : 5
Milliseconds : 151
Ticks : 51514117
TotalDays : 5.96228206018519E-05
TotalHours : 0.00143094769444444
TotalMinutes : 0.0858568616666667
TotalSeconds : 5.1514117
TotalMilliseconds : 5151.4117
But when I run it on a linux machine:
time go build
real 0m2.017s
user 0m0.054s
sys 0m1.915s
and when I run it for the second time:
time go build
real 0m0.120s
user 0m0.072s
sys 0m0.088s
This is not only build, but also some of go tools such as fmt. It takes 0.12 seconds on linux, but almost 3 seconds on windows. Other tools like guru, gocode, etc. suffer the same problem, making code development very slow.
I'm using golang 1.11. I'm using an SSD and everything is running locally. Sorry I wish I could be more helpful but I really have no idea where to start to debug this.
Does anyone has an idea what's going on?
It seems that the build cache is disabled on your Windows and enabled on your Linux.
Go build keeps the result of compilations and reuse it if the .go file hasn't changed. That's why your second build is so fast in Linux.
If you disable it, not only your code, but also all the dependancies must be recompiled each time. Thus even if you change your code, all the libs (here "fmt") are already in cache.
To test it, run go clean -cache before the go build on Linux, and see if the time correspond to the time on your Windows. Then if it matches, you have to find why the build cache is disabled on Windows.
You can see the cache directory by typing go env GOCACHE. If the response is off, the cache is off. Otherwise verify that the repository exists and it has the right permissions.
You can choos the cache directory by setting the value of the GOCACHE environment variable (sorry I don't know how to do this in Windows).
I was having same issue. Turns out I had a really big directory with 1000s of large files in the same location where the binary was. Moving the big dir out to a different location resolved the issue. This was in a macOS.
I'm having trouble with a Jenkins pipeline.
The thing is, it seems one of the steps is running in parallel with another (not intentionally):
I have something like:
...
step("build"){
bat [Visual Basic 6 compile command - vb6.exe file.vbp /outdir my/directory]
if(fileExists("my/directory/output.dll"){
println "SUCCESS"
}else{
error("error")
}
...
}
Ok, the problem is: it checks if the files exist before it's written by the compile command... If I put a sleep 10 before the condition, it always runs OK (for now), but obviously, I don't want to have a sleep command in my pipeline.
I don't know if I can control better the order os execution or if maybe the fault lies in the vb6.exe that creates a thread to write the output and then the main thread returns success before the output being written... does this make sense? Does anyone know how may I solve this problem?
My solution is to make the VB6 compilation step blocking.
This is what I run when working locally on my machine:
cmd /c VB6.exe /make someproject.vbp
And it is also the approach used by the Jenkins Visual Basic 6 plugin (I am the author). See this.
I just got started learning Haskell. And I chose to work with it on my PC through stack. First day, I worked with Chris Allen's tutorial and got stuck at the stack build part of it. The command exited with an error as shown below:
C:\Users\USER\haskellProjects\bassbull>stack build
primitive-0.6.2.0: download
integer-logarithms-1.0.2: download
primitive-0.6.2.0: configure
primitive-0.6.2.0: build
integer-logarithms-1.0.2: configure
integer-logarithms-1.0.2: build
primitive-0.6.2.0: copy/register
integer-logarithms-1.0.2: copy/register
Progress: 2/11Running C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\
ghc-8.0.2\bin\ghc-pkg.EXE --user --no-user-package-db --package-db C:\sr\snapsho
ts\1602ab97\pkgdb describe --simple-output integer-logarithms --expand-pkgroot e
xited with ExitFailure 1
WARNING: cache is out of date: C:/Users/USER/AppData/Local/Programs/stack/x86_64
-windows/ghc-8.0.2\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
ghc-pkg.EXE: cannot find package integer-logarithms
Running C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\
ghc-pkg.EXE --user --no-user-package-db --package-db C:\sr\snapshots\1602ab97\pk
gdb describe --simple-output primitive --expand-pkgroot exited with ExitFailure
1
WARNING: cache is out of date: C:/Users/USER/AppData/Local/Programs/stack/x86_64
-windows/ghc-8.0.2\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
ghc-pkg.EXE: cannot find package primitive
C:\Users\USER\haskellProjects\bassbull>stack exec ghc-pkg recache
C:\Users\USER\haskellProjects\bassbull>stack build
integer-logarithms-1.0.2: configure
integer-logarithms-1.0.2: build
primitive-0.6.2.0: configure
primitive-0.6.2.0: build
integer-logarithms-1.0.2: copy/register
primitive-0.6.2.0: copy/register
Progress: 2/11Running C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\
ghc-8.0.2\bin\ghc-pkg.EXE --user --no-user-package-db --package-db C:\sr\snapsho
ts\1602ab97\pkgdb describe --simple-output primitive --expand-pkgroot exited wit
h ExitFailure 1
ghc-pkg.EXE: cannot find package primitive
Running C:\Users\USER\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\
ghc-pkg.EXE --user --no-user-package-db --package-db C:\sr\snapshots\1602ab97\pk
gdb describe --simple-output integer-logarithms --expand-pkgroot exited with Exi
tFailure 1
ghc-pkg.EXE: cannot find package integer-logarithms
C:\Users\USER\haskellProjects\bassbull>
After trying out other tutorials I concluded that this happened only when trying to install external packages and dependencies.
Please I need help getting past this challenge I am facing, as I am very much enthusiastic about learning to code in (and coding in) Haskell.
The problem has been resolved. Much thanks to Michael Sloan on the Haskell-stack google group and Yuji Yamamoto on on Google+.
I'll just document what I did here:
I had felt my antivirus software was messing things up (in retrospect, the signs started showing up weeks back) so I updated it.
I did a clean uninstall of stack, hunted down its associated files/folders and wiped them off.
Then I reinstalled stack.
And started again with the tutorial mentioned in the question (No, Stack Overflow, I don't have 10 points to spare, thank you!).
I made sure to be connected to a steady network while doing stack setup for the first time, so that everything got downloaded with ease (the other time, connection timed out endlessly while fetching ghc and msys).
When that was done, I restarted the shell.
... and stack build completed successfully.
Now, I don't know exactly what did it for me, but I would love to. If it helps, I was (and I'm still) using stack-1.5.1 on a 64-bit windows7 PC.
Now I don't have to dump haskell for F#.