OpenWrt Buildroot – About 编译过程

OpenWrt Buildroot is a set of Makefiles and patches that allows users to easily generate both a cross-compilation toolchain and a root filesystem for embedded systems. It is a heavily modified Buildroot. The cross-compilation toolchain uses uClibc, a tiny C standard library.

A compilation toolchain is the set of tools used to compile code for your system. It consists of:

? a compiler (in our case, gcc / deb: gcc) ? binary utils like assembler and linker (in our case, binutils / deb: binutils ) ? a C standard library (for example GNU Libc, uClibc or dietlibc).

Using a PC, the compilation toolchain runs on an x86 processor and generates code for a x86 processor. On most Linux systems, the compilation toolchain uses the GNU libc as C standard library. It is called the "host compilation toolchain", and the machine it is running on is called the "host system". The compilation toolchain is provided by the distribution, and has nothing to do with OpenWrt Buildroot.

Embedded systems use a different processor and require a cross-compilation toolchain - a compilation toolchain that runs on a host system but that generates code for a target system (and target processor‘s instruction set architecture (ISA)). For example, if your host system uses x86 and your target system uses MIPS32, the regular compilation toolchain of your host runs on x86 and generates code for x86, while the cross-compilation toolchain runs on x86 and generates code for MIPS32.

While it is possible to manually configure and compile your own software, OpenWrt Buildroot automates this process to work on the instruction set architecture of most embedded systems.

While the OpenWrt Buildroot was designed for developers, inexperienced users can also use it to easily build their own custom firmware!

The OpenWrt Makefile has its own syntax, different from the conventional Makefile of Linux make tool. The OpenWrt Makefile defines the meta information of the package, where to download the package, how to compile, where to install the compiled binaries, etc. See How to Build OpenWrt Application Package for more detail.

OpenWrt Buildroot – Features ? Makes it easy to port software ? Uses kconfig (Linux Kernel menuconfig) for configuration of features ? Provides integrated cross-compiler toolchain (gcc, ld, …) ? Provides abstraction for autotools (automake, autoconf), cmake, scons ? Handles standard download, patch, configure, compile and packaging workflow ? Provides a number of common fixups for badly behaving packages

OpenWrt Buildroot – Make Targets ? Offers a number of high level make targets for standard package workflows ? Targets always in the format "component/name/action", e.g. "toolchain/gdb/compile" or "package/mtd/install" ? Prepare a package source tree: package/foo/prepare ? Compile a package: package/foo/compile ? Clean a package: package/foo/clean

OpenWrt Buildroot – Build sequence

  1. tools – automake, autoconf, sed, cmake
  2. toolchain/binutils – as, ld, …
  3. toolchain/gcc – gcc, g++, cpp, …
  4. target/linux – kernel modules
  5. package – core and feed packages
  6. target/linux – kernel image
  7. target/linux/image – firmware image file generation

Patch management ? Many packages will not work as-is and need patches to work on the target or to even compile ? OpenWrt Buildroot integrates quilt for easy patch management ? Turn package patches into quilt series: make package/foo/prepare QUILT=1 ? Update patches from modified series: make package/foo/update ? Automatically rebase patches after an update: make package/foo/refresh

Packaging considerations ? Main objective is small memory and size footprint ? Features that make no sense on embedded systems get disabled through configure or are patched out ? Packages must be compilable regardless of the host system, should be self contained ? Shipped "configure" scripts are often faulty or unusable in a cross-compile setting, autoreconf or patching needed ? Build variants and kconfig includes allow for configurable compile-time settings ? There is no standard way for porting software, in many cases it "just works" but often the package build process needs tweaks

本文章由http://www.wifidog.pro/2015/08/07/openwrt-%E7%BC%96%E8%AF%91%E8%BF%87%E7%A8%8B.html 整理编辑,转载请注明出处

时间: 2024-11-15 21:21:16

OpenWrt Buildroot – About 编译过程的相关文章

OpenWRT 编译过程

一.使用Ubuntu编译OpenWRT源码 第一步:安装基础软件 sudo apt-get install subversion g++ zlib1g-dev build-essential git python rsync man-db sudo apt-get install libncurses5-dev gawk gettext unzip file libssl-dev wget zip time 第二步:克隆代码 git clone https://git.openwrt.org/o

