PandoraBox/LEDE SDK交叉编译OpenWrt ipk安装包的方法

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/lvshaorong/article/details/62215033

以前写过一篇《Ubuntu 使用Openwrt SDK交叉编译ipk包过程全纪录(超多图)》的文章,详细介绍了如何使用OpenWrt SDK编译ipk安装包的方法。在BB 14.04, CC 15.05, CC 15.05.1版本的SDK上编译一些常见的第三方ipk包都非常容易。这个要得益于OpenWrt SDK行之有效的工具链和链接方式。但是同样的Makefile文件搬到Pandora(潘多拉固件)和LEDE的SDK上时,就没有OpenWrt平台上那么简单了。这两个平台的SDK为我们挖了很多大坑,小白第一次编译往往会被搞得一头雾水。

首先我们先下载pandorabox和lede的SDK

PandoraBox,国内网站已经下载不到了,好在其他地方的还能够下载,从下面的地址不光可以下载到SDK,还可以下载到国内个大厂路由器的固件

http://download.pandorabox.com.tw:99/pandorabox/17.09/

注:根据2017年年底的消息,Pandorabox因为商标恶意注册的问题改名为pangubox,同时也更换了官网,所以Pandorabox最后一版为17.09版,然而pangubox并没有让我们失望,其当前最新版18.07版不仅和以前一样提供了常见国内外路由器的固件、软件包和SDK,还提供了ImageBuilder,可以依托于pangubox直接生成自定义固件了。而且新版SDK的toolchain从原来的gcc 4.8.0升级到了4.9,下载地址如下

https://downloads.pangubox.com/pandorabox/

然后是LEDE的包,固件,feeds下载地址,由于LEDE经常更新,所以内容也会经常变化,可以选择自己喜欢的版本,进去下载SDK或者软件包

https://downloads.lede-project.org/releases/

其实多数的编译不成功都是由于依赖库没有正确的引入引起的,还有一个常见原因是你计算机的Linux没有很好的部署编译环境引起的。

所以跳过潘多拉或者LEDE SDK的大坑其实不麻烦,只要正确的导入第三方依赖库并配置好本地开发环境即可,下面我以Ubuntu16.04 LTS 64位为例介绍一下潘多拉/LEDE相比OpenWrt SDK可能会碰到的问题。主要目的是解决在OpenWrt下能成功编译到了潘多拉或者LEDE就无法编译的问题。如果OpenWrt SDK也无法编译则不在本文的讨论范围之内。

(注意:请不要使用32位操作系统,否则make menuconfig打不开,也不推荐使用Ubuntu14.04,16.10等版本,因为这些系统上失败的案例较多且不好解决)

首先以潘多拉SDK为例,潘多拉16-10稳定版的固件和SDK下载地址为:http://downloads.pandorabox.com.cn/pandorabox-16-10-stable/targets/ralink/ ,可以选择mt7620 和 mt7621两个平台的固件和SDK下载,本文以小米路由器mini为例所以使用的是mt7620的SDK, rt305x芯片如华为HG255D只提供了固件没有提供toolchain或SDK,所以不在本文讨论范围之内。

我们向往常一样解压潘多拉的SDK,然后克隆一个项目的Makefile到package目录下,这里以SSR为例

git clone https://github.com/AlexZhuo/openwrt-shadowsocksr.git package/shadowsocksr-libev

然后选择要编译的IPK安装包

make menuconfig

然后执行编译

make package/shadowsocksr-libev/compile V=99

然后SDK就开始克隆项目的源代码到本地,这里的动作主要是把Makefile指明的源代码的tar.gz压缩包下载到SDK/dl目录中(如果网络不好可以直接从别的地方下载tar.gz源码包然后复制到dl目录下)然后把源码解压到SDK/build_dir/target-mipsel_24kc_musl-1.1.16/下面去,如果因为源码有问题导致编译不成功可以直接在这里修改源代码,这一步还算正常

迎面向我们走来的是第一个报错

configure: loading site script /home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/include/site/mipsel
checking for mipsel-openwrt-linux-gcc... mipsel-openwrt-linux-uclibc-gcc
checking whether the C compiler works... no
configure: error: in `/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/build_dir/target-mipsel_24kec+dsp_uClibc-1.0.x/shadowsocksR-libev-openssl/shadowsocksR-libev-2.5.6':
configure: error: C compiler cannot create executables
See `config.log' for more details
Makefile:135: recipe for target '/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/build_dir/target-mipsel_24kec+dsp_uClibc-1.0.x/shadowsocksR-libev-openssl/shadowsocksR-libev-2.5.6/.configured_yyy' failed


