交叉编译Android平台glib库和其他一些库

2017年7月7日 没有评论

最近有需要把glib库编译上Android上。网上搜索了一下,发觉有人已经写了详细的编译步骤出来了。

编译可在Android上运行的依赖库(一):glib库
交叉编译Android平台glib库

但是按照其方法还是有不少问题。我也不想在这里说明了。因为我估计这些问题可能和你的编译环境等有关系。每个人的机器环境可能都有小小区别。虽然文章也給了具体编译环境的说明,和编译的软件的版本信息。理论上应该没有太多问题。但是我实质上还是遇到问题。 现在提供一个docker来统一编译环境,这样就可以减少问题的存在。而且还提供了编译脚本。其实我已经在建立docker的时候也顺便把编译的工作做了。节省时间。你只要把

docker pull daozhao/glib-android-build-docker

下来,就可以直接使用了。使用的编译方式与文中有点区别,使用standalone的方式编译。我觉得这样的方式比较方便,特别需要对C++的支持。

编译了glib库及依赖包列表:
1) iconv (1.14) https://www.gnu.org/software/libiconv/
2) gettext (0.19.8) https://www.gnu.org/software/gettext/
3) pcre (8.40) http://www.pcre.org/
4) libffi (3.2.1) https://sourceware.org/libffi/
5) glib (2.44.1) https://developer.gnome.org/glib/stable/

其他一下库的包列表
6) jansson (2.10) http://www.digip.org/jansson/
7) gengetopt (2.22.6) https://www.gnu.org/software/gengetopt/gengetopt.html
8) libsrtp (2.0.0) https://github.com/cisco/libsrtp
9) gmp (6.1.2) https://gmplib.org/
10) nettle (3.1) https://www.lysator.liu.se/~nisse/nettle/
11) gnutls (3.5.13) http://www.gnutls.org/
12) libnice (0.1.14) https://nice.freedesktop.org/wiki/
13) libmicrohttpd (0.9.54) https://www.gnu.org/software/libmicrohttpd/

使用方法

docker run -it daozhao/glib-android-build-docker bash

相关信息:

NDK=/home/data/android-ndk-r13b
SYSROOT=/home/data/standalone_toolchain/sysroot
.a & .so 文件在目录 /home/data/standalone_toolchain/sysroot/usr/lib/
.h文件在目录 /home/data/standalone_toolchain/sysroot/usr/include/
arm-linux-androideab* 文件在目录 /home/data/standalone_toolchain/bin/

Bookmark and Share
分类: IT, 编程 标签:

修复mac OS X的Docker: No Space Left on Device

2017年6月6日 没有评论

mac os x的docker现在比较好用,虽然macOS都是POSIX系统。但是多少都和linux系统有点不一样。所以我实验一些新软件系统的时候很多时候还是需要linux系统,以前多数使用虚拟机进行。现在喜欢用docker了。虽然mac上的docker也是运行在虚拟机上的。但是运行效果和在linux上没有什么区别。但有一个问题困扰了我很久。就是经常出现No Space Left on Device。明明我的磁盘还有很多空间。就是老出现这句提示。原来的处理方式,是删除一些不需要的image。最近由于剩下的images都是需要的,删无可删了。

只能上网找解决方法。发现这个问题还是不好处理的。最后虽然成功处理了。大家发觉处理的方式和网上说的有点不一样,所以记录下来。不能说别人的方法错误,只能说明我更加黑仔。

首先,这个不够磁盘空间的问题产生有几种情况的。

1 虚拟机的虚拟磁盘空间不够了。

2 是虚拟机的磁盘分区导致空间不够。(估计大部分人都是这个问题,我就是这个问题导致的。)都不知道为什么docker这么傻逼,生成一个虚拟磁盘是64G的。但是在这个磁盘上在分配一个18G的分区进行使用,超过18G就不能用了。超级傻逼。

现在讲处理方法。

阅读全文…

Bookmark and Share
分类: IT, 编程 标签:

WebRTC Native code在MacOS编译踩坑记

2016年11月28日 2 条评论

想编译WebRTC的源代码,想测试下一些东西。其实官方有说明怎样编译的。理论上也是比较简单的。但是非常不幸的是。webrtc的源代码在墙外。这个源代码据称有8G那么大。不过最后发觉压缩后还有10G多。

