linux编译

1.本文环境: CentOS7 [root@centos7-lvm ~]# cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" 1 [root@centos7-lvm ~]# cat /etc/os-release 2 NAME="CentOS Linux" 3 VERSION="7 (Core)" 4 ID="centos" 5 ID_LIKE="rhel fedora" 6 VERSION_ID="7" 7 PRETTY

编程语言和python简介 一.编程语言的分类 1.编程语言的发展史 机器语言 ​ 机器语言是站在计算机的角度来开发程序，而计算机只能识别高低电频，因此计算机语言是一系列用0和1这种二进制代码写的指令，优点是站在计算机的角度编写的指令，更容易被计算机理解，执行效率高，可直接控制计算机硬件。缺点是过于复杂，开发效率低 ，依赖具体的计算机硬件，跨平台性差 。 汇编语言 ​ 汇编语言的实质和机器语言是相同的，都是直接对硬件操作，只不过指令采用了英文缩写的标识符，更容易识别和记忆。它同样需要编程者将每一步具体的操作用命令的形式写出来。 优点是相对于机器语言来说使用英文标签编写程序相对简单，执行效率稍低，开发效率稍高。 缺点是仍然是直接操作硬件，比起机器语言来说，复杂度稍低，但依旧居高不下，所以开发效率依旧较低 ，一样依赖具体的硬件，跨平台性差 高级语言 ​ 高级语言是站在人的角度，说人话，即用人类的字符去编写程序，而人类的字符是在向操作系统发送指令，而非直接操作硬件，所以高级语言是与操作系统打交道的，此处的高级指的是高层、开发者无需考虑硬件细节。优点是开发效率可以得到极大的提升，缺点是高级语言离硬件较远，更贴近人类语言，人类可以理解，而计算机则需要通过翻译才能理解，所以执行效率会低于低级语言。 ​ 高级语言可以分为编译型（如C语言）和解释型（python） 编译型 ​

预处理 将所有#defined删除，并且展开 处理所有条件预处理指令 处理#include，将被包含的文件插入到该预编译指令的位置 过滤所有的//、/**/ 保留所有#pragma编译指令 编译 词法分析 语法分析 语义分析 代码分析 目标代码生成 汇编 链接 静态链接 动态链接 来源： https://www.cnblogs.com/zsczsc/p/11776480.html

可以尝试的两个配置文档 http://blog.csdn.net/guo8113/article/details/50412469 https://github.com/cleanflight/cleanflight/blob/master/docs/development/Building%20in%20Eclipse.md BTW Git在这里down就好 https://git-scm.com/download/win 注意CDT也需在eclipse的软件中配置 Cleanflight的默认make文件夹下的tool.mk中GCC版本要求是6.3.1而官网推荐的是5.4.1，并未找到具体的解决办法。直接改变编译文件将版本号修改之后会出现如下的问题。 故不确定是否更改。 在tool的makefile中更改了第19行，原版本是6.3.1 Malefile是什么？ 一个工程中的源文件不计其数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为 makefile就像一个 Shell脚本 一样，其中也可以执行操作系统的 命令 。 下载的时候可能会出错，最近不太稳定，多试几次。 上面的方法并未真正编译成功其中并没有成功生成obj文件。找到一个新的下载地址

cd / usr / lib / x86_64 - linux - gnu sudo ln - s ~/ anaconda / lib / libpng16 . so . 16 libpng16 . so . 16 sudo ldconfig #### 不能成功 export LD_LIBRARY_PATH =~/ anaconda2 / lib : $LD_LIBRARY_PATH ~/.bash_profile

在使用CMake编译库时候有以下问题： /opt/ov798/bin/../libexec/gcc/arm-ov798-linux-uclibcgnueabi/4.8.4/cc1: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory 解决方法：指定编译链下的库路径 export LD_LIBRARY_PATH=/opt/ov798/lib 文章来源: 错误：libmpc.so.3: cannot open shared object file解决方法

