菲律宾宿务墨宝潜水日志

2018年9月12日 没有评论

这次墨宝的潜水期待已久,计划已久。这次终于来到了。墨宝这个地方比起pg细太多了。这里的沙丁鱼最出名了。

潜店就不介绍。之前的文章已经说过了。潜店是快艇的船,那条楼梯是那些不锈钢管。好在有钢管外包有防滑的胶垫。不喜欢这种楼梯。

配重:这次进购了自己的装备,就差wetsuit不是自己的。而且是第一次使用。买了件背飞XDeep Ghost,使用起来感觉不错。就是有一个问题,后翻落海。要水底要打个跟斗,开始不是很习惯。刚开始的时候配重4Kg。后来发觉水底经常要打气入BCD。后来几潜都要不停地减小配重,最后减到1kg,第一次使用1kg的时候还是感觉有点重,在较深的时候打了两下气入BCD。本来想试试不带配重的。不过后来感觉不带配重可能在3分钟停留的时候比较吃力。所以后来都是1kg下的。不过后来几潜,无论在深的时候还是在停留的时候,都没有大气或者放气。另外这次潜水并没有带spare air下水,因为店家不給充气。

wetsuit是2.5mm的,不知道是否比3mm薄了,所以配重减了这么多。还是因为背负的本身基本上没有正浮力的东西。水温,这次水温大多数是28度,偶尔看到是29度。不过28度給我感觉还是冷。后来发觉件wetsuit的拉链经常没有拉好,又可能拉好了,自己給滑下来了。这件wetsuit是前拉链的。感觉穿的时候也不方便穿。看来wetsuit还是要自购了。还有感觉墨宝的海水不是很咸。不知道是否这样又减少了我的配重尼。

中性:中性之前感觉自己还是可以的。但是这次感觉不是很好。感觉有时候会上上落落的。有可能开始的时候配重比较重导致的。想上升的时候单单用肺部控制感觉太缓慢了,不过后来感觉用踢腿控制一下上升还是不错的选择。还有一个问题这次潜水经常犯错的。就是深度控制,深度经常在潜导的下方1-2米左右。需要经常调整。

阅读全文…

菲律宾宿务墨宝潜店介绍

2018年9月11日 没有评论

以往去潜水都不会事先找定潜店的,都是去到现场看,感觉那家好就找那家。这次例外,因为希望潜店帮忙安排车和住宿等。所以分别联系了潜水主义Savedra。最后选择了Savedra,有一个比较大的原因是buddy看中了Savedra推荐的酒店,有无敌海景。加上这个这个酒店就在潜店旁边,非常方便。我个人也非常喜欢潜店就在酒店旁边。虽然这里不是很大,可能也就5分钟-10分钟的距离,有时候别看小这几分钟的距离。因为这了每一潜都上岸休息。这几分钟来来回来都比较麻烦的。

回来发觉我没有照潜店的外观和内在。只有一张在酒店观望潜店的照片。

潜店

潜店的规模都算大,不过你问我是否推荐这家潜店。我是不推荐的。原因有两个:

1 我带了一个spare air去,希望潜店帮忙充气,结果被店家的老板决绝了。原因我听不明白,只听明最后一句是,你不会用得上的。这个备用气源就是以防万一的。用不上当然最好。我之前在其他地方未试过被拒绝。

2 这了的潜水时间是早上7:30第一潜。这个时间真的要比翻工还要早起床。实在不明白为什么这么早。虽然它家网站说7:30 去看沙丁鱼会人比较少。但是不是每天第一潜都是去沙丁鱼的。虽然出发前就知道这家是这么早的,开始以为可以适应下,或者中午休息补补眠。不过中午休息时间补够补眠啊。

另外这个7:30是出发时间不是集合时间。起码提前15-20集合。加上这么早,吃早餐的地方都未开门,潜店附近就得一家开门。搞到那家的早餐吃了两天。第三天走远点,终于找到另外一家这么早开门的。

阅读全文…

菲律宾宿务墨宝潜水住宿与美吃攻略

2018年9月10日 没有评论

想去墨宝这个地方潜水很久了,这里有比较著名的沙丁鱼。在网络上看到很多沙丁鱼的图片都很震撼。上年10.1假期就想去这个地方,最后还是选择了pg是因为去墨宝的交通不是那么方便,而且网上找这里的潜水攻略也不是很多,说明也不是很详细。有很多不明白的地方。所以没有去,之后一路都有留意墨宝的资讯,总算搞明白了一些东西。这次是在8月18日星期六去到墨宝。