代码怎样下载?虽然webrtc用的是git管理代码,但是他的下载是用另外一套工具下载的,具体为什么我也不知道。而且我发觉他下载的代码除了webrtc外还包含了chrome的代码,还有一些第三方的工具。下载这个代码最困难的是由于是巨大的容量,而且不支持断点续传。google是怎样想的,这么大的容量还不支持断点。虽然可以挂VPN进行代码下载。但是需要非常稳定的VPN。而且速度也要快。我想不出哪里可以提供这么稳定的vpn,有时候不是vpn不稳定,而是自身网络也不一定稳定。现在想到的办法是在海外创建VPS服务,把代码拉好了。然后打包下载回来。

由于本身在DigitalOcean有VPS。所以就在上边进行拉取。由于用的是最低的配置,没有拉多久,git就报内存不足了。TMD的。谁叫你穷,买的是512M的内存服务器,现在手机的内存都比你多尼?最后找了国内的云主机供应商的香港云主机。搞个4G内存。下载代码就是非常快了。最后把代码拉到Mac上。不过发觉编译有问题。

第一个问题:

>gn gen out/mac –args=’target_os=”mac” target_cpu=”x64″ is_component_build=false’
gn.py: Could not find gn executable at: /Users/daozhao/Documents/sourcecode/WebRTCdemo/webrtc_macos_test/src/buildtools/mac/gn

找不到命令,怎么搞的。居然找不到命令。看了看gn的代码,发觉有一个chromium编译路径可设置在环境变量的。然后我设置了这个,在这个目录下再创建了一个mac的目录。把depot tools工具都放在这个mac目录中。

export CHROMIUM_BUILDTOOLS_PATH=XXXXXXXX

这样重要可以运行gn生成工具了。结果有悲剧了。又显示了一个错误。

gn fork: Resource temporarily unavailable

网上google了这个错误。没有发现编译webrtc的时候有别人出现这个错误,在其他地方会会出现这个错误,原因是mac os系统有限制创建线程数量。大家可以输入。

>launchctl limit
cpu         unlimited unlimited
file size  unlimited unlimited
data        unlimited unlimited
stack      8388608 67104768
core       0 unlimited
rss         unlimited unlimited
memlock unlimited unlimited
maxproc 709 1064
maxfiles 256 unlimited

最后把参数调大。但是还是报同样的错误。现在我怀疑mac有专用的gn工具的。在同步代码的时候应该是根据系统下载相关的工具。由于我是使用linux系统下载的代码,下载了linux的编译工具,没有下载mac的工具。需要再次运行gclient sync,当然运行这个命令是需要vpn的。但是由于有之前的下载,不用所有东西都重新下载,只是下载很少一部分工具而已。

rm src/links #需要先删除这个文件,要不然会报错。
gclient sync
rm -rf src/third_party/llvm-build
gclient sync

这时候可以从新运行gn生成工具了。

>gn gen out/mac –args=’target_os=”mac” target_cpu=”x64″ is_component_build=false’
Done. Made 347 targets from 107 files in 5461ms

到了这里就可以编译了,编译时间比较久,

Bookmark and Share
分类: IT, 编程 标签:

WebRTC入门指导

2016年11月14日 没有评论

这篇文章是记录之前研究的webRTC的记录,最近准备再次走进WebRTC,所有写下一些资料,以免忘记的时候可以看看。

入门看什么文章比较好,当然是WebRTC的官方网站的Getting Started。不过资料比较多,而且上边列表的资源重复也不少。

Getting started的推荐的2013的google IO关于WebRTC的视频就别睇了,没有什么营养。大家看这三篇对webRTC入门的文章比较好,Getting Started with WebRTCWebRTC in the real world: STUN, TURN and singlingWebRTC data channels,基本上把WebRTC的结构说得个明白。可以对WebRTC有一个很好的整体了解。

对于入门的代码例子就看这个codelab,进阶少少的例子就看WebRTC samplesWebRTC-Experiment,还有一个完全可以用的Demo的线上例子,别忘记了这个Demo的有很多参数可以调整的,请查看参数设置

看完上边的资料,你已经对WebRTC有了基本的了解了。如果你做WebRTC的前端或者关于Signaling的后端开发,这些知识基本够用了。不够如果要深入研究WebRTC,需要做二次开发或者做MCU的话就需要进入步研究了。

