I am trying to build chromium from source code following instructions at
https://chromium.googlesource.com/chromium/src/+/master/docs/linux/build_instructions.md
I have successfully built and tested chromium for amd device, Now I am trying to cross-compile it for arm device, However when I set the flag
target_cpu = "arm"
using
gn gen out/Debug --args='target_cpu="arm"'
I get the following error
ERROR at //build/config/linux/atk/BUILD.gn:13:1 (//build/toolchain/linux:clang_x86_v8_arm): Assertion failed.
assert(current_toolchain == default_toolchain)
^-----
See //ui/accessibility/BUILD.gn:294:20: which caused the file to be included.
configs += [ "//build/config/linux/atk" ]
Any leads would be appreciated
I have had the same issue where I tried building chromium on my Linux x64 server for an ARM based device, I was able to get past the issue by commenting the assert function out (as the function assert is usually for sanity checking based on my understanding). You can achieve this by modifying the file build/config/linux/atk/BUILD.gn and adding a # to the following code assert(current_toolchain == default_toolchain).
I followed the guidance on the webpage suggested by Asesh (followed Recipe 2) but the issue we are facing is to do with different current_toolchain and default_toolchain being set and would cause assert() to fail, the instructions given on the webpage doesn't seem to relate to out problem.(https://chromium.googlesource.com/chromium/src/+/master/docs/linux/chromium_arm.md)
To explain why I commented out the assert() code, reading https://www.chromium.org/developers/gn-build-configuration I found the following section: Snip of section "Overriding the CPU architecture".
As we both are configuring target_cpu="arm", this should be enough to configure and build chromium for our ARM devices (this would cause current_toolchain to be set to a different toolchain then default_toolchain, hence why assert() is giving us this error).
After commenting out the assert() I was successfully able to run gn gen out/xxx, gn args out/xxx and run autoninja to build chromium.
This issue has been fixed in Chromium:
https://chromium-review.googlesource.com/c/chromium/src/+/3074662
Related
First, take note that I am using the Xilinx SDK 2018.2 on Kubuntu 22.04 because of my companies policy. I know from research, that the command I'm using is deprecated in newer versions, but in the version I am using, it works flawlessly - kind of... But read for yourself:
My task is to automate all steps in the FPGA build to create a pipeline which automatically builds and tests the FPGAs. To achieve this, I need to build the code - this works flawlessly in XSDK. For automation, this also has to work in the command line, so what I did is following the manual to find out how this is achieved. Everything works as expected if I write it in the interactive prompt like shown here:
user#ubuntuvm:~$ xsct
****** Xilinx Software Commandline Tool (XSCT) v2018.2
**** Build date : Jun 14 2018-20:18:43
** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
xsct%
Then I can enter the commands I need to import all needed files and projects (hw, bsp, main project). With this toolset, everything works as expected.
Because I want to automate it via a pipeline, I decided to pack this into a script for easier access. The script contains exactly the commands I entered in the interactive shell and therefore looks like this:
user#ubuntuvm:~/gitrepos/repository$ cat ../autoBuildScript.tcl
setws /home/user/gitrepos/repository
openhw ./hps_packages/system.hdf
openbsp ./bsp_packages/system.mss
importprojects ./sources/mainApp
importprojects ./bsp_packages
importprojects ./hps_packages
regenbsp -bsp ./bsp_packages/system.mss
projects –clean
projects -build
The commands are identical to the ones entered via the interactive CLI tool, the only difference is that this is now packed into a script. The difference is, that this now does not build completely anymore. I get the following error:
user#ubuntuvm:~/gitrepos/repository$ xsct ../autoBuildScript.tcl
INFO: [Hsi 55-1698] elapsed time for repository loading 1 seconds
Starting xsdk. This could take few seconds... done
'mainApp' will not be imported... [ALREADY EXIST]
'bsp_packages' will not be imported... [ALREADY EXIST]
'hps_packages' will not be imported... [ALREADY EXIST]
/opt/Xilinx/SDK/2018.2/gnu/microblaze/lin
unexpected arguments: –clean
while executing
"error "unexpected arguments: $arglist""
(procedure "::xsdb::get_options" line 69)
invoked from within
"::xsdb::get_options args $options"
(procedure "projects" line 12)
invoked from within
"projects –clean"
(file "../autoBuildScript.tcl" line 8)
I've inserted projects -clean only, because I got the error before with projects -build and wanted to check, if this also happens with another argument.
In the internet I didn't really find anything according to my specific problem. Also I strictly held on to the official manual, in which the command is also used just as I use it - but with the result of it being working.
Also, I've checked the line endings (set to UNIX) because I suspected xsct to read maybe a newline character or something similar, with no result. This error also occurs, when I create the bsp and hardware from sketch. Also, to me the error looks like an internal one from Xilinx, but let me know what you think.
So, it appears that I just fixed the problem on my own. Thanks on everyone reading for being my rubber ducky.
Apparently, the version 2018.2 of XSDK has a few bugs, including inconsistency with their command interpretation. For some reason the command works in the interactive shell, but not in the script - because the command is in its short form. I just learned from a Xilinx tutorial, that projects -build is - even though it works - apparently not the full command. You usually need to clarify, that this command should come from the SDK like this: sdk projects -build. The interactive shell seems to ignore this fact for a reason - and so does the script for any command except projects. Therefore, I added the "sdk" prefix to all commands which I used from the SDK, just to be safe.
I cannot believe, that I just debugged 2 days for an error whose fix only contains 3 (+1 whitespace) letters.
Thanks everybody for reading and have a nice day
I'm pretty new to the yocto project so bear with me if these are trivial problems.
I followed this(https://hub.mender.io/t/preparing-the-yocto-project-environment-from-scratch/801) tutorial and was able to compile a minimal yocto image, flash that image to a SD card and run it on a raspberrypi3.
My next goal is to add the azure device update layer(https://github.com/hiroyha1/meta-azure-device-update)
I cloned the repository to the sources directory and tried to add this layer via bitbake. Since LAYERSERIES_COMPAT was set to "warrior" this failed. I changed that variable to "kirkstone" and updated the syntax in all bb files, basically changing _append/_prepend to :append/:prepend.
Now when I try to run bitbake adu-image-base I get this error:
ERROR: No recipes in default available for:
$MYWORKDIR/sources/meta-azure-device-update/recipes-bsp/u-boot/u-boot-fw-utils_%.bbappend
I searched for this error and found out that sometimes there are "dangling appends". As I found out a fix for that could be to set "BB_DANGLINGAPPENDS_WARNONLY ?= "true"" in the layer.conf.
After running bitbake adu-base-image again the next error is:
ERROR: adu-base-image-1.0-r0 do_rootfs: Could not invoke dnf. [...]
No match for argument: adu-agent-service Error: Unable to find a
match: adu-agent
So I'm pretty stuck here. I think that the dangling appends are the reason for that error - the adu-agent-service isnt build so cannot be packed in the image, for me this makes sense since the root_fs is part of the OTA functionality. My approach would be to revert the "BB_DANGLINGAPPENDS_WARNONLY" change and get this layer to build properly, but I'm struggling to debug this further.
So how can I get this layer to work with the kirkstone release?
P.S if the proposed layer is utterly broken and there is no easy way to get this to work with the kirkstone release a hint would be great.
I'm trying to follow the instructions outlined here:
http://www.webrtc.org/native-code/development#TOC-Before-you-start;
but "fetch webrtc" fails with a message that implies a file (src/buildtools/linux32/gn.sha1) is not found. See this post for more detail on the error message:
https://groups.google.com/forum/#!topic/discuss-webrtc/Dt-GRIlLVe4
I've walked through installation of all the "prerequisite software" as described on the above page, but consistently hit the same error. I'm doing this from a Ubuntu 14.04 LTS machine, any thoughts on what I might be doing wrong?
gn is a replacement for gyp to generate Ninja files. I don't think it's required yet (gn is a work-in-progress), but that's likely what you're missing. You could comment out gn from the DEPS and see if things work.
Answering my own question here...
It appears that the problem is related to the fact that I am behind a proxy
and the --no_auth option is used (in depot_tools) when the download_from_google_storage.py script is called.
After reading this post: https://github.com/GoogleCloudPlatform/gsutil/issues/241
I modified my copy of "download_from_google_storage.py" so that the --no_auth option would have no affect. I also created a ~/.boto file with three lines:
[Boto]
proxy = my.proxy.goes.here.com
proxy_port = PROXY_PORT_NUMBER
Then I re-ran "fetch webrtc" and it completed successfully in about 75 minutes.
Go figure...
I wrote a basic character driver for beagle-bone which prints two message in 1 second interval via a workqueue and a tasklet using printk.
At first i build it as module driver, generated .ko file, load it using insmod command and the print is coming when viewed via dmesg.
Then i built as inbuilt driver and load the uImage and after bootup i checked the dmesg prints. But there is no prints.
In the .config file
CONFIG_MY_DRIVER=y
So its taken as built in driver i think.
How can i confirm whether its actually built in the final image. No error was reported while building.
Is there any additional steps to be done for loading the build in driver.
Please pardon me if i went wrong on any basics. I am really new to linux.
This means that you added it probably somewhere to Kconfig file:
"CONFIG_MY_DRIVER=y"
but, Have you added it to Makefile? It works like that, then kernel during a building an Image, takes all of this directives "CONFIG_*" and use it to build particular source files from Makefile.
Example:
cat fs/ext2/Makefile
ext2-$(CONFIG_EXT2_FS_SECURITY) += xattr_security.o
cat fs/ext2/Kconfig
config EXT2_FS_SECURITY
bool "Ext2 Security Labels"
depends on EXT2_FS_XATTR
so in this example above if your source file is xattr_security.c then you should get xattr_security.o file in fs/ext2 dir, when this is build. You should also see it if your file is build, during a compilation process.
When I am trying to make executable files of my .m-files on a Linux machine, some of the the .m-files are working absolutely fine.
However, one file which has camera input inside the .m-file is giving me this error:
Depfun error: 'Unexpected Standard exception from MEX file. What() is: ..' Error using mcc Error executing mcc, return status = 1 (0x1).
But when I use the same .m-file on Windows and R2012a it is working properly without any error.
I found a bug report here - is this a similar problem?
How do I solve it?
Here is the simple code of my .m-file:
function yuv()
vid1 = videoinput('linuxvideo', 1, 'YUYV_1280x960');
set(vid1,'FramesPerTrigger',1);
start(vid1);
imageData1=getdata(vid1,1);
imageData=ycbcr2rgb(imageData1);
imagesc(imageData(:,:,:,1));
end
I was getting the same Depfun error, "What() is: ..", under R2013a on Linux but no errors when using a different OS or an older MATLAB version to compile my code. Following the bug report you linked to fixed it for me.
In the zip file linked to in the bug report you'll find a depfun.opts file. Rename or move your original depfun.opts file that's located in [matlabroot]/toolbox/compiler and copy the new one in its place.
Putting the new depfun.opts file in place is all it took for me to be able to compile using R2013a on Linux.
Also note, the bug report says that it could be caused by the importdata function or the Parallel Computing Toolbox but I'm not using either of those.