When starting bitbake I get the following info that the dependency cache is empty and parsing all recipes takes several minutes. This is very frustrating as with every bitbake command I have to wait 6-7 minutes only for parsing the recipes.
Loading cache: 100% | ETA: --:--:--
Loaded 0 entries from dependency cache.
Parsing recipes: 1% |# | Time: 0:06:20
From time to time the cache gets loaded correctly. So caching seems to work in principal, I just could not find out why it is not loaded most of the time.
I already tried to get rid of .lock files in the build directory, but this also did not solve the problem.
I found out that the bb_cache.dat file that is loaded does not exist. E.g it tries to load bb_cache.dat -> bb_cache.dat.8766c4ab6f5e02381cb595498695990e54b0e58d7e7aed06cfdf517975 which is not existing. Then it parses the recipies and at the end it generates this file that was missing before. Next time when starting bitbake it either loads the previously generated one or (most of the time) looks for a new file and does not find it again. And so on...
Are you changing any of the configuration between bitbake invocations? Are you updating any of the repositories or layers?
It will reparse only when some configuration file has been changed, be that a local.conf file, a bblayers.conf file, or a configuration file in one of the checkouts. "bitbake -D" which enables debug output might give some hints as to why it is reparsing too.
Related
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 have a bunch of unit tests which contain code like:
File file = new File("src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
This test is suddenly failing when running it with Maven Surefire and -DforkCount=0. With -DforkCount=1, it works.
Things I tried so far:
The file does exist. Windows Explorer, command line (copy & paste), text editors, Cygwin can all find it and show the contents. That's why I think it's not a permission problem.
It's not modified by the unit tests or anything else. Git shows no modifications for the last two months.
I've checked the file system, it's clean.
I've tried other versions of Java 8, namely 8u171 and 8u181. Same problem.
I've run Maven from within Cygwin and the command prompt. Same result.
Reboot :-) No effect :-(
More details:
When I see this problem, I start to see the "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" in other projects. That's why I tried forkCount=0 which often helps in this case to find out why the forked VM crashed.
This has started recently, maybe around the October 2018 update of Windows 10. Before that, the builds were rock solid for about three years. My machine was switched to Windows 10 late 2017, I think.
I'm using Maven 3.6 and can't easily try an older version because of an important bug that was fixed with it. I did see the VM crash above with Maven 3.5.2 as well.
It's always the same files which fail (so it's stable).
ulimit (from Cygwin) says:
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 2032
cpu time (seconds, -t) unlimited
max user processes (-u) 256
virtual memory (kbytes, -v) unlimited
I'm wondering if the "open files" limit of 256 only applied to Cygwin processes or whether that's something which Cygwin reads from Windows.
Let me know if you need anything else. I'm running out of ideas what I could try.
Update 1
Bernhard asked me to print absolute names. My answer was that I was already using absolute names but I was wrong. The actual code was:
File file = new File("src/main/java/com/pany/Foo.java");
if (!file.exists()) {
log.debug("Missing file {}", file.getAbsolutePath());
... fail ...
}
... do something with file...
I have now changed this to:
File file = new File("src/main/java/com/pany/Foo.java").getAbsoluteFile();
if (!file.exists()) {
log.debug("Missing file {}", file);
}
and that fixed the problem. I just can't understand why.
When Maven creates a forked VM to run the tests with Surefire, then it can change the current directory. So in this case, it would make sense that the tests work when forked but fail when running in the same VM (since the VM was created in the root folder of the multi-module build). But why is making the path absolute before the call to exists() fixing the issue?
Some background. Each process has a notion of "current directory". When started from the command line, then it's the directory in which the command was executed. When started from the UI, it's usually the folder in which the program (the .exe file) is.
In the command prompt or BASH, you can change this folder with cd for the process which runs the command prompt.
When Maven builds a multi-module project, it has to change this for each module (so that the relative path src/main/java/ always points to the right place). Unfortunately, Java doesn't have a "set current directory" method anywhere. You can only specify one when creating a new process and you can modify the system property user.dir.
That's why new File("a").exists() and new File("a").getAbsoluteFile().exists() work differently.
The latter will use new File(System.getProperty("user.dir"), "a") to determine the path and the former will use the Windows API function _wgetdcwd (docs) which in turn uses a field of the Windows process to get the current directory - in our case, that's always the folder in which Maven was originally started because Java doesn't update the field in the process when someone changes user.dir and Maven can only change this property to "simulate" changing folders.
WinNTFileSystem_md.c calls fileToNTPath(). That's defined in io_util_md.c and calls pathToNTPath(). For relative paths, it will call currentDirLength() which calls currentDir() which calls _wgetdcwd().
See also:
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/WinNTFileSystem_md.c
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/io_util_md.c
and here is the place where the Surefire plugin modifies the Property user.dir: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1060
When not forking, it's copied into the current VM's System properties: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1133
So I have checked via printing out the system properties with some simple tests.
During the tests via maven-surefire-plugin the user.dir will be changed to the root of the appropriate module in a multi module build.
But as I mentioned already there is a system property available basedir which can be used to correctly handle the location for tests which needs to access them via File...The basedir is pointed to the location of the pom.xml of the appropriate module.
But unfortunately the basedir property is not set by IDEA IntelliJ during the test run.
But this can be solved by a setup like this:
private String basedir;
#Before
public void before() {
this.basedir = System.getProperty("basedir", System.getProperty("user.dir", "Need to think about the default value"));
}
#Test
public void testX() {
File file = new File(this.basedir, "src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
}
This will work in Maven Surefire with -DforkCount=0 as well as -DforkCount=1 and in IDE's (checked only IDEA IntelliJ).
And yes that is an issue in Maven Surefire plugin changing the user.dir.
We might convince IDE's to support the basedir property as well ?
Aaron, we develop the Surefire. We can help you if you provide the path for this:
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
Pls post the actual path, expected path and basedir where your POM resides.
The theory would not help here. We are testing all the spectrum of JDKs 7-12 but we do not have the combination Cygwin+Windows which must be considered.
The code setting user.dir in Surefire you mentioned exists a decade.
I downloaded Clamwin source code and loaded the clamwin solution to visual studio(2010 professional) and successfully built all project without any errors. After clicking start without debugging(seting clamscan project as startup ) I'am getting bellow error on cmd-prompt.
LibClamAV Error:cl_load:No such file or directory: C:\Users\my-pc\Desktop\clamav-win32-clamav-0.99\contrib\msvc\Debug\Win32\db
-----------SCAN SUMMARY-------------
Known viruses: 0
Engine version: 0.97.8
Scanned directories: 0
Scanned files: 0
Infected files: 0
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.003 sec (0 m 0 s)
Press any key to continue . . .
I searched solution online and I got Clam is looking for it's database files and the directory doesn't have them, doesn't exist, or Clam doesn't have sufficient rights to access the files.
But how should I solve this? should I create file or directory in that path or should I make it find itself?
Just run freshclam -> downloads fresh vc db to predefined dir (DatabaseDirectory in freshclam.conf). Before you do this, you must set up the freshclam.conf.
Then set up the same DatabaseDirectory in clam.conf.
(There was a bug here for me. I was installing on Windows and used forward slashes all over the config files as dir delimiter of path. At DatabaseDirectory value i had to change my forward slashes to backslashes to be able to run clamdscan successfully)
Finally, try run clamscan.
Please, tell me, if it did not help.
As specified in question Clam is looking for it's database files and the directory, directory /db should be updated with database by Running the freshclam tool,to run freshclam(if there is an Error), download the freshclam.conf file and edit the file as required.Then click on start debugging from the debug menu. Clamscan scans current working directory. For more information on clamscan
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.
Recently, I got error
Warning: require_once(account_header.php): failed to open stream: No
such file or directory in
/home/contestium/dev/temp/dev.contestium.com.tpl.0oyr4na on line 1
Fatal error: require_once(): Failed opening required
'account_header.php' (include_path='.:/usr/share/pear:/usr/share/php')
in /home/contestium/dev/temp/dev.contestium.com.tpl.0oyr4na on line 1
I have disabled caching with
F3::set('CACHE',FALSE);
But it was not helpful for me. Any help will be appreciated. Thank you!
When using cached files, your relative path won't work, as the cached files are not in the original file's directory.
You'll either need to provide the full path to 'account_header.php', or add the path to the directory containing such to your include path. This can either be done in your php.ini file, or at [runtime][1].
It looks like the cached files are still being used, right? If you delete those files, will it fetch the original file (and not the cached files)?