clang交叉编译

① 如何使用clang+llvm+binutils+newlib+gdb搭建交叉编译环境

1，Build llvm/clang/lldb/lld 3.5.0等组件

1.0 准备：

至少需要从llvm.org下载llvm, cfe, lldb, compiler-rt,lld等3.5.0版本的代码。

$tar xf llvm-3.5.0.src.tar.gz

$cd llvm-3.5.0.src

$mkdir -p tools/clang
$mkdir -p tools/clang/tools/extra
$mkdir -p tools/lld
$mkdir -p projects/compiler-rt

$tar xf cfe-3.5.0.src.tar.xz -C tools/clang --strip-components=1
$tar xf compiler-rt-3.5.0.src.tar.xz -C projects/compiler-rt --strip-components=1
$tar xf lldb-3.5.0.src.tar.xz -C tools/clang/tools/extra --strip-components=1
$tar xf lld-3.5.0.src.tar.xz -C tools/lld --strip-components=1
1.1 【可选】使用clang --stdlib=libc++时，自动添加-lc++abi。

libc++组件可以使用gcc libstdc++的supc++ ABI，也可以使用c++abi，cxxrt等，实际上自动添加-lc++abi是不必要的，这里这么处理，主要是为了方便起见。实际上完全可以在“clang++ -stdlib=libc++”时再手工添加-lc++abi给链接器。

这里涉及到链接时DSO隐式还是显式的问题，早些时候ld在链接库时会自动引入由库引入的依赖动态库，后来因为这个行为的不可控性，所以ld链接器的行为做了修改，需要显式的写明所有需要链接的动态库，才会有手工添加-lc++abi这种情况出现。

--- llvm-3.0.src/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 18:49:06.663029075 +0800
+++ llvm-3.0.srcn/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 19:36:04.260071355 +0800
@@ -251,6 +251,7 @@
switch (Type) {
case ToolChain::CST_Libcxx:
CmdArgs.push_back("-lc++");
+ CmdArgs.push_back("-lc++abi");
break;

case ToolChain::CST_Libstdcxx:
1.2 【必要】给clang++添加-fnolibgcc开关。

这个开关主要用来控制是否连接到libgcc或者libunwind。

注：libgcc不等于libunwind。libgcc_eh以及supc++的一部分跟libunwind功能相当。

注：libgcc_s和compiler_rt的一部分相当。

这个补丁是必要的， 不会对clang的正常使用造成任何影响 ，只有在使用“-fnolibgcc"参数时才会起作用。

之所以进行了很多unwind的引入，主要是为了避免不必要的符号缺失麻烦，这里的处理相对来说是干净的，通过as-needed规避了不必要的引入。

--- llvm-static-3.5.0.bak/tools/clang/lib/Driver/Tools.cpp 2014-09-10 13:46:02.581543888 +0800
+++ llvm-static-3.5.0/tools/clang/lib/Driver/Tools.cpp 2014-09-10 16:03:37.559019321 +0800
@@ -2060,9 +2060,15 @@
".a");

CmdArgs.push_back(Args.MakeArgString(LibClangRT));
- CmdArgs.push_back("-lgcc_s");
- if (TC.getDriver().CCCIsCXX())
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else {
+ CmdArgs.push_back("-lgcc_s");
+ if (TC.getDriver().CCCIsCXX())
+ CmdArgs.push_back("-lgcc_eh");
+ }
}