意思是C编译器不工作,这个一般是编译环境搭建有问题,但是明明OP的SDK是可以编译的,说明编译环境并没有出问题。但是这个报错并没有指出到底哪里出的错,要修改也无从下手。它还让我们找config.log这个文件看详细日志,可找了半天也没找到这个文件在哪。实在天坑。于是为了判断问题出在哪里,我们克隆redsocks2的源码手动指定编译器和连接器来看详细日志。做法如下:

首先克隆redsocks2的源码,那为啥要选redsocks2的源码呢?原因是redsocks2可以通过make直接编译出可执行文件,可以很方便的检查哪里除了问题,而ssr make要添加参数,依赖库也太多,不方便调试错误

git clone https://github.com/semigodking/redsocks.git package/redsocks

然后切换到源码目录

cd package/redsocks


然后手动指定编译器和连接器,通过声明当前Shell的环境变量实现

export PATH=$PATH:/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/staging_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-1.0.x/bin
export STAGING_DIR=/store/build/openwrt/staging_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-1.0.x 
export CFLAGS="-I/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/staging_dir/target-mipsel_24kec+dsp_uClibc-1.0.x/usr/include/ -L/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/staging_dir/target-mipsel_24kec+dsp_uClibc-1.0.x/usr/lib"

然后通过编译器和连接器手动交叉编译可执行文件

make CC=mipsel-openwrt-linux-uclibc-gcc LD=mipsel-openwrt-linux-uclibc-ld

然后发现真实错误终于暴露出来了

/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/staging_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-1.0.x/bin/../libexec/gcc/mipsel-openwrt-linux-uclibc/4.8.3/cc1: error while loading shared libraries: libisl.so.10: cannot open shared object file: No such file or directory
<builtin>: recipe for target 'parser.o' failed
make: *** [parser.o] Error 1

这个潘多拉的SDK其实就是在我的电脑上找不到libisl.so.10 这个文件,那么这个文件上哪了呢?为啥OP就不会报出这个错误呢?

首先来找一下这个文件

locate libisl.so

输出

/usr/lib/x86_64-linux-gnu/libisl.so
/usr/lib/x86_64-linux-gnu/libisl.so.15
/usr/lib/x86_64-linux-gnu/libisl.so.15.1.1

发现这几个文件都在同一个目录下,仔细一看还能发现,libisl.so.15和libisl.so这两个文件都是libisl.so.15.1.1的软链接。换句话说这三个文件其实是一个文件。那么现在可以试试让libisl.so.10也软链接到libisl.so.15.1.1这个文件试试可以不

sudo ln -s /usr/lib/x86_64-linux-gnu/libisl.so.15.1.1 /usr/lib/x86_64-linux-gnu/libisl.so.10


然后再执行编译的命令,发现这个问题已经不见了,说明有效果。刚才克隆的一大堆代码,又手动指定了编译连接器,最后其实就建立一个软链接就把这个问题解决了。这个大坑的解决成本相当高。此处还应该感谢redsocks2这个项目

送走了这个bug,我们继续编译SSR吧。不过马上又迎来了新的报错

checking for pcre-config... pcre-config
checking for pcre headers in ... not found
checking for library containing pcre_exec... no
configure: error: Cannot find pcre library. Configure --with-pcre=DIR
Makefile:135: recipe for target '/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/build_dir/target-mipsel_24kec+dsp_uClibc-1.0.x/shadowsocksR-libev-openssl/shadowsocksR-libev-2.5.6/.configured_yyy' failed
make[2]: *** [/home/alex/PandoraBox-SDK-ralink-mt7620_gcc-4.8-linaro_uClibc-1.0.x.Linux-x86_64/build_dir/target-mipsel_24kec+dsp_uClibc-1.0.x/shadowsocksR-libev-openssl/shadowsocksR-libev-2.5.6/.configured_yyy] Error 1


这意思是找不到pcre这个依赖库啊。这个好说,只要把相应的feeds安装到SDK里就可以。在OpenWrt/LEDE 的SDK里,只要执行

./scripts/feeds update base packages

就会在SDK根目录下新建一个feeds文件夹,然后里面会有base和package两个文件夹,里面都是OpenWrt提前写好的各个依赖库的Makefile编译文件。然后使用

./scripts/feeds install libpcre