openWRT自学---自己编译的第一个 backfire10.03 版本的过程记录(转)

基于 backfire10.03(从http://downloads.openwrt.org/backfire/10.03/ 中下砸的源码包backfire_10.03_source.tar.bz2:后来确认不应该从这里下载:而是应该从svn下载),编译用于H618B的版本 -- BRCM53xx:过程记录如下: 1.sdk自带的luci版本是0.9.0,结果编译luci出错: /home/hadoop/openwrt/backfire_10.03/build_dir/target-mipsel

2.4、uboot配置和编译过程详解

2.4.1.uboot主Makefile分析1 2.4.1.1.uboot version分析 (1)uboot版本号分为3个级别: VERSION:主版本号 PATCHLEVEL:次版本号 SUBLEVEL:再次版本号 EXTRAVERSION:另外附加的版本信息 这四个用.隔开共同构成了最终的版本号. (2)Makefile中版本号最终生成了一个变量U_BOOT_VERSION,这个变量记录了Makefile中配置的版本号 (3)include/version_autogenerated.h

FFmpeg在Linux下安装编译过程

转载请把头部出处链接和尾部二维码一起转载,本文出自:http://blog.csdn.net/hejjunlin/article/details/52402759 今天介绍下FFmpeg在Linux下安装编译过程,用的是CentOS, 总体过程比较顺利,就是在ffmpeg等的时间稍长点.没什么技术难点.仅当记录. 关于FFmpeg FFmpeg是一个开源免费跨平台的视频和音频流方案,属于自由软件,采用LGPL或GPL许可证(依据你选择的组件).它提供了录制.转换以及流化音视频的完整解决方案.它包

编译过程中,termcap.h 文件找不到路径 licli.a终于生成

编译过程中,termcap.h      文件找不到路径 查看是linux  源码下找不到termcap.h文件 安装了所有关于*cap*的源码包也不起作用 今天终于解决了这个问题,搜termcap.h  发现一篇文章,如下 ----------------------------------------------------------------------------------------- 安装minicom2.3出现termcap.h错误解决方法 2010-05-06 17:12:

GCC与编译过程

GCC与编译过程   GCC(GNU Compiler Colletion),GUN编译器套装,是一套由GNU开发的编程语言编译器.Linux系统下的GCC编译器实际上是调用其他不同的工具来完成预处理.编译.汇编和链接工作. 一.编译过程 在计算机的眼里,只有1和0.不幸的是,我们用C语言写出来的代码,计算机无法直接看明白.所以一个程序如果需要被计算机执行,那么就必须翻译成能被计算机读懂并执行的1和0.实现这一结果的过程,我们称之为编译. 编译包括以下步骤:预处理.编译.汇编和链接.具体过程如下

Hive SQL的编译过程

Hive是基于Hadoop的一个数据仓库系统,在各大公司都有广泛的应用.美团数据仓库也是基于Hive搭建,每天执行近万次的Hive ETL计算流程,负责每天数百GB的数据存储和分析.Hive的稳定性和性能对我们的数据分析非常关键. 在几次升级Hive的过程中,我们遇到了一些大大小小的问题.通过向社区的咨询和自己的努力,在解决这些问题的同时我们对Hive将SQL编译为MapReduce的过程有了比较深入的理解.对这一过程的理解不仅帮助我们解决了一些Hive的bug,也有利于我们优化Hive SQL

C程序编译过程浅析【转】

转自:http://blog.csdn.net/koudaidai/article/details/8092647 前几天看了<程序员的自我修养——链接.装载与库>中的第二章“编译和链接”,主要根据其中的内容简单总结一下C程序编译的过程吧. 我现在一般都是用gcc,所以自然以GCC编译hellworld为例,简单总结如下. hello.c源代码如下: ?[Copy to clipboard] C 1 2 3 4 5 6 [c] view plaincopy <span style=&qu

Windows下Caffe在GPU编译过程

Windows下Caffe在GPU编译过程 GeForce8800 GTS512: cc=1.1 CUDA6.5 问题一: src/caffe/layers/conv_layer.cu(20): error : too few arguments in function call Error in in conv_layer.cu :forward_gpu_gemm needs the argument skip_im2col #1962 解决: https://github.com/BVLC/