static void addProfileRT(
@@ -7150,24 +7156,50 @@
bool isAndroid = Triple.getEnvironment() == llvm::Triple::Android;
bool StaticLibgcc = Args.hasArg(options::OPT_static_libgcc) ||
Args.hasArg(options::OPT_static);
+
+
+
if (!D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");

if (StaticLibgcc || isAndroid) {
if (D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
} else {
if (!D.CCCIsCXX())
CmdArgs.push_back("--as-needed");
- CmdArgs.push_back("-lgcc_s");
+ if (Args.hasArg(options::OPT_fnolibgcc))
+ CmdArgs.push_back("-lunwind");
+ else
+ CmdArgs.push_back("-lgcc_s");
if (!D.CCCIsCXX())
CmdArgs.push_back("--no-as-needed");
}

if (StaticLibgcc && !isAndroid)
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc_eh");
else if (!Args.hasArg(options::OPT_shared) && D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");

// According to Android ABI, we have to link with libdl if we are
// linking with non-static libgcc.
--- llvm-static-3.5.0.bak/tools/clang/include/clang/Driver/Options.td 2014-08-07 12:51:51.000000000 +0800
+++ llvm-static-3.5.0/tools/clang/include/clang/Driver/Options.td 2014-09-10 13:36:34.598511176 +0800
@@ -788,6 +788,7 @@
def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group<f_Group>;
def fopenmp : Flag<["-"], "fopenmp">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fopenmp_EQ : Joined<["-"], "fopenmp=">, Group<f_Group>, Flags<[CC1Option]>;
+def fnolibgcc : Flag<["-"], "fnolibgcc">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, Group<f_Group>;
def foptimize_sibling_calls : Flag<["-"], "foptimize-sibling-calls">, Group<f_Group>;
def force__cpusubtype__ALL : Flag<["-"], "force_cpusubtype_ALL">;
1.3 llvm的其他补丁。

llvm/clang将gcc toolchain的路径hard code在代码中，请查阅tools/clang/lib/Driver/ToolChains.cpp。

找到x86_64-redhat-linux之类的字符串。

如果没有你系统特有的gcc tripple string，请自行添加。

这个tripple string主要是给llvm/clang搜索gcc头文件等使用的，不影响本文要构建的toolchain

1.4 构建clang/llvm/lldb

本文使用ninja。顺便说一下，llvm支持configure和cmake两种构建方式。可能是因为工程太大，这两种构建方式的工程文件都有各种缺陷（主要表现在开关选项上，比如configure有，但是cmake却没有等）。llvm-3.4.1就是因为cmake工程文件的错误而导致了3.4.2版本的发布。

综合而言，cmake+ninja的方式是目前最快的构建方式之一，可以将构建时间缩短一半以上。

mkdir build
cd build

cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_CXX_FLAGS="-std=c++11" \
-DBUILD_SHARED_LIBS=OFF \
-DLLVM_ENABLE_PIC=ON \
-DLLVM_TARGETS_TO_BUILD="all" \
-DCLANG_VENDOR="MyOS" ..

ninja

ninja install
如果系统原来就有clang/clang++的可用版本，可以添加：

-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
这样就会使用系统的clang++来构建llvm/clang

2，测试clang/clang++。

自己找几个简单的c/cpp/objc等编译测试一下即可。完整测试可以在构建时作ninja check-all

3，libunwind/libc++/libc++abi，一套不依赖libgcc, libstdc++的c++运行库。

3.1 从https://github.com/pathscale/libunwind 获取代码。

libunwind有很多个实现，比如gnu的libunwind, path64的libunwind，还有libcxxabi自带的Unwinder.

这里作下说明：

1)，gnu的libunwind会有符号缺失和冲突。

2)，libcxxabi自带的Unwinder是给mac和ios用的，也就是只能在darwin体系构建。目前Linux的实现仍然不全，等linux实现完整了或许就不再需要path64的unwind实现了。

暂时建议使用pathscale的unwind实现。

mkdir -p build
cd build
cmake -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-m64" ..
ninja

mkdir -p /usr/lib
cp src/libunwind.so /usr/lib
cp src/libunwind.a /usr/lib
3.2 第一次构建libcxx.

必须先构建一次libcxx，以便后面构建libcxxabi。这里构建的libcxx实际上是使用gcc的libgcc/stdc++/supc++的。

打上这个补丁来禁止libgcc的引入：

diff -Nur libcxx/cmake/config-ix.cmake libcxxn/cmake/config-ix.cmake
--- libcxx/cmake/config-ix.cmake 2014-06-25 06:57:50.000000000 +0800
+++ libcxxn/cmake/config-ix.cmake 2014-06-25 09:05:24.980350544 +0800
@@ -28,5 +28,4 @@
check_library_exists(c printf "" LIBCXX_HAS_C_LIB)
check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
-check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
编译安装：

mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
..
ninja
ninja install
3.3，测试第一次构建的libcxx。

使用"clang++ -stdlib=libc++ -o test test.cpp -lstdc++"编译简单c++代码，检查是否出错。(如果前面构建clang是已经apply了c++abi的链接补丁，这里会出现找不到c++abi的情况，跳过即可)

使用"ldd test"查看test二进制动态库使用情况。可以发现，test依赖于libgcc_s/libc++/libstdc++。（多少有些不爽了吧？使用了libc++居然还要依赖libstdc++？）

② gdal for android 如何支持 gpkg

编译环境如下：

ubuntu 16.04 LTS

android-ndk-r18b

GNU Make 4.1

代码版本如下：

gdal-2.2.3

curl-7.59.0

按照网上的办法顺利对GDAL进行了交叉编译，坑来了。

利用GDAL的CPLHTTPFetch测试网络抓取功能的时候，没抓取到文件。测试函数如下：

bool SaveUrl2File(const char* pszUrl, const char* pszFileName)
{
if (CPLHTTPEnabled() != TRUE)
return false;

CPLHTTPResult *pRest = CPLHTTPFetch(pszUrl, NULL);
if (pRest == NULL)
return false;

FILE *pFile = fopen(pszFileName, "wb");
if (pFile == NULL)
return false;

fwrite(pRest->pabyData, sizeof(GByte), pRest->nDataLen, pFile);
fclose(pFile);

CPLHTTPDestroyResult(pRest);
CPLHTTPCleanup();
return true;
}
查看错误信息，大概的意思是需要HTTPS支持，查资料得知，需要在编译curl的时候指定--with-ssl 才能支持HTTPS，然后就开始编译openssl库，本来应该是比较容易的一件事，结果整了足足一天，糟糕的是还没把ssl编译出来。我用的NDK版本比较高，编译器是clang，真是没搞出来，原因是和NDK版本有密切关系，貌似GCC比较容易，clang是google推荐编译器。之后就从网上找ssl库，arm64-v8a的ssl不太好找，还好在GITHUB上找到了。

这是成功在curl中集成ssl后的configure输出，注意最后一行Protocols 中要出现HTTPS，另外在编译curl的时候要指定ssl的库目录，和库名字，否则链接的时候可能会找不到库。

export LDFLAGS="-L/xxx/xxx/build64dr/openssl/lib" ，指定ssl库的搜索目录

export LIBS="-lssl -lcrypto -lz"，指定ssl库名字

GDAL编译好后，开始测试 SaveUrl2File 函数，测试失败，提示SSL certificate problem: unable to get local issuer certificate，调用CPLSetConfigOption("GDAL_HTTP_UNSAFESSL", "YES");即可解决，原理就不说了。OK，GDAL在android下可以抓取网络数据了。

③ [openharmony]liteos-a系统编译之GN

在 文章 中已经分析openharmony的小型系统（liteos-a）编译过程，最主要的就是调用gn/ninja/makefs三个命令最终生成可烧录的镜像文件
从前面文件可以看到hb build调用的gn命令参数如下

这里详细分析一下gn工具在编译过程中的使用

这里简单介绍下GN工具的使用方法，gn语法可以参考 http://weharmonyos.com/openharmony/compile/gn/docs/
，已经熟悉的可以跳过

从上面图中可以看到使用的命令类型为 gn gen <output_dir> [options] ，此命令就是为了将所有需要的BUILD.gn文件生成为*.ninja文件供ninja进行编译; 可以通过 gn help gen 命令查看详细的用法说明， 如下

下面重点说一下gn_cmd中的 [options]

liteos-a编译系统的dotfile内容如下:

liteos-a是嵌入式系统，而编译环境是linux系统，这就需要用到交叉编译方式，这个就可以在环境配置中指定 target_os 、 target_cpu 、 board_cpu 等等信息
这些信息就是 buildconfig 参数指定的 BUILDCONFIG.gn 文件中配置的
除了以上信息，还配置了以下几个重要信息

详细信息可以查看 //build/lite/config/BUILDCONFIG.gn 文件内容

toolchain定义源码编译需要的工具，像编译器、汇编器、连接器等等，一般在.gn所在目录下有一个 toolchain 目录，里面的 BUILD.gn 定义详细的编译工具链信息
这里目录结构如下：

从结构信息中可以看到定义了clang和gcc两种工具链，通过变量 board_toolchain_type 来区分（此变量也是buildconfig中定义的），具体信息参见BUILD.gn文件内容，如下

在.gn文件所在目录下的BUILD.gn就是入口，此文件做了以下几个事情

这里重点说一下target为 ohos 的 group 如下：

这里也比较好理解，里面就是读取一个配置文件，几级循环来处理配置文件中配置的内容。流程如下

到此就将此board下各模块的依赖关系添加好了，然后 GN 会将依赖树中所有的BUILD.gn生成对应的.ninja文件，并且在out的根目录下生成下面几个ninja的入口文件以及配置文件

④ 怎么样才能提高python程序的网络吞吐速率

Python是一个很酷的语言，因为你可以在很短的时间内利用很少的代码做很多事情。不仅如此，它还能轻松地支持多任务，比如多进程等。Python批评者有时会说Python执行缓慢。本文将尝试介绍6个技巧，可加速你的Python应用程序。
1.让关键代码依赖于外部包

虽然Python让许多编程任务变得容易，但它可能并不总能为紧急的任务提供最佳性能。你可以为紧急的任务使用C、C++或机器语言编写的外部包，这样可以提高应用程序的性能。这些包都是不能跨平台的，这意味着你需要根据你正在使用的平台，寻找合适的包。简而言之，这个方案放弃了一些应用程序的可移植性，以换取只有在特定主机上直接编程才能获得的程序性能。这里有一些你应该考虑加入到你的“性能兵工厂”的包：

• Cython

• PyInlne

• PyPy

• Pyrex

这些包以不同的方式提高性能。例如，Pyrex能够扩展Python所能做的事情，例如使用C的数据类型来让内存任务更加有效或直接。PyInIne让你在Python应用程序中直接使用C代码。程序中的内联代码单独编译，但它在利用C语言所能提供的效率的同时，也让所有的代码都在同一个地方。
2.排序时使用键（key）

有很多老的Python排序代码，它们在你创建一个自定义的排序时花费你的时间，但在运行时确实能加速执行排序过程。元素排序的最好方法是尽可能使用键（key）和默认的sort()排序方法。例如，考虑下面的代码：


import operatorsomelist = [(1, 5, 8), (6, 2, 4), (9, 7, 5)]somelist.sort(key=operator.itemgetter(0))somelist#Output = [(1, 5, 8), (6, 2, 4), (9, 7, 5)]somelist.sort(key=operator.itemgetter(1))somelist#Output = [(6, 2, 4), (1, 5, 8), (9, 7, 5)]somelist.sort(key=operator.itemgetter(2))somelist#Output = [(6, 2, 4), (9, 7, 5), (1, 5, 8)],

每一个实例中，根据你选择的作为key参数部分的索引，数组进行了排序。类似于利用数字进行排序，这种方法同样适用于利用字符串排序。
3.优化循环

每种编程语言都会强调需要优化循环。当使用Python的时候，你可以依靠大量的技巧使得循环运行得更快。然而，开发者经常漏掉的一个方法是：避免在一个循环中使用点操作。例如，考虑下面的代码：


lowerlist = ['this', 'is', 'lowercase']upper = str.upperupperlist = []append = upperlist.appendfor word in lowerlist:append(upper(word))print(upperlist)#Output = ['THIS', 'IS', 'LOWERCASE']

每一次你调用方法str.upper，Python都会求该方法的值。然而，如果你用一个变量代替求得的值，值就变成了已知的，Python就可以更快地执行任务。优化循环的关键，是要减少Python在循环内部执行的工作量，因为Python原生的解释器在那种情况下，真的会减缓执行的速度。

（注意：优化循环的方法有很多，这只是其中的一个。例如，许多程序员都会说，列表推导是在循环中提高执行速度的最好方式。这里的关键是，优化循环是程序取得更高的执行速度的更好方式之一。）
4.使用较新版本的Python

在网上搜索Python信息，都会发现无数人在问，从Python一个版本迁移到另一个版本的问题的信息。一般来说，Python的每一个版本都包含了能让其比上个版本运行更快的优化。版本迁移的限制因素是，你喜欢的那些库是否已经迁移到Python的较新版本。相比于询问是否应该进行版本迁移，关键问题是确定一个新版本什么时候有足够的支持，以保证迁移的可行性。

你需要验证你的代码仍然运行。你需要在Python的新版本下使用你获得的新库，然后检查你的应用程序是否需要重大改变。只有在你作出必要的更正之后，你才会注意到版本之间的差别。然而，如果你正好确保你的应用程序能在新版本下运行，而不需要任何改变，你可能会错过那些版本升级带来的新特性。一旦你进行了迁移，你应该为你的新版本下的应用程序写一个说明，检查有问题的地方，并且优先考虑利用新版本的特性去更新那些地方。这样用户将会在升级的过程中更早的看到一个更大的性能提升。
5.尝试多种编码方法

如果每次你创建一个应用程序都是用相同的编码方法，几乎肯定会导致一些你的应用程序比它能够达到的运行效率慢的情况。作为分析过程的一部分，你可以尝试一些实验。例如，在一个字典中管理一些元素，你可以采用安全的方法确定元素是否已经存在并更新，或者你可以直接添加元素，然后作为异常处理该元素不存在情况。考虑第一个编码的例子：


n = 16myDict = {}for i in range(0, n):char = 'abcd'[i%4]if char not in myDict:myDict[char] = 0myDict[char] += 1print(myDict)

这段代码通常会在myDict开始为空时运行得更快。然而，当mydict通常被数据填充（或者至少大部分被充填）时，另一种方法效果更好。


n = 16myDict = {}for i in range(0, n):char = 'abcd'[i%4]try:myDict[char] += 1except KeyError:myDict[char] = 1print(myDict)

两种情况下具有相同的输出：{‘d': 4, ‘c': 4, ‘b': 4, ‘a': 4}。唯一的不同是这个输出是如何得到的。跳出固定的思维模式，创造新的编码技巧，能够帮助你利用你的应用程序获得更快的结果。
6.交叉编译应用程序

开发者有时会忘记，电脑实际上是不懂任何用于创建现代应用程序的语言，电脑所能懂得是机器代码。为了能在电脑上运行应用程序，你使用一个应用将人类可读的代码你转换成计算机能理解的。有时候用一种语言，比如Python，写一个应用，并用另一种语言，比如C++，运行它，从性能的角度来看是有意义的。这取决于你想要应用程序去做什么，以及主机系统可以提供的资源。

一个有趣的交叉编译器，Nuitka，可以将你的Python代码转换为C++代码。这么做的结果是，你可以在原生模式下执行应用程序，而不是依靠解释器。根据平台和任务，你可以看到一个显着的性能提升。

（注意：Nuitka目前还处于测试阶段，所以用它来产品程序时需要小心。实际上，目前最好将其用于实验。现在也有一些关于交叉编译是否是得到更好性能的最佳方式的讨论。开发者已经利用交叉编译好几年了，目的是实现特定的目标，比如更好的应用程序的速度。记住，每一个解决方案都会有得有失，你应该在将一个解决方案用于生产环境之前就好好考虑一下得失情况。）

在使用一个交叉编译器时，要确保它支持你使用的Python的版本。Nuitka支持Python2.6、2.7、3.2和3.3。想让这个方案发挥作用，你需要一个Python解释器和一个C++编译器。Nuitka支持多种C++编译器，包括Microsoft Visual Studio、MinGW 和 Clang/LLVM。

交叉编译也可能带来一些严重的负面影响。例如，当利用Nuitka工作时，你会发现即使一个小程序也能消耗很大的硬盘空间，这是因为Nuitka使用大量的动态链接库（DLLs）实现Python的功能。所以当你面对一个资源有限的系统时，这个方案可能不会很好的起作用。
总结

这六个技巧中的任意一个，都可以帮助你创造更快的Python程序。但任何技巧都不是万能的，不能每次都起作用。有些技巧在Python的特定版本下比其他技巧的更有效——甚至系统平台也能影响它们的效果。你需要配置你的应用，确定哪个地方让其运行缓慢，然后尝试似乎能最好的解决这些问题的一些技巧。

⑤ SE是什么编译器

Clang交叉编译器。

_lang具有更现代的设计茄渣，并且通常被认为比GCC更先进。除此之外，Clang还获得了更为宽松的许可，该许可允许制造可商购的衍生物。ARM / Keil从Clang派生了一个编译器，从而停止了其先前专有编译器的开发。考虑到所有这些，我们决定更深入地研究Clang，以使用它创建我们自己的编译器为目标。

_EGGER将所有内容打包到一个易于下载的“软件包”中，完全集成并且可以立即使用。Clang和GCC都有非常先进的前端，可以将源代码转换为中间表示（IR），并且都可以生成出色的代码。到目前为止，SEGGER一直专注于针对基于Cortex-M微控制器的ARM Thumb-2代码的银吵代码生成器的更改。下一步将包括改善与其他编译器的兼容性，而不仅仅是GCC和Clang（针对实用程序和其他专颤搏悄业），以使其易于切换。

⑥ 关于Mac上交叉编译几个小问题，求解答

我是打算编译给模拟器脊喊悔用的库喔。sysroot设置成simulator.platform相应的目录了。但是还渗大是出樱正现clang: warning: using sysroot for 'iPhoneSimulator' but targeting 'MacOSX'。虽然是warning但是不知道有没影响。

⑦ OpenSSL的编译和使用

个人博客地址： https://blog.yookingh.cn
该文章地址： https://blog.yookingh.cn/dev/201215-openssl.html

从NDK r19开滑知始，由于gcc兼容clang的编译方式有问题，该版本乎高已经移除了相关gcc文件，所以用老方法交叉编译Openssl的时候，会提示找不到gcc文件。

参考： https://blog.csdn.net/zoujin6649

build-android-single.sh 脚本文件及注释如下岁让尺

执行脚本

修改脚本为 循环编译 ，编译所有需要的文件

build-android-all.sh 脚本文件内容如下

执行脚本方法同上，如为第一次执行（即没有Makefile文件），仍需要执行 ./config 循环编译无需执行 make clean

参考： https://blog.csdn.net/iamadk

Python 脚本内容

创建编译执行脚本

执行编译脚本同r15，第一次需要执行 ./config 生成Makefile，第二次或以上需要清除make记录即 make clean ，接下来依旧是创建 循环编译 脚本

⑧ 如何提高python的运行效率

窍门一：关键代码使用外部功能包

Python简化了许多编程任务，但是对于一些时间敏感的任务，它的表现经常不尽人意。使用C/C++或机器语言的外部功能包处理时间敏感任务，可以有效提高应用的运行效率。这些功能包往往依附于特定的平台，因此你要根据自己所用的平台选择合适的功能包。简而言之，这个窍门要你牺牲应用的可移植性以换取只有通过对底层主机的直接编程才能获得的运行效率。以下是一些你可以选择用来提升效率的功能包：

Cython
Pylnlne
PyPy
Pyrex

这些功能包的用处各有不同。比如说，使用C语言的数据类型，可以使涉及内存操作的任务更高效或者更直观。Pyrex就能帮助Python延展出这样的功能。Pylnline能使你在Python应用中直接使用C代码。内联代码是独立编译的，但是它把所有编译文件都保存在某处，并能充分利用C语言提供的高效率。

窍门二：在排序时使用键

Python含有许多古老的排序规则，这些规则在你创建定制的排序方法时会占用很多时间，而这些排序方法运行时也会拖延程序实际的运行速度。最佳的排序方法其实是尽可能多地使用键和内置的sort()方法。譬如，拿下面的代码来说：

import operator
somelist = [(1, 5,]
在每段例子里，list都是根据你选择的用作关键参数的索引进行排序的。这个方法不仅对数值类型有效，还同样适用于字符串类型。

窍门三：针对循环的优化

每一种编程语言都强调最优化的循环方案。当使用Python时，你可以借助丰富的技巧让循环程序跑得更快。然而，开发者们经常遗忘的一个技巧是：尽量避免在循环中访问变量的属性。譬如，拿下面的代码来说：

lowerlist = ['this', 'is', 'lowercase']
upper = str.upper
upperlist = []
append = upperlist.append
for word in lowerlist:
append(upper(word))
print(upperlist)
#Output = ['THIS', 'IS', 'LOWERCASE']
每次你调用str.upper, Python都会计算这个式子的值。然而，如果你把这个求值赋值给一个变量，那么求值的结果就能提前知道，Python程序就能运行得更快。因此，关键就是尽可能减小Python在循环中的工作量。因为Python解释执行的特性，在上面的例子中会大大减慢它的速度。

（注意：优化循环的方法还有很多，这只是其中之一。比如，很多程序员会认为，列表推导式是提高循环速度的最佳方法。关键在于，优化循环方案是提高应用程序运行速度的上佳选择。）

窍门四：使用较新的Python版本

如果你在网上搜索Python，你会发现数不尽的信息都是关于如何升级Python版本。通常，每个版本的Python都会包含优化内容，使其运行速度优于之前的版本。但是，限制因素在于，你最喜欢的函数库有没有同步更新支持新的Python版本。与其争论函数库是否应该更新，关键在于新的Python版本是否足够高效来支持这一更新。

你要保证自己的代码在新版本里还能运行。你需要使用新的函数库才能体验新的Python版本，然后你需要在做出关键性的改动时检查自己的应用。只有当你完成必要的修正之后，你才能体会新版本的不同。

然而，如果你只是确保自己的应用在新版本中可以运行，你很可能会错过新版本提供的新特性。一旦你决定更新，请分析你的应用在新版本下的表现，并检查可能出问题的部分，然后优先针对这些部分应用新版本的特性。只有这样，用户才能在更新之初就觉察到应用性能的改观。

窍门五：尝试多种编码方法

每次创建应用时都使用同一种编码方法几乎无一例外会导致应用的运行效率不尽人意。可以在程序分析时尝试一些试验性的办法。譬如说，在处理字典中的数据项时，你既可以使用安全的方法，先确保数据项已经存在再进行更新，也可以直接对数据项进行更新，把不存在的数据项作为特例分开处理。请看下面第一段代码：

n = 16
myDict = {}
for i in range(0, n):
char = 'abcd'[i%4]
if char not in myDict:
myDict[char] = 0
myDict[char] += 1
print(myDict)
当一开始myDict为空时，这段代码会跑得比较快。然而，通常情况下，myDict填满了数据，至少填有大部分数据，这时换另一种方法会更有效率。

n = 16
myDict = {}
for i in range(0, n):
char = 'abcd'[i%4]
try:
myDict[char] += 1
except KeyError:
myDict[char] = 1
print(myDict)
在两种方法中输出结果都是一样的。区别在于输出是如何获得的。跳出常规的思维模式，创建新的编程技巧能使你的应用更有效率。

窍门六：交叉编译你的应用

开发者有时会忘记计算机其实并不理解用来创建现代应用程序的编程语言。计算机理解的是机器语言。为了运行你的应用，你借助一个应用将你所编的人类可读的代码转换成机器可读的代码。有时，你用一种诸如Python这样的语言编写应用，再以C++这样的语言运行你的应用，这在运行的角度来说，是可行的。关键在于，你想你的应用完成什么事情，而你的主机系统能提供什么样的资源。

Nuitka是一款有趣的交叉编译器，能将你的Python代码转化成C++代码。这样，你就可以在native模式下执行自己的应用，而无需依赖于解释器程序。你会发现自己的应用运行效率有了较大的提高，但是这会因平台和任务的差异而有所不同。

（注意：Nuitka现在还处在测试阶段，所以在实际应用中请多加注意。实际上，当下最好还是把它用于实验。此外，关于交叉编译是否为提高运行效率的最佳方法还存在讨论的空间。开发者已经使用交叉编译多年，用来提高应用的速度。记住，每一种解决办法都有利有弊，在把它用于生产环境之前请仔细权衡。）

在使用交叉编译器时，记得确保它支持你所用的Python版本。Nuitka支持Python2.6, 2.7, 3.2和3.3。为了让解决方案生效，你需要一个Python解释器和一个C++编译器。Nuitka支持许多C++编译器，其中包括Microsoft Visual Studio,MinGW 和 Clang/LLVM。

交叉编译可能造成一些严重问题。比如，在使用Nuitka时，你会发现即便是一个小程序也会消耗巨大的驱动空间。因为Nuitka借助一系列的动态链接库（DDLs）来执行Python的功能。因此，如果你用的是一个资源很有限的系统，这种方法或许不太可行。