就会在package目录下建立一个feeds文件夹,然后把libpcre的Makefile文件通过软链接链接过去,在碰到编译时需要依赖库的情况时就会自动链接相应的源码进行编译了。

即使官方没有相应的Makefile源码,也可以自己在feeds里建立相应三方库的Makefile。

但是在潘多拉的SDK中执行update命令后根本没有反应,也没有建立feeds文件夹这时怎么回事呢,这里update过程是联网的,克隆地址记录在SDK根目录下的feeds.conf.default文件里面,在LEDE 17.01.5上这个文件中的内容是

下载地址是:https://downloads.lede-project.org/releases/17.01.5/packages/mipsel_24kc/feeds.conf

当然你也可以下载别的版本的feeds,这样就可以直接用SDK编译常见的官方已经收录的软件了

src-git base https://git.lede-project.org/source.git^5886a50
src-git packages https://git.lede-project.org/feed/packages.git^2578f56
src-git luci https://git.lede-project.org/project/luci.git^7bf0367
src-git routing https://git.lede-project.org/feed/routing.git^d094782
src-git telephony https://git.lede-project.org/feed/telephony.git^95498e7


由于这个文件指向的地址都是各个应用程序的Makefile文件而不是二进制文件,所以这个文件其实是在LEDE/OpenWrt/潘多拉中通用的。因为所有的SDK都可以通过同一个Makefile文件编译相应的ipk包。

但是在潘多拉SDK中,feeds.conf.default这个文件里面居然是空的。那么当然就无法通过传统的方法部署相应第三方依赖库的源码了,所以我们这里只要把LEDE SDK中的feeds.conf.default文件内容复制到潘多拉SDK中去就可以了

然后再执行update和install命令,相应的依赖库就会出现在package/feeds中了

然后把/feeds中的libpcre的Makefile做软链接到package/feeds中,使用

./scripts/feeds install libpcre

就可以了,效果如图

package/feeds 下面出现相应的目录就说明安装成功了。

然后我们观察ssr Makefile中的依赖库,发现除了pcre之外,还有另外的三个依赖库

define Package/shadowsocksr-libev
  $(call Package/shadowsocksr-libev/Default)
  TITLE+= (OpenSSL)
  VARIANT:=openssl
  DEPENDS:=+libopenssl +libpcre +libpthread +zlib
endef

所以我们要都安装一下(mBedTLS版需要自己的依赖包)

./scripts/feeds install zlib libopenssl libmbedtls

此时如果你网络状况好的话,一半就可以畅通无阻的编译了。真是谢天谢地潘多拉提供的toolchain还没有问题

这个过程中,SDK会首先根据第三方依赖库Makefile中记载的源码地址去下载相应源码,然后通过这些源码先编译出第三方依赖库,并将相应的ipk文件放到bin目录下。

然后再使用第三方依赖库的源码编译我们所需的应用程序。

注意如果始终无法安装feeds的情况,直接去feeds文件夹下搜索pcre,然后把pcre这个文件夹复制到package/feeds下面也是可以的。

举例来说,比如libpolarssl这个库已经被mBedTLS替代,所以当执行./scripts/feeds install libpolarssl 的时候,会碰到如下报错,说明在feeds中找不到libpolarssl这个依赖库

WARNING: No feed for package 'libpolarssl' found, maybe it's already part of the standard packages?
此时我们去其他地方搜索libpolarssl的Makefile或者自己编写,这里提供一个libpolarssl的Makefile:https://github.com/AlexZhuo/openwrt-feeds/tree/master/base/polarssl
 

同理,在我们编译redsocks2的时候可能会碰到以下错误

utils.h:7:26: fatal error: event2/event.h: No such file or directory
 #include <event2/event.h>
                          ^
compilation terminated.
<builtin>: recipe for target 'parser.o' failed
make[3]: *** [parser.o] Error 1


这个报错和上面的pcre一样,也是找不到libevent这个第三方依赖库,执行./scripts/feeds install libevent2 即可解决

其他报错一般可以用相同的办法解决。包括LEDE

关于LEDE要提示一点,LEDE 17.01的rc1和rc2 目前好像feeds不是很全,推荐使用17.01版本,不要使用rc1或rc2的SDK。

同时LEDE的feeds中很多库的版本要高于OpenWrt CC 15.05.1,所以可以把OP的feeds库换成LEDE的然后重新./scripts/feeds update

猜你喜欢

转载自blog.csdn.net/lvshaorong/article/details/62215033
今日推荐