去一个地方旅游最重要的是机票和住宿。机票这个没有什么好说的,不同地区出发都有不同的方案,这个我也不想多说。这里说一说住宿吧。因为第一次想去的时候没有去成,有8成是住宿没有搞定。

首先这个半岛还是挺大的。在订房网站,或者google搜索,发觉整个岛周围都有酒店。究竟住那里是一个问题。那里才是我们这些背包客的集中地尼。大家请看下图,红色标记的岸边应该是背包客的集中地。其他地方估计是比较漂亮的酒店。因为这次我就在这个区域行走,其他地方没有去。不确定那些地方是否也一样旺,潜水坐船的时候看见也有不少的住宿,在白沙滩那里很多人在玩。住宿最后是找这个红色划线区域,不过这里的住宿大多都是比较廉价的住宿,青年旅馆的床位酒店也多。经常看到一些相对好些的酒店都是被订满了。我是提前一个月进行预定的。

墨宝住宿地图 阅读全文…

TensorFlow with CUDA安装在Ubuntu的踩坑记录

2018年5月3日 没有评论

最近研究TensorFlow,需要开发环境,需要安装一个。我选择了在Ubuntu上使用docker来进行TensorFlow开发环境。因为使用docker是目前最方便搭建开发环境的工具。

安装步骤官方文档说明得比较详细。其实用docker安装环境没有什么可以说的,能会有问题么?如果你使用cpu版本基本不会有问题的。但是如果你使用的是GPU版本。那你还要安装CUDA环境和需要这些支持。我选择了使用CUDA9.1,安装教程在这。在CUDA9.1的下载安装我选择了从网络deb的方式

不过安装后,运行测试程序(nvidia-smi)或在运行nvidia-docker失败。

 
Failed to initialize NVML: GPU access blocked by the operating system

nvidia-docker failed to initialize nvml: driver/library version mismatch

后来发觉这是驱动的安装问题。我使用的是这里的下载的驱动文件,你可以在www.nvidia.com/drivers按照你显卡型号选择驱动,我发觉最后下载的文件都一样的。下载的文件名称NVIDIA-Linux-x86_64-390.48.run。使用

sudo sh NVIDIA-Linux-x86_64-390.48.run

进行安装,途中会有些报错,不理会继续继续。但是安装出来后,cuda不能正常运行。查询google。最后发现原来官方说这个驱动在ubuntu上需要手动安装。不要直接运行run文件。

#这里先卸载之前安装的驱动。
sudo apt-get remove --purge nvidia-390 nvidia-modprobe nvidia-settings
#重新安装驱动,虽然安装过程中有报错,不过后来测试运行暂时没有发现问题。
sudo apt-get install nvidia-390 nvidia-modprobe nvidia-settings

经过这一卸载,再安装就成功了。幸福来得有点突然。哈哈哈。

还有一个地方需要注意的是,nvidia-docker的安装需要指定的docker版本,而且这个版本必须是精确的版本。不能高于或在一个小升级的版本。而且这个版本不是稳定版本来的。我这次需要的是Docker version 18.03.1-ce, build 9ee9f40版本。不过你的版本不对他是不会继续给你安装的。

下边给几个用于检查安装好的环境

cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module  390.30  Wed Jan 31 22:08:49 PST 2018
GCC version:  gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)

ls -l /dev/nvidia*
crw-rw-rw- 1 root root 195, 254 May  3 10:00 /dev/nvidia-modeset
crw-rw-rw- 1 root root 243,   0 May  3 09:03 /dev/nvidia-uvm
crw-rw-rw- 1 root root 243,   1 May  3 10:00 /dev/nvidia-uvm-tools
crw-rw-rw- 1 root root 195,   0 May  3 10:00 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 May  3 09:03 /dev/nvidiactl
(我安装驱动失败的时候这里只有两个设备,/dev/nvidia-uvm和/dev/nvidiactl)

lspci | grep -i nvidia
01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 730] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1)

cat /proc/driver/nvidia/gpus/0000:01:00.0/information
Model: 		 GeForce GT 730
IRQ:   		 34
GPU UUID: 	 GPU-????????-????-????-????-????????????
Video BIOS: 	 ??.??.??.??.??
Bus Type: 	 PCIe
DMA Size: 	 40 bits
DMA Mask: 	 0xffffffffff
Bus Location: 	 0000:01:00.0
Device Minor: 	 0

大家别笑我的GPU太差。真实使用的时候需要租用云服务器的GPU。

2017年国庆Puerto Galera潜水日记

