How can I build a Linux kernel in Travis CI. I have added script: make menuconfig to my Travis config and it doesn't work and says
No output has been received in the last 10 minutes
How can I fix this?
Link to GitHub repo : https://github.com/ProjectPolyester/tegra_kernel and submit fixes in PRs if possible
Travis monitors your build process and if there is no output for about 10 minutes, it assumes that your process is stuck somewhere for unknown reasons, and then kills it.
Solution in your case :
You need to provide with the actual build command.
make menuconfig
actually just allows you to configure the kernel. It doesn't really starts the kernel build process. So there is no output of this command.
Also, the kernel should already be configured or you can download the appropriate .config file if its available some where online. And then there will be no need to execute:
make menuconfig
The build command
It can be simply
make
or something like
make -j3 modules ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOCALVERSION=-$SOURCE_VERSION
The second one is actually to perform cross compilation.
You also need to set all the prerequisites like downloading the header file etc
You may want to take a look at this script , it crosscompiles the modules only, not the entire kernel.
If you want to use the old config for a new kernel, you can use make olddefconfig. Here is my example how to compile and boot a new kernel in travis: https://github.com/avagin/criu/blob/linux-next/scripts/travis/kexec.sh#L54
I know that this is an old thread but I was recently able to get Travis CI working on building a Linux kernel
https://github.com/GlassROM-devices/android_kernel_oneplus_msm8994/commit/6ed484812bbd4a25c3b22e730b7489eaaf668da1
GCC fix is for toolchains compiled on Debian unstable, arch, gentoo, etc. These toolchains will fail to compile on Ubuntu so you'll have to use the GCC fix for these toolchains
And you really want to upgrade GCC before you even try building a kernel. Travis CI has a very old GCC that will fail if you try to compile the kernel
In my commit I'm building it with GCC 8 linaro built by myself
Related
I am using Rust to cross compile a CLI.
An issue I am having is that typically the Rust compiler only works flawlessly when it compiles for the same OS/arch as the host it is running on (otherwise there are missing components, e.g. dynamic libs or compiler toolchains).
I want to release a binary that I have compiled on my Mac, but I want to be able to archive all inputs so that I can recreate the build for any future security audits.
For Linux I am using Docker containers which snapshot all files used as input to the cargo build process.
But for my Mac I have no idea how to isolate the cargo install, or what other toolchains or dynamic libs it may be calling out to.
Thanks
I wrote a little game using Rust, and I used cargo build --release to compile a release version on Mac.
I tried to share this with my friend who is using Ubuntu, but when he tried to run the binary, he got the following error:
cannot execute binary file: Exec format error
I searched for this but found no answers. Doesn't Rust claim to have "no runtime"? Shouldn't it be able to run anywhere in binary form?
Rust not having a runtime means that it doesn't have a lot of code running as part of the language (for example a garbage collector or bytecode interpreter). It does still need to use operating system primitives (i.e. syscalls), and these are different on MacOS and Linux.
What you want is a cross compiler. If you're using rustup, then installing a cross compiler should be simple:
# Install the toolchain to build Linux x86_64 binaries
rustup target add x86_64-unknown-linux-gnu
Then building is:
cargo build --release --target=x86_64-unknown-linux-gnu
Caveat: I don't have an OS X machine to test this on; please comment or edit to fix this if it works!
Well, it is because Rust has no runtime (unlike e.g. Java's JVM) that you can't just compile code on one OS and expect it to run on a different one; what you are looking for is cross-compilation. I haven't done it in Rust, but from what I can gather you can find relevant information on different cross-compilation Rust strategies on this GitHub repo.
So, each time I modify the device tree I typically change the dts in a custom recipe and rebuild the image. The rebuild takes a long time since it rebuilds the entire kernel, and then the image needs to be built and finally deployed to the target device.
Is there any trick that I'm missing that rebuilds only the device tree?
UPDATE:
I've marked g0hl1n's answer as the correct one, since it is the answer to my question. However, I found it to be very cumbersome to work with the kernel in Yocto: strange, long paths and risk of files being overwritten on each rebuild, source of kernel in tmp/work-shared while the kernel is being built in tmp/work.
Instead I've moved the kernel development out of Yocto. Yocto has good tools for creating an SDK (see populate_sdk task) and with that it's easy to setup an environment for kernel development with quick rebuilds and manual (or scripted) deployments. Once the work is done the changes can be moved to a recipe using git diff.
The instructions on the following page was very helpful: http://jumpnowtek.com/beaglebone/Working-on-the-BeagleBone-kernel.html
AFAIK there are two different ways of doing this.
The kernel way: Using the scripts provided by the kernel
Change to your kernel source directory (<build dir>/tmp/work/<machine>/<kernel-name>/<kernel-version>/git/)
Execute the device-tree-compiler: ./scripts/dtc/dtc -I dts -O dtb -o ./devicetree.dtb path/to/devicetree.dts
The bitbake way: Using the kernel's deploy job
Call $ bitbake <kernel-name> -f -c deploy
The generated device-tree-blob then can be found in <build dir>/tmp/work/<machine>/<kernel-name>/<kernel-version>/build/arch/arm/boot/dts/)
At least for me both versions worked in a quick test.
UPDATE:
I just came over a third version of building the dtb with yocto on the net.
That one uses yocto's devshell of the kernel build.
For more information see the original authors page at https://splefty.blogspot.co.at/2015/09/compiling-device-tree-using-yocto.html.
For me using bitbake to regenerate the device tree worked in the following way:
Command: $ bitbake <kernel-name> -f -c compile
Example: $ bitbake linux-fslc -f -c compile
Tested using yocto sumo.
I am using msys2 Mingw (gcc 4.8.2 for i686 32-bit) for building Ghostscript 9.10. After running make, gs.exe was created successfully. Followed by that I ran "make so" for creating libgs library. Libgs.so, Libgs.so.9.10 were created which are of the same file size. But I found both of them to be PE executables. After renaming extension to .exe, they produced the same output as done by gs.exe. What I require is libgs.dll, libgs.a to be created, but instead "make so" creates libgs.so which is in fact a PE executable. I also tried using patch found on site:https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-ghostscript/mingw-build.patch, but still the output remains the same. Has anyone been successful in this? Kindly help me.
I presume if you follow the steps taken in the build script connected to the patch you linked, everything will work out fine. I think most of it is just to make it use the "system"'s 3rd party libraries instead of those in the GS source. I'd guess running the configure command would do.
Alternatively, you could just download the MSYS2 base system from here, and do a pacman -Syu mingw-w64-i686-ghostscript. It should download and install the binary package without you having to build it yourself.
If you really want to build it yourself, download the PKGBUILD and patch, and run makepkg from the aforementioned MSYS2 shell and have that build it for you.
Have just completed testing of gs 9.15 built executables using the a patch
MINGW-packages-master.zip from https://github.com/Alexpux/MINGW-packages
Without implementing the zlib patch and PKGBUILD and using a MINGW 4.7.3 32/64
without by ghostscript used libs installed.
They did not work as is while using msys1 pathe'd up ahead of Windoze.
I simply edited the the MINGW Build and 32/64 bit type in makefile in
and set them to =1 there. and as i built without GTK defined in ./configure
SOC_LOADER_PLAIN manually to gs.c
Check the makefile after ./configure ahead of make or make so though , , .
All went well except for the COMPILE_INITS
mkromfs build that failed so I had to set that to =0 and build without that
feature. For me personally preferred as one can patch the gs fonts and libs
much easier.
The builds run as charm with full cpu optimisers implemented
only disabling gcse and guess-branch-probability, easily outperforming
the binaries provided by http://www.ghostscript.com/ by all means.
HPC !
I'm trying to build a cross-compiler (x86->64) on my windows system, with the aim of targetting windows 64, however my software currently relies on open source libraries which also have open source dependencies for which there are no prebuilt binaries available with which I can compile. This means that if I want the 64 bit versions I need to compile them.
I've installed MSYS and mingw, I'm also in the process of adding mingw-w64 to the mix so that I can finally compile the libraries in 64 bit form for use with my software. I'm following the steps as closely as I can using these instructions and in the order listed on that page, I'm currently at the step titled "Building the GCC core cross-compiler(s)", but when I try to compile with the line:
$ ../gcc-4.6.1/configure --target=x86_64-w64-mingw32 --enable-targets=all && make -j 6 all-gcc && make -j 6 install-gcc
I get the output pasted here. I should note that I of course snipped the previously executed commands and that last command was the last one listed before all the errors were displayed. Also, I have no idea if it's the cause of all the errors due to the '-j 6' argument, but everything prior to it at least looked successful.
What's the problem and how can I fix it?
Oh, in anticipation of one potential suggestion; no I can't just switch to cygwin.
Edit: Okay after executing them individually, here's the output of the configure command, the output produced by make all-gcc (no -j argument), and config.log. Note, I didn't run a make clean beforehand which may explain the different ending, I didn't do it in the interest of time to write this update, but I suppose I'll just make a different compile folder and re-execute it cleanly to hopefully see the same error as before while I wait for a response.
Edit 2: The make all-gcc failed again as expected, this time the output should help a little more I hope.
Thanks very much for your help.
Your config.log shows that the build process will use the binaries in x86_64-w64-mingw32/bin for stuff like ar, as etc... These are for internal compiler use only, and they should all be available in your /mingw/bin directory. I would strongly suggest asking on the mingw-w64-public mailing list for help.