编译驱动时报错： make -C /work/system/linux-2.6.22.6 M= pwd modules make[1]: Entering directory /work/system/linux-2.6.22.6' make[2]: *** No rule to make target /work/driver_test/leds/drv/myleds.c’, needed by /work/driver_test/leds/drv/myleds.o'. Stop. make[1]: *** [_module_/work/driver_test/leds/drv] Error 2 make[1]: Leaving directory /work/system/linux-2.6.22.6’ make: * [all] Error 2 解决办法如下： 1、我的驱动文件名为leds_drv.c，所以编译出来的.o文件名为leds_drv.o 。但是从报错里面可以发现在MakeFile文件里面依赖的竟然是myleds.o,出错的原因就在这里。只需要把MakeFile文件里面的myleds.o改成leds_drv.o即可make成功。 文章来源: 执行make编译驱动文件生成ko驱动文件时报错

随着Android Studio的普及，越来越多的Android开发者也要开始了解和学习Gradle这款强大的代码构建工具了。我们在学习和了解一项新事物的时候，最快速的方法往往是与已知的事物进行比较，对于熟悉Makefile编译机制的Linux程序员而言，认识和掌握Gradle最好的方法莫过于比较它们之间的区别了，本文不准备详细介绍Gradle的方方面面，而是希望通过与Makefile的对比帮助Gradle初学者更快速地理解Gradle的基础和原理。 Makefile是一种管理和编译 Linux C/C++ 项目的工具，而Gradle也是一种代码构建工具，只不过是针对Java语言的，它同样可以通过一些配置文件和脚本来完成代码的依赖、第三方库的引入、编译的自动化配置等功能。 首先说说Makefile，它是由一个个"规则"组成，每个"规则"都是由"目标"、"依赖"、"命令"构成， 一个最简单的Makefile如下所示: 1 2 3 4 5 6 7 8 9 .PHONY: clean all: hello hello: hello.c gcc -o hello hello.c clean: rm hello 这里有三个"目标"，分别是: "all"，"hello"，"clean" 当执行"make"命令时，编译器会默认查找目标"all" ，如果没有"all

转载地址： https://blog.csdn.net/zqixiao_09/article/details/50805205 Uboot 所用版本 u-boot-2013.01 u-boot-2013.01 中有上千文件，要想了解对于某款开发板，使用哪些文件、哪些文件首先执行、可执行文件占用内存的情况，最好的方法就是阅读它的Makefile。 根据顶层Readme文件的说明： 可以知道如果使用开发板board/<board_name>，就先执行 “make <board_name>_config” 命令进行配置，然后执行 “make all”, 就可以生成如下3个文件： U-Boot.bin ：二进制可执行文件，它就是可以直接烧入eMMC中的文件。 U-Boot : ELF格式的可执行文件。 U-Boot.sre c : 摩托罗拉格式的可执行文件。 对于Exynos4412开发板，这里用的其实是Fs4412，执行 “make fs4412_config" 、“make all"后生成的 u-boot-fs4412.bin 可以烧入eMMC中执行。 一、U-Boot 配置过程 1、在顶层Makefile中可以看到如下代码： 假定在u-boot-2013.01的根目录下编译，则其中的MKCONFIG 就是根目录下的 mkconfig文件（mkconfig是shell脚本文件） 。 %

综述 u-boot 自 v2014.10 版本开始引入 KBuild 系统，同更改前的编译系统相比，由于 Kbuild 系统的原因，其 Makefile 变得更加复杂。 u-boot的编译跟kernel编译一样，分两步执行： 第一步：配置，执行 make xxx_defconfig 进行各项配置，生成 .config 文件 第二部：编译，执行 make 进行编译，生成可执行的二进制文件u-boot.bin或u-boot.elf Makefile的核心是依赖和命令。对于每个目标，首先会检查依赖，如果依赖存在，则执行命令更新目标；如果依赖不存在，则会以依赖为目标，先生成依赖，待依赖生成后，再执行命令生成目标。 博客《》详尽解释了第一步的操作，在这一步中，u-boot执行配置命令 make xxx_defconfig 时先搜集所有默认的 Kconfig 配置，然后再用命令行指定的 xxx_defconfig 配置进行更新并输出到根目录的 .config 文件中。 配置完成后执行make命令生成二进制文件的过程，由于涉及的依赖和命令很多，也将make编译过程分析分为两部分，目标依赖和命令执行。 博客《》中描述了 make 过程中的依赖关系 本篇主要分析 make 过程中的通过命令生成各个目标的依赖，从而一步一步更新目标，直至更新并生成顶层目标 u-boot.bin 。 第二部分