2017年10月19日 没有评论

这次是我第二次来到puerto galera了。上一次来的时候是2013年农历新年的时候,那时候的pg不是很多国人,虽然在中文潜店会很多国人。但是这次再来,发觉国人已经占据了这里,我在鬼佬潜店,也是大部分是国人。在餐厅,客人基本上都是说中文的。給我感觉是这里不能再来了。不过后来潜完水,觉得这里还是可以再来的。

这次的潜店也是我上次帮衬过的。blue:ribbon Dive resort 现在有中文名了,叫“蓝丝带”。不过现在的pg几乎所有潜店都会贴出中文店名的。Asia dive还有巨型中文海报。这家潜店給我的感觉没有上次好,虽然还是很不错的。设备比以前旧了。一些细节没有以前好了。例如上水后冲身的水,水压细了。还有冲洗池没有分冲洗bcd,wetsuit,相机。感觉不是很好。虽然影响不大。

这次选择了潜店,原因是上次在这里潜水体验还是不错的。特别是那条大木船。不过现在发觉很多潜店都改用大木船了。这次价格比上次贵了。1200php/潜,6潜以上是1100php/潜。不够不包装备,装备全套300php/潜。由于我有fins和mask,装备减50php/潜。

这次潜水感觉都比之前熟练了,在用气方面应该比之前好了很多,省气了。基本上水都在90bar左右,其他有些同行者都没有气了,要上水了,我有时候还有成100bar的气,

对付流方面可能有改进,又可能这次基本上没有遇到大流吧。因为没有对比很难说明问题。不过踢水感觉比以前有效率了。不过用力过猛的时候感觉有小小抽筋feel。而且在上船前,脱fin的时候试过脚子公抽筋。这个估计是我个人老问题了。筋骨硬。脱fin的时候特别小心。

阅读全文…

coturn的用于webrtc的测试

2017年9月6日 没有评论

coturn是一个开源的turn/stun的服务器,大家可以使用它进行webrtc的测试搭建。当然也可以用于生产环境。此文只是介绍其用于测试环境如何配置其用户于验证。这里可以配合apprtc-go的测试进行说明。

coturn服务器是包括了turn和stun这两个服务的。如果你只需要stun服务。按照下边的命令启动就可以。(假设turn服务器和apprtc-go服务器都运行在192.168.2.170上,另外,如果需要测试turn服务,需要把连接的两台机器分别放在不同的网段,相互之间不能访问,才能发挥turn的功效)

turnserver --no-auth --stun-only -v
参数说明:
--no-auth  不做用户认证,只有stun可以不用用户认证,
                turn服务,在iceServer中必须给出用户名认证等,
                要不然页面建立peerConnect的时候报错。
--stun-only  服务器制作stun服务,不做turn服务。
-v       打印log信息。请不要用-V,大V的信息量太多了。

apprtc-go的启动需要添加stun参数給,命令如下

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
                      -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key  \
                      -httpport=8080 -httpsport=8888 \
                      -stun=192.168.2.170:3478

iceServer返回json,只有stun服务器列表。

{"iceServers":[
{
   "urls": [
           "stun:192.168.2.170:3478"
           ]
}
]}

这样在浏览器就可以键入https://192.168.2.170:8080,就可以进行测试。建议使用两台机器,并连接到不同的的子路由器下进行测试。

测试turn服务,固定用户名,密码

turnserver -v  --user=daozhao:12345 --realm apprtc  --no-stun
参数说明:
--no-stun 不启动stun服务,所有stun的包都被忽略。
--user  用户名和密码 组合形式username:password
--realm  域标志,其实这个在这里随便写就可以。
             但是不能不写,要不然认证失败401

apprtc-go启动的时候添加turn服务器参数,使用静态用户名密码。

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -httpport=8080 -httpsport=8888 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-password=12345

iceServers返回,注意,如果使用turn服务列表,必须有username和credential。这里的用户名密码是静态的。

{"iceServers":[
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
    "username": "daozhao",
    "credential": "12345"
  }
]}

测试turn服务,动态验证用户名,密码:

turnserver -v  --user=daozhao  --realm apprtc --static-auth-secret=654321  --no-stun
参数说明:
--static-auth-secret  认证加密需要的key
--user   有static-auth-secret设置时候,这里只需要写用户名。
             不要写密码,要不然认证失败401

apprtc-go启动命令行。

./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -httpport=8080 -httpsport=8888 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-static-auth-secret=654321