由于WebRTC是P2P的,首先需要研究的了解UDP打洞。关于打洞的问题请看Peer-to-Peer Communication Across Network Address Translators这个是关于P2P的网络神作。如果觉得文章复杂,不如先看看这些入门级的文章:穿越防火牆技術P2P通信原理与实现。再找些开源的STUN服务器研究下。

其实需要研究的东西还是比较多的,不过站在巨人的肩膀好办事。这里列几个比较出名的WebRTC开源项目吧,

1. http://www.kurento.org/

2.Licode

https://doubango.org/ 这个是项目有SIP的部分,有webrtc2sip的转换。兼容SIP系统较好选择。

WebRTC有一个比较烦人的问题,Web服务必须使用https来部署,要不然浏览器不给使用相关的api,这样做开发测试的时候比较麻烦。

Bookmark and Share
分类: IT, 编程 标签:

golang 与cgo的跨平台编译

2016年11月2日 1 条评论

golang语音本身是支持跨平台编译的,只要在编译的时候添加相应的选项就可以了。不过有一个问题是不支持带有cgo的程序。如果需要支持cgo还需要配置编译cgo的环境,如果一个带cgo的程序需要编译成多个平台的支持,那是一件痛苦的事情,或者需要编译成非开发机本机运行版本,也是一件麻烦事。特别是开发嵌入式arm程序的时候就编译环境的配置就特别麻烦。不过现在有万能的docker对配置进行了简化。

由于工作需要,之前自己做了一个docker编译go 和cgo在android上运行的images,不过当时是手工制作images,并没有记录制作步骤和写下dockerfile。由于目前go和android的版本升级比较快。所以原来的docker images已经不合时宜了。不想再自己去做这个images了。在网上搜索了一个Go CGO cross compiler这个docker images比自己做的强大很多,支持很多平台的编译。使用起来比较方便。大家可以看看说明就可以了。非常方便。

由于这个docker的操作非常自动,可以说太自动了。例如,编译的项目必须在git上,自动下载项目和项目相关的库。对于一些不在git上的公司内部项目不是很友好。而且好像每次都重新下载项目和关联的代码库。导致编译速度非常慢,本来就是比较慢了。所以我没有使用它提供的的xgo工具。只使用它的docker images。

这个docker images的使用方法官方并没有说明。不过通过其dockerfile可以窥探其秘密。

进入这个docker的命令是:

docker run -it –entrypoint /bin/bash  karalabe/xgo-latest

因为这个docker设置了entrypoint是根目录的build.sh,需要把它替换成bash。这个docker的go path位于/go目录中,代码需要放在/go/src目录中。然后可以运行/build.sh XXXX 进行项目编译。当然可以归宿主机的代码映射到docker目录中并自动运行编译那时最方便的。

docker run –rm -it \
-v “$PWD”:/build \
-v “$PWD”/vendor:/go/src \
-v “$PWD”:/go/src/XXXXX \
karalabe/xgo-latest XXXXX

#XXXX代表你的项目目录名称。这里把项目需要包含的依赖包也一并映射到docker的/go/src中。

这样就可以很方便编译出各个平台运行的版本可执行文件,包括windows,macOS,iOS,android,linux,arm等。不过大多数我们并不需要编译这么多平台的版本,很多时候我们只需一个版本就够了。这样可以节省很多的编译时间。

docker run –rm -it \
-v “$PWD”:/build \
-v “$PWD”/vendor:/go/src \
-v “$PWD”:/go/src/XXXXX \
-e TARGETS=android/arm \
karalabe/xgo-latest XXXXX

这样写就可以只编译android的arm的版本。具体TARGETS支持什么参数,请参考官方说明。

Bookmark and Share
分类: IT, 编程 标签: , , , , ,

RTMP转换成TS流的注意事项

2016年11月1日 没有评论

RTMP转换成TS流的注意事项,

一  需要注意PCR的标记,虽然有人说PCR不是必须的,但是如果你标记PCR的话,必须写对PCR,开始做的时候,因为看见网上的评论说,ipad和苹果的系统并不检查PCR的。所以我就乱打,结果在windows上播放出问题,windows上的媒体播放器会播放得特别快,他是根据PCR的时间播放的。

另外PCR的字段生成,不是简单的=DTS就可以了。PCR的组成是33(PCR_Base)+6(PCR_const)+9(PCR_Ext) ,计算方法参考下边,此方法是参照SRS的计算方式,另外stackoverflow有另外一个方式计算。我觉得SRS的计算方式更加好理解。

