① 如何编译SQLite-How To Compile SQLite
SQLite是ANSI-C的源代码。在使用之前必须要编译成机器码。这篇文章是用于各种编译SQLite方法的指南。
这篇文章不包含编译SQLite的每个步骤的反馈，那样可能会困难因为每种开发场景都不同。所以这篇文章描述和阐述了编译Sqlite的原则。典型的编译命令已经作为例子提供了，以期望应用开发者能够使用这些例子作为完成他们自己定制的编译过程的的一个指南。换句话说，这篇文章提供了想法和见解，而不是交钥匙的解决方法。
融合VS单独源文件
Sqlite是由超过一百个c源码文件以及众多的目录下的脚本构建的。Sqlite的实现是纯粹的ANSI-C，但是许多C语言源代码文件是由辅助的C程序生成或者转换来的，并且AWK，SED和TCL脚本会融合到完成的sqlite库中。对Sqlite构建需要的C程序和转换和创建C语言源码是一个复杂的过程。
为了简化这些，sqlite也通过一个预打包的合并后的源码文件：sqlite3.c。这个合并文件是一个ANSI-C源码实现整个SQLite库的唯一文件。合并后的文件更容易处理。所有的东西都包含在这一个文件里，所以很容易进入一个更大的C或者C++程序的源码树。所有的代码生成和转换步骤都已经实现了，因此没有辅助的C程序需要去配置和变异，也没有脚本需要去运行。并且，因此所有哭都包含在一个翻译单元，编译器可以做更多高级的优化从而提升5%到10%的性能。因为这些原因，融合后的源码文件sqlite3.c对所有程序来讲都是值得推荐的。
推荐所有的应用程序使用融合文件。
直接从单独的源码文件中构建sqlite当然可以，但是并不推荐。对一些特殊的应用程序，可能需要修改构建程序去处理使用那些从网站上下载的预构建的源码文件不能完成的情况。对于这些情况，推荐构建和使用一个定制过的合并文件。换句话说，即使一个工程需要以单独的源码文件构建sqlite，仍然推荐使用一个融合后的源码文件作为一个中间步骤。
编译命令行接口（CLI）
构建命令行接口需要三个源码文件：
sqlite3.c:Sqlite融合的源码文件
sqlite3.h:匹配sqlite3.c以及定义sqlite的c语言接口的头文件
shell.c:命令行接口程序本身。这个c源码文件包含一个main()的例程和每轮循环的用户输入的提示符并将输入传给sqlite数据库引擎用于处理。
所有的上述源码的三个文件都被包含在下载页面的amalgamation tarball中。
为了构建CLI，简单的将这三个文件放置在相同的目录下然后一起编译他们。用MSVC：
cl shell.c sqlite3.c -Fesqlite3.exe
在unix系统上（或者在windows上用cygwin或者mingw+msys）典型的命令会有些像这样：
gcc shell.c sqlite3.c -lpthread -ldl
为了SQLite线程安全，需要pthreads库。但是因为CLI是一个单线程的，我们可以指示SQLite构建一个非线程安全的库并因此护绿pthreads库：
gcc -DSQLITE_THREADSAFE=0 shell.c sqlite3.c -ldl
-ldl库是在支持动态装载时需要，例如sqlite3_load_extension() 接口和load_extension()
SQL function。如果这些特性都不要求，那么我们也可以使用SQLITE_OMIT_LOAD_EXTENSION编译时间选项忽略他们。
gcc -DSQLITE_THREADSAFE=0 -DSQLITE_OMIT_LOAD_EXTENSION shell.c sqlite3.c
有人可能想要提供其他的编译时间选项(compile-time options)，例如SQLITE_ENABLE_FTS3去全文本搜索或者SQLITE_ENABLE_RTREE用于R*树搜索引擎扩展。而有人将正常指定一些编译优化开关。（预编译的CLI可以从选择sqlite网站上使用“-Os”下载下来）有无数种可能的变数在这里。
关键点在这里：构建CLI需要编译一起两个C语言文件。shell.c文件包含入口的定义和用户输入的loop，而sqlite融合文件sqlite3.c包含完整的sqlite库的实现。
编译TCL接口
sqlite的tcl接口是一个小的模块被添加到一般的融合文件中。结果是一个新的融合后的源码文件，称之为“tclsqlite3.c”。这个源码文件是生成一个可以使用TCL
load命令去加载到一个标准的tclsh或者wish中，或者随着sqlite构建成功生成一个单独唯一的tclsh的共享库所需要的。一个tcl的融合的副本被包含在下载页的TEA
tarball中作为一个文件。
为了生成一个linux上的sqlite的TCL-loadable库,下面的命令需要满足：
gcc -o libtclsqlite3.so -shared tclsqlite3.c -lpthread -ldl -ltcl
不幸的是构建Mac OS X 和 Windows的共享库并不是如此简单。对于这些平台最好使用包含在TEA tarball中的configure脚本和makefile.
为了生成一个单独的tclsh，可以用于sqlite静态链接，使用如下的编译器调用：
gcc -DTCLSH=1 tclsqlite3.c -ltcl -lpthread -ldl -lz -lm
这里的技巧是-DTCLSH=1选项。sqlite的TCL接口模块包含一个main的过程，用于初始化一个TCL解释器并在以-DTCLSH=1编译后进入到一个命令行loop。上述命令可以工作在Linux和Mac
OS X,虽然有时可能需要依赖于平台调整库选项以及编译的TCL的哪一个版本。
构建融合文件
下载页提供的sqlite融合文件的版本对大多数用户来说是足够的。然而，一些工程可能想要或者需要构建他们自己的融合文件。一个常见的构建一个定制的融合文件的理由是为了使用特定的compile-time options来定制sqlite库。回想sqlite融合文件中包含了许多C代码由辅助程序和脚本生成。许多的编译时间选项影响这一成圣代码而且必须在融合文件组装前提供给代码生成器。这一系列必须传给代码生成器的编译时间相关的选项会使得sqlite的发布版本各不相同，但是在写这边文章的时候，代码生成器需要知道的这组选项包括：
SQLITE_ENABLE_UPDATE_DELETE_LIMIT
SQLITE_OMIT_ALTERTABLE
SQLITE_OMIT_ANALYZE
SQLITE_OMIT_ATTACH
SQLITE_OMIT_AUTOINCREMENT
SQLITE_OMIT_CAST
SQLITE_OMIT_COMPOUND_SELECT
SQLITE_OMIT_EXPLAIN
SQLITE_OMIT_FOREIGN_KEY
SQLITE_OMIT_PRAGMA
SQLITE_OMIT_REINDEX
SQLITE_OMIT_SUBQUERY
SQLITE_OMIT_TEMPDB
SQLITE_OMIT_TRIGGER
SQLITE_OMIT_VACUUM
SQLITE_OMIT_VIEW
SQLITE_OMIT_VIRTUALTABLE
为了构建一个定制的融合文件，先下载原始的独立源码文件到一个unix或者类unix开发平台。确定获取的原始源码文件不是“预编译过的源文件”。任何人都可以通过到下载页或者直接从configuration management system.获取完整的一套原始源码文件。
假设sqlite源码树被存在一个名为“sqlite”的目录下。计划构建一个平行目录下的名为“bld”的融合文件。首先通过运行sqlite源码树种的configure脚本运行或者通过制作一份源码树顶层的的makfile模板的一份，来构建一个合适的makefile.然后手动编辑这个Makfile去包含需要的编译时间相关的选项。最终运行：
make sqlite3.c
在windows上使用MSVC:
nmake /f Makefile.msc sqlite3.c
sqlite3.c的make
target会自动构造一般的“sqlite3.c”合并的源码文件，以及它的头文件“sqlite3.h”，和包含TCL接口的融合源码文件“tclsqlite3.c”。之后，需要的文件可以被拷贝到文件目录下然后根据上述勾勒的过程编译。
构建一个windows的动态链接库DLL
为了在windows构建一个sqlite的dll使用，首先获取对应的融合过的源码文件，sqlit3.c和sqlite.h。这些可以从SQLite website上下载或者和上述告知的一样去定制生成。
使用工作目录下的源码文件，一个dll可以在msvc中使用如下命令生成：
cl sqlite3.c -link -dll -out:sqlite3.dll
上述命令需要运行在msvc的MSVC Native Tools Command
Prompt.如何你已经在机器上安装了msvc，你可能有多个版本的这种命令提示符，针对于x86和x64的自带构建的，或者交叉编译到ARM的。依赖要求的DLL去使用对应合适的命令提示符工具。
如果使用MinGW编译器，命令是这样的：
gcc -shared sqlite3.c -o sqlite3.dll
注意MinGW只生成32位的dll。另有一个分开的MinGW64工程可以用来生成64位的dll。可以推断其命令行语法是类似的。需要注意的是最近的MSVC的版本生成的DLLs可能不能工作到WinXP或者更早版本的windows上。因此为了最大限度的兼容你的生成的dll，推荐MinGW。一个好的经验法则是使用MinGW去生成32位的dlls，使用msvc去生成64位的dlls。
② Qt 软件中怎么自动加入build版本号
当进入解压好的源码包后，使用./configure –help命令，可以获得相应帮助，那我们只要选取参数部分看看 -release 这个参数显而易见，就是编译Qt以发布版的模式进行，一般来说，最后系统完成后，库就应该是发布版。 -release 与上面对应，自然是调试版了，如果开发的话，可以选择它吧。 -debug-and-release 囧，上面那两个的儿子。 -developer-build 囧，我错了，开发者也可以用这个的，选了这个后，可以进行自动测试，不过还没去用过，以后可以研究研究。 -opensource -commercial 这两个参数是指是编译是商业版本的，还是开源版本呢，视个人情况而定。 -shared -static 这两个参数是指Qt的lib以动态还是静态编译生成，这自然也是视个人需要的。 -no-fast -fast 这两个就很有关系，如果对自己的电脑性能很有信心，那就选第一个，那所有的工程文件都会生成到makefiles中，那编译的时间，估计可以看完变形金刚了。如果选第二个，那就加入子目录和库到makefiles，这样就能加快编译的速度。 -no-largefile -largefile 顾名思义，支不支持大文件，一般来说，嵌入式里是不会有从超过4G的大文件的，那就选第一个吧。 -no-exceptions -exceptions 计算机英语够好的人都该懂，这个自然就是异常情况，选则编译器支持抛出异常，否则不支持。 -no-accessibility -accessibility 可访问性的支持，说实话，这个我真不知道有什么有用了。等哪天发现了，再来好好解释。 -no-stl -stl 是都加入stl的支持，stl，这应该算是C＋＋程序员应该都了解了，再不济，那也总听说过大名吧。 no-sql-<driver> -qt-sql-<driver> -plugin-sql-<driver> 这 个可要好好说明下，一般来说，对于一个优秀的项目开发，数据库是必不可少的，qt也自带了大多数数据库驱动，可以完美地支持数据库的使用。对于数 据库的使用，我们可以直接qt驱动编译进去，或者以插件的形式编译进去。一般来说，最简单地就是直接编译进去，但使用插件形式的可以更加灵活，针对不同的 需求将驱动插件添加。其中，<>代表的是驱动名，如果我想直接添加sqlite的支持话，形式如下：-qt-sql-sqlite。其他名称 可以自己查看参数里，有详细地介绍。 -system-sqlite sqlite真受欢迎啊，当然那么优秀的嵌入式数据库，本人也是基本使用它来进行开发。这个参数意思是使用操作系统上的sqlite数据库，如果是不太会移植的，可以考虑直接使用qt自带的驱动。 -no-qt3support -qt3support 这个也是简洁易懂，加不加对qt3的支持。 no-xmlpatterns -xmlpatterns 选择对xml的支持，如果对网络无需求的话，就不用加了。 -no-phonon -phonon phonon是qt中处理多媒体的模块，比如放放视频什么来着，不过本人从没用过，也是根据需要选择的。 -no-phonon-backend -phonon-backend 与上面类似，只不过这两是以插件的形式加入支持。 -no-svg －svg 是否加入svg的支持，svg即可缩放矢量图形。 -no-webkit -webkit 是否加入webkit的支持，这可是个好东西，不过如果跟网络不搭界的话，还是不支持吧。 -no-scripttools -scripttools 是否加入脚本工具的支持，这对php等脚本工程师来说是个很棒的参数，但对于我这样菜鸟，就别提了。 -platform target 目标平台，这可是关键了，如果不注意的话，编译出来是x86上的话，哪怕是再牛的嵌入式工程师来也没法帮你移植到开发板上。通常，本人是linux-arm-g++。 -no-mmx -no-3dnow -no-sse -no-sse2 这四个参数是针对CPU的指令集，老实说，我也不甚了解，不过，对于开发并不是影响很大。 -qtnamespace 把qt的库封装到命名空间，没啥重要用处，依个人爱好加吧。 -qtlibinfix 将所有的qt的.so库重命名，也没啥大用处。 -no-sql-<driver> -qt-sql-<driver> -plugin-sql-<driver> -system-sqlite 这是相当明显的，如果这都看不出来，，囧，那您一定比我近视（本人800度近视。。） 就 是说如果是-no-XX-，就说明编译时不选择这个参数，如过是-qt-XX-，说明我们可以编译直接选用qt自带的驱动，如果是 -plugin-XX-，就是将驱动以插件形式编译，而-system-XXX,当然是使用操作系统提供的驱动，不过那就需要您自己移植了，而且有时还要 用第三方的API，就方便来说非常麻烦，但是不排除您是牛人要好好玩玩的情况。 接下来，我们接着研究配置参数。 -qt-zlib -system-zlib 想 必经过上面的讲解，参数的意思已经很快得知，就是选择qt带的zlib库还是系统的zlib。zlib库是用于文件和资料压缩的库，对于新入嵌入式的人来 说，可能并无太大的用处，但是在以后的实际开发中，特别是对于多媒体图像图形的工程师来说，就肯定用到，因为图形图像的压缩都要使用或涉及到这个库。 -no-gif -qt-gif 这是选择gif的支持，如果选择qt支持的话，那在用qt开发的项目中，就能显示gif图，gif也是比较普遍的图片格式了，英文全称是Graphics Interchange Format。 -no-libtiff -qt-libtiff -system-libtiff tiff是一种非常复杂的光栅图像格式，并且有直接现成的C语言实现库，因此选择参数时就有了qt和system，一般来说，科学相关的开发里可能会用到。 -no-libpng -qt-libpng -system-libpng png的相关参数，一种非失真性压缩位图图形文件格式，其实就是为了替代gif搞出来的，也是随实际需要来选择，当然，也有C语言实现的库。 -no-libmng -qt-libmng -system-libmng 大汗，大汗，这可是超级罕见的东西，QT竟然也能支持，说实话，这个参数我看来就是无视的。MNG是多帧PNG动画格式，结构极其复杂，基本没人用。 -no-libjpeg -qt-libjpeg -system-libjpeg jpeg,这么有名的图片格式也不用说了，随需要选择吧。 -no-openssl -openssl -openssl-linked SSL，Security Socket Layer,是一个安全传输协议，在Internet网上进行数据保护和身份确认，而OpenSSL是一个开放源代码的实现了SSL及相关加密技术的软件 包，在qt中，我们可以选择直接支持，或者OpenSSL链接支持,这个参数也是为有需要者提供的。 以上是第三方库的参数选择，紧接着就是qt附加参数，在附加参数里，我们可以指定编译的部分及加入参数来获取信息。 -make -nomake 一 句话，说明，就说我可以这两个参数选择哪些我要编译，哪些我不需要，在 libs tools examples demos docs translations这些里你可以选择，比如examples，并不重要，可以放在-nomake后，这样编译过程中就不会编译这部分了。通过适当的 选择，我们可以大大加快编译的速度，这对配置较差的机子来说有着积极意义。 -R <string> -l <string> 这两个参数是为编译时增加一个库的运行路径及头文件的路径，比如使用tslib作为开发触摸驱动时，我们就应使用这两个参数来指定tslib的库路径和头文件路径。 -no-rpath -rpath 这个参数比较难于理解，简单地说，就是告诉动态加载器，到-rpath指定的目录中寻找编译时须要的动态链接库，语法就与上面的参数结合，比如 -rpath -R/home/xxxx。 -continue 这个参数的作用就是当出现错误时依然进行配置编译，换我是不会加上的。 -verbose, -v 这个参数就很眼熟，在前面的文章中有过详细介绍，简言之，就是显示配置的每一步的具体信息。 -no-optimized-qmake -optimized-qmake 是否编译生成优化过的qmake，没啥大用，也属于可有可无的参数。 -no-nis -nis 是否编译NIS支持，NIS（网络信息服务）是一个提供目录服务的RPC(远程过程调用)应用服务，当然没网络需要的可以再次华丽地无视。 -no-cups -cups 是 否编译CUPS支持，是不是想问什么用啊?~~~~囧，开打印店用的。好了，不说冷笑话，CUPS给Unix/Linux用户提供了一种可靠有效 的方法来管理打印。它支持IPP，并提供了LPD，SMB（服务消息块，如配置为微软WINDOWS的打印机）、JetDirect等接口。CUPS还可 以浏览网络打印机。它的开发提供者是大名鼎鼎的“水果生产商”----苹果公司。 -no-iconv -iconv 选择是否编译iconv支持，iconv是一个计算机程序以及一套应用程序编程接口的名称。它的作用是在多种国际编码格式之间进行文本内码的转换。这对跨语言Qt开发人员来说是很有用的，当然，考虑到中文的编码，我也选择加入支持。 -no-pch -pch 是 否支持预编译过的头文件。预编译头就是把一个工程中的一部分代码,预先编译好放在一个文件里(通常以.pch为扩展名)，这个文件就称为预编译头 文件。这些预先编译好的代码在工程开发的过程中不会被经常改变。如果这些代码被修改，则需要重新编译生成预编译头文件。妈妈经常说：不懂就要学。我说：不 懂就加上。。。 no-dbus -dbus -dbus-linked 是否编译编译QtDBus模块。dbus是freedesktop下开源的Linux IPC通信机制，本身Linux 的IPC通信机制包括，管道（fifo），共享内存，信号量，消息队列，Socket等。在Qt中DBUS是有单独的模块的，可见其重要性。 -rece-relocations 对于额外的库链接器优化，可以减少编译中的再定位。 no-separate-debug-info -separate-debug-info 是否存储debug信息在.debug，一般为了查错，还是选择存储吧。 -xplatform target 相当浅显的参数，即交叉编译的目标平台，一般来说根据你所要移植的目标板来确定。 -no-feature-<feature> -feature-<feature> 选 取qte的feature编译，对于这个，我理解为特性，特性的描述你可以参考src/corelib/global/qfeatures.txt，在这 里面对于每个特性都有比较充分的讲解。对于特性地选择，也是要根据开发需求进行，如果裁剪适当，能大大为qte库瘦身。 -embedded <arch> 嵌入式平台架构选择，可以选择arm，mips，x86及generic，视你的目标平台决定吧。 -armfpa -no-armfpa 这个参数也只是针对ARM平台的，是否加入对于基于ARM的浮点数格式的支持，通常，这个参数在编译时会自动选择。 -little-endian -big-endian 目标平台的大端和小端选择，这应该是常识了，如果这不知道，就不要来混嵌入式了 -host-little-endian -host-big-endia 主机平台的大端和小端选择，属于鸡肋的参数，不选择也会在配置时自动选择。 -no-freetype -qt-freetype -system-freetype 选择freetype，FreeType库是一个完全免费(开源)的、高质量的且可移植的字体引擎，它提供统一的接口来访问多种字体格式文件，在嵌入式开发中，有套可使用的字体对于中文开发至关重要，本人一般使用文泉驿字体。 -qconfig local 使用本地的qconfig配置文件来替代全部参数配置，有需要的可以去研究下，可以裁剪控件级别的参数。 -depths <list> 显示的像素位深，也是根据需要来进行吧。 -qt-decoration-<style> -plugin-decoration-<style> -no-decoration-<style> 这个是选择qt的样式风格，对于需要美化界面的项目来说，可以好好选择下。 -no-opengl -opengl <api> 是否加入opengl的支持，OpenGL是个专业的3D程序接口，是一个功能强大，调用方便的底层3D图形库。不过对于一般的开发来说，似乎有很少用到的地方。 -qt-gfx-<driver> -plugin-gfx-<driver> -no-gfx-<driver> 这个是相当重要的一个参数，选择QtGui的图形显示驱动，比如我们在pc上使用qvfb模拟时，就应该加入对qfvb的支持。我们可以在 linuxfb，transformed，qvfb，vnc，multiscreen这几个中选择。在平常的开发板上，选择linuxfb即可。 -qt-kbd-<driver> -plugin-kbd-<driver> -no-kbd-<driver> 选择键盘的驱动支持，可以支持usb键盘，串口键盘等等，也是在tty，usb ，sl5000， yopy， vr41xx ，qvfb中选择。 qt-mouse-<driver> -plugin-mouse-<driver> -no-mouse-<driver> 鼠标的驱动支持，一般都会选择tslib，可以完美地支持触摸屏，在pc，bus，linuxtp，yopy，vr41xx，tslib，qvfb中选择吧。 -iwmmxt 加入iWMMXt指令的编译，也只是部分XScale架构才具有。 -no-glib -glib 是否加入glib库的支持，glib库对应即gtk库，就也是说加入后可以使用gtk。
③ 编译的时候提示的是 sqlite3.c:5:21: 致命错误： sqlite3.h：没有那个文件或目录 编译中断。请问该怎么做
用交叉编译器编译时，也会出现找不到sqlite3.h头文件的情况，需要把sqlite3.h这个头文件放到交叉编译工具目录下的 include。
sudo apt-get install libsqlite3-dev
④ 如何从android源码中编译webkit
android本来自带了webkit浏览器，但是要对其进行custom就需要android源代码才行， 但是在没有源码的情况下，那么就需要用到ndk了，比如，我是在xoom上做custom webkit的。
1、虽然ndk提供的库很少，而且没有skia，但是好在有bitmap，这样显示慢了点，没有硬加速，但不是不可能。
2、webkit需要的第三方库，freetype，png，jpeg，sqlite3等虽然android源码中有，但是ndk没有开放，因此所有的第三方库，freetype，png，jpeg，sqlite3，cairo，curl，fontconfig，pixman，iconv等都需要用ndk cross-compile成静态库，然后链接到最终的动态库中。
3、选择iconv是icu太大，而且没有多语言的需求，选择cairo+pixman是skia的移植性不好，而且cairo支持很多种backend。
4、编译第三方库需要用到autoconfig，ndk中有如何生成交叉编译链的文档，然后在configure时使用这个工具链就可以了，但是android用到的是bionic库，因此会有很少的地方需要修改，有些库也不能生成test程序，但是静态库是没问题的。
5、利用ndk生成的交叉工具链，在加上webkit自带的cmake编译系统，生成webkit的动态库是没有问题的，当然是webkit的内核，而且有些平台相关的部分代码需要修改。
6、但是只要是以linux平台为基础，修改还是很容易的，我移植的webkit是先移植到linux平台上，然后移植到android平台上的，所以修改相对少了很多，但是修改大多都在WebCore/platform下，在选择了的平台相关库后，做相应的配置和修改。
7、其次是在WebKit目录，这个主要是支持和使用WebCore，因此在需求不是整个浏览器，而只是正常地显示网页时，还是可以写的比较简单的。
⑤ linuxqt缂栬疟
linux涓嬫墽琛宷t绋嫔簭镐庝箞缂栬疟杩愯岋纻
1銆佸湪Linux涓嬬殑锻戒护琛岀紪杈戠▼搴忥细#mkdirhello//mkdir锻戒护鍒涘缓涓涓猦ello鐩褰#cdhello//cd锻戒护鍒囨崲鍒板垰镓嶅垱寤虹殑hello鐩褰#vimain.cpp//鍦╤ello鐩褰曚腑鐢╲i鍒涘缓涓涓猰ain.cpp鏂囦欢灏嗕笅闱㈢殑浠ｇ爜杈揿叆鍒癿ain.cpp鏂囦欢涓#include
镐庢牱鍦╱buntu涓嫔畨瑁卶t宓屽叆寮忥纻
1cd~/Qtenv 2 3chmo+xqt-sdk-linux-x86-opensource-2010.04.bin 4 5./qt-sdk-linux-x86-opensource-2010.04.bin 涓轰简鏂囦欢绠＄悊鏂逛究锛屽皢sdk涔熷畨瑁呭湪Qtenv鏂囦欢澶逛腑銆 2銆佽В铡嬫簮浠ｇ爜鍖 鍦ㄧ敤鎴风洰褰曚笅寤虹珛涓涓猀tenv鐩褰曪纴鐢ㄤ簬瀛樻斁缂栬疟婧愭枃浠躲 mkdir$HOME/Qtenv 鍦╭tembedded鐩褰曚笅鍒涘缓arm鍜寈86鐩褰曘傚垱寤鸿繖涓や釜鐩褰曚富瑕佹槸涓轰简缂栬疟涓涓鐢ㄦ埛arm寮鍙戠増镄凲TE锛屽彟涓涓鐩褰旷敤浜庡瓨鏀剧敤浜巕vfb镄刹86涓婹TE锛岃繖镙锋紨绀哄拰寮鍙戦兘寰堟柟渚裤 1cd~/Qtenv 2mkdirarmx86 鎺ヤ笅𨱒ュ皢婧愪唬镰佸寘鍒嗗埆澶嶅埗鍒瘾rm鍜寈86涓嫔苟瑙ｅ帇缂┿傝繖镙峰仛铏界劧娴璐逛简涓浜涚‖鐩樼┖闂达纸ps锛氩湪瀹夸富链轰笂镄勭‖鐩桦お涓嶅奸挶浜嗭级锛屼絾鑳戒负灏嗘潵鍐嶉厤缃鍜岀紪璇戣妭鐪佸緢澶氭椂闂淬 1cd~/Qtenv 2mvqt-everywhere-opensource-src-4.6.3.tar.bz2./arm 3cd~/Qtenv/arm 4tarxjvfqt-everywhere-opensource-src-4.6.3.tar.bz2 5 6cd~/Qtenv/x86 7mvqt-everywhere-opensource-src-4.6.3.tar.bz2./x86 8tarxjvf./x86/qt-everywhere-opensource-src-4.6.3.tar.bz2 瑙ｅ帇缂╁悗鍒嗗埆阍埚笕rm骞冲彴鍜寈86骞冲彴杩涜岄厤缃锛岄厤缃鍓嶅彲杈揿叆 ./configure-embedded-help 杩涜岄厤缃甯锷╂煡璇锛屾牴鎹骞冲彴閰岖疆锛屽苟缂栬疟鍜屽畨瑁呮枃浠躲傚叾锻戒护浠ｇ爜濡备笅锛 1cd~/Qtenv/arm 2./configure-prefix$HOME/Qtenv/arm-embeddedarm-nomakedocs-nomakedemo-nomakeexamples 3make 4makeinstall 5 6cd~/Qtenv/x86 7./configure-prefix$HOME/Qtenv/arm-embeddedx86-nomakedocs-nomakedemo-nomakeexamples 8make 9makeinstall 鍦ㄧ粡杩囨极闀跨殑閰岖疆銆佺紪璇戝悗灏卞畬鎴愪简QTE镄勫畨瑁呫傛湰浜哄湪arm鐗堢殑缂栬疟杩囩▼涓鍑虹幇杩囦袱涓阌栾锛屽湪鍙傝冦婂湪arm-linux-gcc3.4.1涓嬬紪璇憅t-embedded-4.6.2銆嫔畬鎴愮紪璇戙 瀹屾垚缂栬疟鍜屽畨瑁呭悗闇瑕佸圭郴缁熺殑鐜澧冨彉閲忚繘琛岃剧疆锛岃剧疆鍙浠ユ槸涓存椂镐ц剧疆鍜屾案涔呮ц剧疆銆备复镞惰岃剧疆鏄鐩存帴鍦ㄥ懡浠ょ獥鍙ｈ緭鍏 1exportQTENV=$HOME/Qtenv 2exportQTXDIR=$QTENV/qtsdk 3exportQTEDIR=$QTENV/x86 4exportPATH=$QTXDIR/qt/bin:$PATH 5exportLD_LIBRARY_PATH=$QTXDIR/lib:$LD_LIBRARY_PATH 6exportQVFBDIR=$QTXDIR/qt/bin 7exportQTEMAKEDIR=$QTEDIR/bin 浠ヤ笂杩欎簺鍙橀噺鍙浠ユ牴鎹镊宸辩殑锽滃ソ杩涜屽炲垹銆傝繖绉嶈剧疆鏂规硶鍦ㄥ叧闂褰揿墠锻戒护缁堢钖庡け鏁堛 绗浜岀嶆柟寮忔槸鍦ㄥ綋鍓岖敤鎴风殑涓荤洰褰曚笅锛岀紪杈.bash_profile鏂囦欢锛屽姞鍏ヤ笂杩板懡浠よ岋纴淇濆瓨閲嶅惎锻戒护缁堢鍗冲彲銆
濡备綍鍦ˋRMLinux鐜澧冧腑鎼寤篞T杩愯岀幆澧冿纻
1銆佸彲浠2銆丵tCreator鍙鏄涓涓闆嗘垚寮鍙戝伐鍏凤纴杩欎釜鐗堟湰闅忔剰锛岀绣涓娄笅灏卞彲浠ワ纴Qte涓嶆槸鐢ㄦ渶鏂帮纴钥屾槸链濂界敤璺熶綘鍦↙inux寮鍙板紑鍙戜竴镙风殑銆傞栧厛瑕佸湪Linux涓嬩氦鍙夌紪璇恸te镄勫簱锛岀劧钖庡啀灏哃ib杩欎簺鏂囦欢绉绘嶅湪𨱒垮瓙涓婏纴链钖庨氲繃浜ゅ弶缂栬疟濂界殑搴揿幓缂栬疟浣犲湪pc
镙戣帗娲句笅镐庢牱杩愯岀Щ妞岖殑QT绋嫔簭锛
浣犲彲浠ュ弬钥侨QLiteStudio杩欎釜Qt鍐欑殑璺ㄥ钩鍙癝QLite绠＄悊宸ュ叿,瀹冭嚜宸辨墦鍖呬简渚濊禆镄凲t搴,鍙浠ュ仛鍒拌В铡嫔嵆鐢,鍏煎逛笉钖孡inux鍙戣岀増.阆撶悊鍏跺疄璺焀indows鐗圦t绋嫔簭镊甯Qt搴揿樊涓嶅.
缂栬疟鍓岖粰杩炴帴鍣ㄤ紶涓涓鍙傛暟:
璇存槑:
-Wl琛ㄧず锻婅瘔缂栬疟鍣ㄥ皢钖庨溃镄勫弬鏁颁紶阃掔粰阈炬帴鍣.
rpath鏄痝cc镄勪竴涓鍙傛暟,褰撶▼搴忚锷犺浇镞,浼氭悳瀵籸path鐩褰,瀵绘垒鍏变韩搴.
rpath娣诲姞镄勭洰褰曚俊鎭淇濆瓨鍦ㄥ彲镓ц屾枃浠朵腑.
$ORIGIN琛ㄧず鍙镓ц屾枃浠舵墍鍦ㄧ殑鐩褰.
涔熷氨鏄杩愯屾椂绋嫔簭浼氩厛铡昏嚜宸辨墍鍦ㄧ殑鐩褰旷殑lib閲屽幓锷犺浇渚濊禆搴,娌℃湁镄勮瘽鍐嶅幓绯荤粺搴挞噷镓.
濡傛灉浣犵殑绋嫔簭鍦ㄧ紪璇戞椂娌℃湁浼犻抮path鍙傛暟,闾ｄ綘涔熷彲浠ョ敤patchelf𨱒ヤ慨鏀逛綘绋嫔簭镄剅path:
娉ㄦ剰:patchelf淇鏀规枃浠跺悗鍐岘trip浼氩艰嚧鏂囦欢鎹熷潖.
镓浠ュ簲璇ュ厛鐢╯trip鍒犻櫎绗﹀彿琛ㄧ缉灏忎簩杩涘埗鏂囦欢,铹跺悗鍐岖敤patchelf璁剧疆rpath.
棰桦栬瘽,Android涓婃棦娌℃湁glibc搴,涔熸病链夊簱阈炬帴鍣╨d-linux.so.3.
濡傛灉浣犺佹妸DebianARM(濡傛爲銮撴淳Raspbian)涓婄殑杞浠舵斁鍒痨ndroid涓婅窇,浣犱竴镙峰彲浠ユ墦鍖呯▼搴忎緷璧栫殑鍏变韩搴,璁╃▼搴忎篃鑳借窇鍦ˋndroid涓,姣斿侾HP:
涔熷氨鏄浣犳妸搴挞摼鎺ュ櫒ld-linux-armhf.so.3鍜孭HP渚濊禆镄勫簱閮芥斁鍒/data/local/tmp/web/lib閲,铹跺悗璁剧疆涓鍒钖,灏辫兘鍦ˋndroid镄刟dbshell閲岃繍琛屾爲銮撴淳镄凯HP浜.
褰撶劧,浣犱篃鍙浠ョ敤patchelf璁剧疆PHP镄刬nterpreter鍜宺path,鏁堟灉宸涓嶅:
镐庢牱浜ゅ弶缂栬疟涓涓猀T搴旂敤绋嫔簭锛
1.璁剧疆鐜澧冨彉閲忥细rPATH锛濇坊锷犱负浜ゅ弶鐜澧冧笅缂栬疟钖庣敓鎴愮殑qmake璺寰勶纴阃氩父鍜屼富链虹殑绯荤粺鏄涓绉嶆灦鏋勶纴钖屾椂闇瑕佺‘淇濅氦鍙塯cc缂栬疟鍣ㄥ湪鍦≒ATH瀹氢箟rQMAKESOEC锛濅氦鍙夌紪璇戠殑瀵硅薄镄勭殑骞冲彴鎻忚堪鏂囦欢锛屼緥濡俶akespec/qws/linux-arm-g++rQTDIR=Qt镄勫畨瑁呮枃浠讹纴瀛樻斁杩椤簱鍜屽ご鏂囦欢rLD_LIBRARY_PATH=瀛樻斁镄勬槸Qt镄勪氦鍙夌紪璇戝悗镄勫簱锛屽嗳澶囦负鐩镙囩紪璇戦摼鎺ョ殑搴搑2銆傛墽琛岀幆澧冨彉閲弐阃氩父鎴戜滑閮戒细灏嗕互涓婄殑璁剧疆鏀剧疆鍦ㄤ竴涓狰ash鑴氭湰涓锛岄渶瑕佺殑镞跺椤氨镓ц屼竴涓嬨傚紑濮嬬紪璇憆1.浣跨敤qmake锛峱roject𨱒ョ敓鎴愰”鐩鏂囦欢****.pror2浣跨敤qmake𨱒ョ敓鎴怣akefile鏂囦欢r3浣跨敤make𨱒ョ紪璇戠Щ妞嶏细浣跨敤readeif宸ュ叿𨱒ュ垎鏋愮洰镙囩郴缁熺殑浠ユ潵搴掳纴铹跺悗鐩稿叧镄勫簱鍒扮洰镙囨枃浠剁郴缁熷唴銆傞氩父鎴戜滑涔熸槸閲囧彇鑴氭湰镄勬柟寮忔潵瀹屾垚銆俽涓鑸钥岃█锛屽嚒鏄链夎勫緥镄勬垨钥呴吨澶嶆х殑宸ヤ綔锛屾垜浠閮藉彲浠ラ噰鍙栬剼链镄勬柟寮忔潵瑙ｅ喅銆
⑥ 嵌入式开发要学哪些课程
嵌入式开发的必学课程：C语言，C++，操作系统，计算机组成原理，linux编程，51单片机，arm，硬件编程语言，模拟电路&数字电路。
嵌入式培训分几个阶段的学习，从基础到实战的练习，一点一点学习和掌握这门技术。学习的课程内容包含：嵌入式高级C语言、嵌入式设备及GUI开发、嵌入式Linux高级程序设计、Linux高级网络程序设计、数据库开发、面向对象高级语言程序设计、物联网、CotexA53 Linux平台驱动开发及真实的企业实战项目。
想要学好嵌入式技术，嵌入式软件开发工程师，从事领域很宽泛，特别是工业控制、消费电子与通信设备三大领域，因为就业面很大，所以人才需求也大。现在智能硬件也比较火，这方面的发展也会大大拓展嵌入式软件开发工程师的就业机会。再者，嵌入式硬件工程师，需求没有嵌入式软件开发工程师大，但因为做硬件门槛会高些，所以这个方向如果做的比较专业，薪资绝对不会低。