交叉编译静态编译

A. 可执行程序无法在linux上运行，显示line 1: syntax error: word unexpected (expecting ")

同求，我也遇到了 这个问题。我用的是arm-linux-gcc 4.4.3 和3.4.1 都是这个错误。
程序本身没问题，在VC上试验过了。交叉编译之后用ftp传完就出现这个错误。
您解决了吗？

B. 现在go可以静态编译一个程序么

第一步：all.bash

% cd $GOROOT/src
% ./all.bash

第一步有些突兀，因为 all.bash 仅仅调用了其它两个 shell 脚本；make.bash 和 run.bash。如果你在使用 Windows 或 Plan 9，过程是一样的，只是脚本扩展名变成了.bat 或.rc。对于本文中的其它脚本，请根据你的系统适当改动。
第二步：make.bash

. ./make.bash --no-banner

main.bash 来源于 all.bash，因此调用退出将正确终止便宜进程。main.bash 有三个主要工作，第一个是验证编译 Go 的环境是否完整。完整性检查在过去几年中建立，它通常尝试避免使用已知的破损工具或必然失败的环境进行编译。
第三步. cmd/dist

gcc -O2 -Wall -Werror -ggdb -o cmd/dist/dist -Icmd/dist cmd/dist/*.c

一旦可用性检查完毕，make.bash 将编译产生 cmd/dist,cmd/dist取代了之前存在于Go 1 之前的Makefile 编译系统。cmd/dist用来管理少量的pkg/runtime的代码生成。cmd/dist 是C语言编写的程序，能够充分利用系统C编译器和头文件来处理大部分主机系统平台的检测。cmd/dist通常用来检测主机的操作系统和体系结构,即环境变量$GOHOSTOS和$GOHOSTARCH .如果是交叉编译的话，变量 $GOOS和$GOARCH可能会由于你的设置而不同。事实上,Go 通常用作跨平台编译器，只不过多数情况下，主机和目标系统一致而已。接下来，make.bash 调用cmd/dist 的引导参数的支持库、 lib9、 libbio 和 libmach，使用编译器套件，然后用自己的编译器进行编译。这些工具也是用 C 语言写的中，但是由系统 C 编译器编译产生。

echo "# Building compilers and Go bootstrap tool for host, $GOHOSTOS/$GOHOSTARCH."
buildall="-a"
if [ "$1" = "--no-clean" ]; then
buildall=""
fi
./cmd/dist/dist bootstrap $buildall -v # builds go_bootstrap

使用的编译器套件 cmd/dist 编译产生一个版本的gotool，go_bootstrap。但go_bootstrap并不是完整得gotool，比方说 pkg/net 就是孤立的，避免了依赖于 cgo。要编译的文件的列表以及它们的依赖项，是由cmd/dist编译的 ，所以十分谨慎地避免引入新的生成依赖项 到 cmd/go。

第四步：go_bootstrap

现在， go_bootstrap 编译完成了，make.bash 的最后一部就是使用 go_bootstrap 完成 Go 标准库的编译，包括整套 gotool 的替换版。

echo "# Building packages and commands for $GOOS/$GOARCH."
"$GOTOOLDIR"/go_bootstrap install -gcflags "$GO_GCFLAGS" \
-ldflags "$GO_LDFLAGS" -v std

第五步：run.bash

现在，make.bash 完成了，运行回到了 all.bash，它将引用 run.bash。run.bash 的工作是编译和测试标准库，运行时以及语言测试套件。

bash run.bash --no-rebuild

使用 --no-rebuild 标识是因为 make.bash 和 run.bash 可能都调用了 go install -a std，这样可以避免重复，--no-rebuild 跳过了第二个 go install。

# allow all.bash to avoid double-build of everything
rebuild=true
if [ "$1" = "--no-rebuild" ]; then
shift
else
echo '# Building packages and commands.'
time go install -a -v std
echo
fi

第六步：go test -a std

echo '# Testing packages.'
time go test std -short -timeout=$(expr 120 \* $timeout_scale)s
echo

下一步 run.bash z则是对标准库中的所有包进行单元测试，这是使用 testing 包编写的。由于 $GOPATH 和 $GOROOT 中的代码存在于同一个命名空间中，我们不能使用 go test，这可能会测试 $GOPATH 中的所有包，所以将创建别名std来标识标准库中的包。由于有些测试需要很长时间，或耗用大量内存，测试将会通过 -short 标识将其过滤。
第七步 runtime 和 cgo 测试

run.bash的下一节将运行大量对cgo支持的平台测试，运行一些季春测试，编译 Go 附带的一些杂项程序。随着时间的推移，这份杂项程序列表已经变长了，当它们发现自己并不包含在编译过程中时，沉默将不可避免的被打破。

第八步： go run test

(xcd ../test
unset GOMAXPROCS
time go run run.go
) || exit $?

run.bash的倒数第二步调用了$GOROOT目录下test文件夹中的编译器和运行时测试。这其中有描述编译器和运行时本身的低层级测试。而子目录 test/bugs 及 test/fixedbugs 中的测试对已知问题和已解决问题进行特别的测试。所有测试的测试驱动器是 $GOROOT/test/run.go，该程序很小，它调用test文件夹中的每个.go 文件。有些 .go 文件在首行上描述了预期的运行结果，例如，程序失败或是放出特定的输出队列。

第九步go tool api

echo '# Checking API compatibility.'
go tool api -c $GOROOT/api/go1.txt,$GOROOT/api/go1.1.txt \
-next $GOROOT/api/next.txt -except $GOROOT/api/except.txt

run.bash的最后一部将调用API工具，API工具的作用是执行 Go 1 约定；导出的符号，常数，函数，变量，类型和方法组成2012年确认的 Go 1 API。Go 1 写在 api/go1.txt 文件，而 Go 1.1 则写在 api/go1.1.txt文件中。另一个额外的文件，api/next.txt 描述了G 1.1自后添加到标准库和运行时中的符号。当 Go 1.2 发布时，这个文件将会成为 Go 1.2 的约定，另一个新的 next.txt 文件也将被创建。这里还有一个小文件，except.txt，它包括 Go 1 约定中被批准的扩展。对文件的增添总是小心翼翼的。

C. Ubuntu下使用mingw-w64交叉编译ffmpeg

网上大部分编译windows版ffmpeg的教程都是基于msys+mingw的，完全运行在windows上。由于msys2的性能实在是太糟糕了，编译速度太感人，因此决定研究Linux下使用mingw-w64交叉编译

先是安装ubuntu版的mingw-w64
sudo apt install mingw-w64

然后在configure ffmpeg的时候，在正常的配置项之后加上。
--arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32-

上面是32位库编译的配置，64位的如下
--arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-

而且最好使用动态库，静态库还需要链接一大堆mingw的库实现，而且还可能链接失败。但这样编译出来的动态库，还需要依赖 libgcc_s_sjlj-1.dll。如果要移除这个依赖，configure的时候还要加上 --extra-ldflags='-static-libgcc'

D. Golang项目部署3，容器部署

容器部署即使用 docker 化部署 golang 应用程序，这是在云服务时代最流行的部署方式，也是最推荐的部署方式。

跨平台交叉编译是 golang 的特点之一，可以非常方便地编译出我们需要的目标服务器平台的版本，而且是静态编译，非常容易地解决了运行依赖问题。

使用以下指令可以静态编译 Linux 平台 amd64 架构的可执行文件：

生成的 main 便是我们静态编译的，可部署于 Linux amd64 上的可执行文件。

我们需要将该可执行文件 main 编译生成 docker 镜像，以便于分发及部署。 Golang 的运行环境推荐使用 alpine 基础系统镜像，编译出的容器镜像约为 20MB 左右。

一个参考的 Dockerfile 文件如下：

其中，我们的基础镜像使用了 loads/alpine:3.8 ，中国国内的消正用户推荐使用该基础镜像，基础镜像的 Dockerfile 地址： https://github.com/johngcn/dockerfiles ，仓库地址： https://hub.docker.com/u/loads

随后使用 " docker build -t main . " 指令编译生成名为 main 的 docker 镜像。

需要注意的是，在某些项目的架构设计中， 静态文轿轮件 和 配置文件 可能不会随着镜像进行编译发布，而是分开进行管理和发布。

例如，使用 MVVM 模式的项目中(例如使用 vue 框架)，往往是前后端非常独立的，因此在镜像中往往并不会包含 public 目录。而使用了 配置管理中心 (例如使用 consul / etcd / zookeeper )的项目中，也往往并不需要 config 目拿帆悔录。

因此对于以上示例的 Dockerfile 的使用，仅作参考，根据实际情况请进行必要的调整。

使用以下指令可直接运行刚才编译成的镜像：

容器的分发可以使用 docker 官方的平台： https://hub.docker.com/ ，国内也可以考虑使用阿里云： https://www.aliyun.com/proct/acr 。

在企业级生产环境中， docker 容器往往需要结合 kubernetes 或者 docker swarm 容器编排工具一起使用。
容器编排涉及到的内容比较多，感兴趣的同学可以参考以下资料：

E. linux嵌入式中的静态交叉编译是什么意思

应该说是分为静态和动态的

静态就是把需要的库文件也直接编译进去

动态则是在需要的时候才去调用，本身不编译进去

F. 如何在windows上用ndk交叉编译其他平台程序

目标 ：编译arm64的.so库

编译方法：理论上应该有两种交叉编译方法，法一，在Linux服务器上安装交叉工具链，直接用交叉工具链进行编译链接；法二，使用ndk完成交叉编译，因为

ndk已经安装好交叉编译工具链，以及相关的系统库和系统头文件了。这两种方法的区别在于，linux服务器上的编译使用的makefile和ndk使用的.mk
文件显然不同。原因是ndk作为一个集成编译环境，制定了一套特定的规则用于生成最终的编译脚本。

这里简单总结下，如何在windows用ndk进行交叉编译arm64目标平台的.so库：

step1:找到ndk开发工具包，官网之类的都可以下载，Android-ndk64-r10-windows-x86_64.rar文件

step2:解压上述ndk工具包，将包含程序源文件和头文件的文件夹testProject都放入android-ndk-r10下的samples目录下。

放在其他地方当然也可以，但是后续相对路径之类的不太好加，既然其他例子都放这，把代码放这编译是最保险的了。

step3:在testProject中增加一个jni的文件夹，必须要添加！！！！！！

step4:在jni文件夹中，添加一个Android.mk的文件，必须要添加！！！！！

step5:在jni文件夹中，添加一个Application.mk的文件与Android.mk并列，必须要添加！！！！！

step6:Android.mk和Application.mk合起来就类似于linux环境下的makefile编译文件。

如何写Android.mk，可以参考例子helllo-jni中jni文件夹下的Android.mk。

LOCAL_PATH:=$(call my-dir) #必须要写的

include $(CLEAR_VARS) #必须要写的

LOCAL_MODULE:=hello-jni #编译出来的模块名称

LOCAL_SRC_FILES:=hello-jni.c #制定编译的源文件名称

include $(BUILD_SHARED_LIBRARY)#放在最后

除了上述变量之外，还有其他的指定的变量，

LOCAL_CFLAGS，用于指定编译选项，这个和makefile中是完全一样的，可以指定编译选项-g，也可以指定编译宏及宏值

LOCAL_LDLIBS，用于指定链接的依赖库，这个可以makefile也是完全一样的，可以指定链接库用-l库名，以及指定库搜索路径用_L路径名

LOCAL_STATIC_LIBRARIES，指定链接的静态库名，makefile中没有

LOCAL_C_INCLUDES，用于指定编译头文件的路径，和makefile中不同，路径前不需要加-I，直接写路径即可，可以是相对路径或绝对路径，

多个路径之间用空格隔开。

编写上述Android.mk碰到的问题有，

(1)使用默认的系统自动加载stl库头文件总是出错，只好手动在LOCAL_STATIC_LIBRARIES指定sources/cxx-stl/stlport/stlport来完成对#include<string>这种c++形式的头文件加载

(2)使用$(SYSROOT)/usr/include来完成对系统库头文件的加载，结果找不到sem_t符号，只好指定platforms/android-L/arch-arm64/usr/include

step7:Application.mk编写

APP_STL指定使用的stl移植库，动态或者静态都行

APP_CPPFLAGS，指定app编译的编译选项

APP_ABI指定abi规范类型，例如arm64-v8a，也可以写成ALL就是把所有的类型全部编一编

APP_PLATFORM指定编译的platform名称，这里可以写成android-L或者不指定全编。

step8:编译完成后，运行。

启动cmd，使用cd /D进行到testProject的jni目录下

step9:将android-ndk-r10下的ndk-build.cmd直接拖拽到cmd中，此时直接敲回车，就可以编译了。当然也可以加一个 clean，清除编译中间文件。

step10:检查下编译结果，编译成功后在testProject中多了两个文件夹与jni并列的，libs和obj。
编译链接后的结果就在libs中！

G. QT交叉编译时怎么添加静态库，急！！！

INCPATH = -I../EmbedSky/qt-4.5/__install/arm/mkspecs/default -I. -I../EmbedSky/qt-4.5/__install/arm/include/QtCore -I../EmbedSky/qt-4.5/__install/arm/include/QtNetwork -I../EmbedSky/qt-4.5/__install/arm/include/QtGui -I../EmbedSky/qt-4.5/__install/arm/include -I. -I. -I.
在这里增加你编译的静态库。。。可以试试，我也是新手

H. 建立交叉编译环境需要配置哪些服务

基于Linux操作系统的应用开发环境一般是由目标系统硬件（开发板）和宿主PC机所构成。目标硬件开发板用于运行操作系统和系统应用软件。

这种情况下，在 ARM 平台上进行本机编译就不太可能了，这是因为一般的编译工具链（compilation tool chain）需要很大的存储空间，并需要很强的 CPU 运算能力。为了解决这个问题，交叉编译工具就应运而生了。

比如，我们在 Windows 平台上，可使用 Visual C++开发环境，编写程序并编译成可执行程序。这种方式下，我们使用 PC 平台上的 Windows 工具开发针对 Windows 本身的可执行程序，这种编译过程称为 native compilation，中文可理解为本机编译。

然而，在进行嵌入式系统的开发时，则不能直接编译。运行程序的目标平台通常具有有限的存储空间和运算能力，比如常见的 ARM 平台，其一般的静态存储空间大概是 16 到 32 MB，而 CPU 的主频大概在 100MHz 到 500MHz 之间。