iceServers返回,注意这里是一个动态的用户名密码。这个用户名密码的计算方法:
用户名由两段组成 timestamp:username
credential的计算方式 base64(sha1_HMAC(timestamp:username,secret-key))
详细的参考这里

{"iceServers":[
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
    "username": "1504596938:daozhao",
    "credential": "k/yZNM4Jfofkqqa7ygBP5yCstow="
  }
]}

下边是一个完全事例。

turnserver -v  --user=daozhao  --realm apprtc --static-auth-secret=654321 
./apprtc-go -cert=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.pem \
            -key=$GOPATH/src/github.com/daozhao/apprtc-go/mycert.key \
            -stun=192.168.2.170:3478 \
            -turn=192.168.2.170:3478 -turn-username=daozhao -turn-static-auth-secret=654321 \
            -httpport=8080 -httpsport=8888

iceServer返回:

{"iceServers":[
{
    "urls": [
      "stun:192.168.2.170:3478"
    ]
  }
,
{
    "urls": [
      "turn:192.168.2.170:3478?transport=udp"
    ],
	"username": "1504598153:daozhao",
	"credential": "+pUWOR9wKKgBRXQoLJ7tl2PlFSA="
  }
]}

参考链接:

http://www.cnblogs.com/lingdhox/p/4209659.html

http://www.cnblogs.com/kakawater/p/7112925.html

https://stackoverflow.com/questions/30745153/turn-server-for-webrtc-with-rest-api-authentication?noredirect=1&lq=1

分类: IT, 编程 标签: , , , , ,

在chrome上调试webrtc踩坑记

2017年8月21日 没有评论

最近又再次用chrome测试webrtc的demo(https://appr.tc/)。 为了有更多的控制性,和测试两个客户端不同的网络环境的情况是否可以通讯。此网站是google提供的测试网站并且提供了网站的全部源代码(https://github.com/webrtc/apprtc)。可以自行部署在自己的机器上。部署webrtc的服务器,如果想访问摄像头的功能必须部署https。或者你只能通过localhost来访问。apprtc提供的代码是需要部署 Google App Engine SDK for Python的。或者使用使用这个docker(piasy/webrtc-build),使用说明。不过存在一个问题,就是它们都不支持https的访问,如果用chrome来调试,就只能本机访问。或者你在做一个https和wss的转发代理。

上述的方法我并没有采用,我是用golang重写了一次这个demo的python部分。代码请去https://github.com/daozhao/apprtc-go。为什么重写这个,当然有原因,这里就不说了。

先说说我的发现的bug。我发现在windows的chrome经常建立不了呼叫和应答,出不了视频图像。有时候可以有时候不可以。搞不懂。使用的官方的appr.tc的网站测试和自己搭建的测试环境都一样。但是我在mac OS X上的chrome肯定是可以的。实在搞不懂。

测试了很久,终于发现规律了。就是我如果是通过Mac OS X 上的Microsoft Remote Desktop去登陆windows进行操作,进行测试是没有任何问题的。但是如果我是直接在windows的主机上操作就是老出不到图像。或者,先remote过windows,chrome进行过呼叫,并出过图像,然后再在windows主机操作,这样也是可以的。这个真的令我奇怪不已。

不过找其他同事的windows机器测试并没有此问题。真的傻了,chrome升级了一遍又一遍,卸载重装。问题依旧。后来细心思考了一会儿,估计出问题是截屏问题,因为我的windows是台式机,并没有摄像头。呼叫或者应答的时候是输出桌面的截屏视频的。后来我在主机接上了一个usb摄像头。并在chrome的设置使用该摄像头。发觉问题解决了。这个问题搞了我2天。真的TMD。

在这个bug解决后,我继续思考。chrome的桌面输出是需要在启动的时候添加参数才可以。我由第一次使用chrome测试webrtc就没有打开过这个参数,就可以输出桌面的。我开始并不以为然。以为网上的资料有错,由或者我之前打开了chrome的测试模式。现在看来这个桌面输出并不是chrome自带的。而且我安装了一个第三方的截屏输出的驱动。而chrome把它也当作一个摄像头。我查询了一下这个截屏输出是screen-capture-recorder。原来这个东西和chrome有点不合。不过我在别的同事也安装了这个插件的机器上,并没有我的问题。看来是版本的原因。

分类: IT, 编程 标签: ,

交叉编译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/

分类: 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就不能用了。超级傻逼。

现在讲处理方法。

阅读全文…

分类: IT, 编程 标签: ,

WebRTC Native code在MacOS编译踩坑记

2016年11月28日 3 条评论

想编译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

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

分类: IT, 编程 标签: , ,