PCR_Ext = 0;
PCR_Const = 0x3F;
int64_t pcrv = PCR_Ext & 0x1ff;
pcrv |= (PCR_Const << 9) & 0x7E00;
pcrv |= (PCR_Base << 15) & 0xFFFFFFFF8000LL;

pp = (char*)&pcrv;
data[ 6] = pp[5];
data[ 7] = pp[4];
data[ 8] = pp[3];
data[ 9] = pp[2];
data[10] = pp[1];
data[11] = pp[0];

另外PCR转换成播放时间的秒的方法,具体方法可以参考stackoverflow的帖子:

pcrv = 0
pcrv |= uint64(pcr[0]) << 40
pcrv |= uint64(pcr[1]) << 32
pcrv |= uint64(pcr[2]) << 24
pcrv |= uint64(pcr[3]) << 16
pcrv |= uint64(pcr[4]) << 8
pcrv |= uint64(pcr[5])

programClockReferenceBase := (pcrv & 0xFFFFFFFF8000) >> 15
programClockReferenceExtension := pcrv & 0x1FF
constValue := (pcrv & 0x7E00) >> 9
s =float64(programClockReferenceBase * 300 + programClockReferenceExtension) / 27000000

阅读全文…

Bookmark and Share
分类: IT, 编程 标签: , , , , , , ,

2015年8月菲律宾宿务薄荷潜水日记

2016年5月3日 没有评论

这次的潜水日记不分开每一潜来写,因为我的潜水日记是为了记录我潜水的时候一些操作不佳或者有些做的不好的东西,有待下次改进,主要记录技术问题为主。

这次潜水的是15年8月份在菲律宾宿命薄荷的alone beach和附近著名的Balicasag。潜店选择了无限蓝,选择它的原因是因为有朋友在这里学ow。那我就顺便在这里fun dive。

这次一共潜了7个潜,有4潜是Balicasag。3潜是Alone beach附近。

dive point如下:

1、swiss bamboo

15年08月02日 09:43AM
Dive time 41分钟。
最大深度:19.8米
平均深度:10.5米
水温:29度。


2、tawala marine sanctuary

15年08月02日 02:21pm
Dive time 41分钟。
最大深度:19.6米
平均深度:13.3米
水温:31度。
3、black forest

15年08月03日 10:02AM
Dive time 48分钟。
最大深度:11.5米
平均深度:7.7米
水温:29度。
4、cathedral

15年08月03日 12:08pm
Dive time 44分钟。
最大深度:19.6米
平均深度:13.2米
水温:29度。
5、alona house reef

15年08月03日 06:17pm
Dive time 49分钟。
最大深度:18.3米
平均深度:10.1米
水温:29度。
6、dive’s heaven

15年08月04日 10:00AM
Dive time 40分钟。
最大深度:18.6米
平均深度:10.8米
水温:28度。

7、marine sanctuary

15年08月04日 12:00pm
Dive time 49分钟。
最大深度:19米
平均深度:11.2米
水温:29度。

 

点评一下潜店,这个潜店在国人中都算比较出名,其中有好多国人在这里学习DM,甚至考教练牌。给我的感觉是不过不失啦。没有太多特别。选择中文潜店的好处就是可以大家多交流。这里的教学还是比较认真的,朋友在这里上了4天的ow课程,内容排得满满的。4整天没有闲过。

阅读全文…

Bookmark and Share
分类: 旅游, 生活 标签: ,

编译nginx到Android上踩坑了

2015年4月3日 1 条评论

上个月老细又话把产品移植到android上,哭吧。。。又一堆东西要搞了。收到任务,第一个移植的就是nginx,因为我们的软件使用了nginx作为http服务器,并且针对服务写了些插件绑定在nginx上。心想这个android也是linux内核的,应该左个跨平台编译就差不多了。谁知道折腾了一个多星期。

如果大家只是想最快编译一个nginx上android就不用看我的文章。直接在这里andoid-nginx下载这个针对android修改好的编译配置就可以了。想了解我采坑的就继续看下去。

编译nginx for android主要参考了 这个帖子和另外一个帖子。但是结合自己的遇到的情况做了一些调整。虽然编译不是很顺利,一路遇到不少问题。不过通过万能的google解决了。历尽千辛万苦终于编译完成了。

其中一个主要的修改是对 auto/types/sizeof文件进行修改,由于configure会对编译出来的测试程序并运行,测试出int,long等数值的长度。由于修改了编译器,编译出来的文件只能在arm的系统上跑,那么在编译的主机上是不能跑的。帖子的方法是教你写一个固定的值,我觉得不是太好,事实上也的确不太好。于是我把这个测试程序的编译器改成我编译主机(用的是mac osx系统)的gcc(其实是clang)。还有一个问题就是我的系统是64位的。而我的目标的android是32位的。不过好彩gcc(其实是clang编译器)有一个参数可以编译32位的程序,“-m32″

#ngx_test=”$CC $CC_TEST_FLAGS $CC_AUX_FLAGS \
ngx_test=”gcc -m32 $CC_TEST_FLAGS $CC_AUX_FLAGS \

阅读全文…

Bookmark and Share
分类: IT, 编程 标签: , ,

使用docker重建Gitlab服务

2015年3月6日 没有评论

新年假期回到公司,就发现一个噩耗,就是代码服务器意外关机,重启不成功。虽然我知道linux的机器意外关机会造成不可以预知的损坏,但是在10多年的linux使用生涯中还是真的未遇过。这次终于给我遇上了。

虽然数据在年前已经备份过了。不过我想到的是如果这台机救不回来,要我重新安装这个gitlab服务就真的疼苦了。虽然当初安装的时候有把关键点都记录下来。不过再安装一次的确痛苦。关键是迁移数据的问题。我还发现一个问题就是我没有记录当时安装的gitlab的版本,低级错误。不过经过维护部门的努力,机器是可以重新启动,gitlab服务也正常。不过在等待维护部门的修复,就等待了好几天。好在影响不大,其实这些东西本应不用我操心的。不过公司一共4个开发团队,就我一个团队使用代码管理。其他几个部门还是原始社会的手工管理。所以这个代码服务器想移交去维护部门都不行。

虽然这次救活了,但是我还是需要准备万一下次再出问题的时候,修复不了机器的时候做好准备了。作为快速搭建服务,首选是使用docker进行部署。目前已经有人做好了docker-gitlab的image镜像。目前这个image的版本使用gitlab 7.8.1,不过我们使用的gitlab的版本是6.6.5的版本。不知道数据库是否可以平滑升级。

找了一台Ubuntu 14.04机器进行测试。其实使用这个docker-gitlab的container比较简单,他的github页面说明比较详细。如果新建的gitlab服务,参照他的说明就可以了。比较简单。但是有一个坑,这个可能是docker-compose(原有的fig)的bug。

阅读全文…

Bookmark and Share
分类: IT 标签: , ,

golang的包管理–godep

2015年1月7日 没有评论

golang没有提供包管理工具,只是提供了一个全局的包管理。不过对于一些项目来说,需要一个包管理工具,经过一番google后,最后选择了godep这个工具。

对于这个工具的使用觉得并不是很满意。经常有一些问题,不知道如何解决。有时候昨天不成功,今天有Ok了。真是搞到头大。目前对于一些问题还是不太确认是什么问题。估计是对这个工具的理解不够。

 

这里讲一下使用技巧和一些注意事项。

1、建立依赖json文件。在项目的根目录下运行下边命令。

godep save  或者用 godep save ./…

注意你需要在这个目录运行go build 可以成功编译。就可以。另外你需要把文件Godeps/Godeps.json添加到代码管理中,那样才方便别人下载项目和更新依赖包。,godep save 同时把依赖包的代码都copy到Godeps/_workspace/src目录下,而且把依赖包的git管理目录.git去掉了。你可以把这些依赖包一并上传到你的项目代码管理中,这样别人下载你的代码库的时候就可以直接编译,不需要下载更新依赖包。但是你的代码库会相对大一些,同时也会出现一些其他一些版本问题。

2、下载依赖包

godep restore

这个命令是根据Godeps/Godeps.json文件把项目的依赖包下载到$GOPATH目录下。另外看一看下边的脚本,千万别学他。这个脚本我是参考wandoulabs/codis的项目中的一个编译脚本编写的。就因为这个,我踩坑了。

make clean

echo “downloading dependcies, it may take a few minutes…”
# Test godep install, steal it from LedisDB project :P
godep path > /dev/null 2>&1
if [ "$?" = 0 ]; then
GOPATH=`godep path`:$GOPATH
godep restore
go build || exit $?
exit 0
fi

阅读全文…

Bookmark and Share
分类: IT, 编程 标签: