积累日常生活的点滴,开发过程的心得。

centos 7上安装 gcc 4.7.2

CentOS7的默认gcc是4.8.5,需要降级到gcc 4.7.2

sudo wget -O /etc/yum.repos.d/slc6-devtoolset.repo http://linuxsoft.cern.ch/cern/devtoolset/slc6-devtoolset.repo
sudo yum localinstall --nogpgcheck compat-libgmp-4.3.1-1.sl7.x86_64.rpm compat-libmpfr-2.4.1-1.sl7.x86_64.rpm

sudo yum install devtoolset-1.1-gcc-c++ --nogpgcheck http://linuxsoft.cern.ch/cern/devtoolset/slc6X/x86_64/RPMS/

scl enable devtoolset-1.1 bash

在windows上编译Tensorflow C++ 工程

找了半天,只有这个文章最靠谱

https://joe-antognini.github.io/machine-learning/windows-tf-project

在Windows上编译Tensorflow

参考https://joe-antognini.github.io/machine-learning/build-windows-tf

1.安装cmake 3.6
2.安装swig 3.0.10
3.安装VS2015
4.执行C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat
5.下载Tensorflow
C:\...> git clone https://github.com/tensorflow/tensorflow.git
6.生成cmake 文件
C:\...> cd tensorflow\tensorflow\contrib\cmake
C:\...> mkdir build
C:\...> cd build

Delphi的IOS 64bit的大bug

https://quality.embarcadero.com/browse/RSP-11802,
只要是Xcode6.3.1之后的版本编译的第三方库,在64bit下编译都回报告无法对齐的错误

更让人震惊的是,这个bug从Delphi Seattle就已经有人报告了,但是到了Delphi Tokyo过了一年半,仍然没有修正。
这个bug导致所有的,所有的,所有的(重要的事情说3遍)第三方的IOS的library在64bit时都无法使用。

感觉没有用户用Delphi做IOS开发一样。

挖矿软件

https://bitcointalk.org/index.php?topic=1433925.0

1.支持双挖, ETH和SC
2.需要设置虚拟内存为16G
3.设置窍门,ping 矿池,ping值小的矿池可以减少stale份额。

Nvidia超频软件

http://download.msi.com/uti_exe/Afterburner_4.4.0.zip

GPU-z

可以看显存颗粒是否是三星,镁光还是海力士,海力士的不能超频,千万别买

A卡超频,需要刷bios。A卡没有三星颗粒。

超频设置,挖eth,三星颗粒可以拉倒700. 参考附件的图片,核心降200也不影响算力。

使用gclient 同步webrtc代码

用法帮助 gclient help

修复错误
gclient sync -R
glcient revert

取特定版本

gclient sync -r src@968c9ccfe80f6f0d64991d5e997ce74774381dfa

切换编译版本是相当的慢,要下载好几G的chrome的代码

禁用MAC OSX的SIP

Mac OSX有一个很恶心的功能,那就是禁止删除系统文件。
但是它自身带的文件经常版本非常旧,比如nasm。
我编译了新的nasm想替换掉它的nasm,但是系统禁止。

只好重启的时候,按下command+r进入恢复模式,然后用csrutil disable禁止SIP

Webrtc ice错误解决办法

janus-gateway 连接时有时会报告ice failed,或者dtls timeout错误

1.首先确认stun server设置

vi /usr/local/etc/janus/janus.cfg

[nat]
;public_ip = 1.2.3.4
stun_server = stun.l.google.com
stun_port = 19302

注意google的stun从中国访问不了,可以改用stun.voipstunt.com

2.确认stun server的连通,用https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
来测试,这个也可以用来测试turn server,返回的信息一般是

0.001 1 host 1947478017 udp 172.16.100.20 62003 126 | 30 | 255
0.002 1 host 161342690 udp 2001::4137:9e76:38a4:dbe:745d:8c18 62004 126 | 10 | 255
0.002 2 host 1947478017 udp 172.16.100.20 62005 126 | 30 | 254

编译Webrtc的IOS Static Library

现在网上发布的Webrtc都是Embeded Framework,Delphi没法编译使用这种Framework,所以只好自己编译

1.gn gen out/Release-arm -args='target_os="ios" target_cpu="arm" is_component_build=false is_debug=false ios_enable_code_signing=false'

2.ninja -C out/Release-arm webrtc

注意生成的libwebrtc.a里面有很多的debug symbol,生成的文件很大,要strip一下

另外,要用lipo生成armv7 , arm64的fat library。

2019/4/21追记

现在最新的Webrtc ios,应该是2018年3月6号的时候, 移除了编译静态library的功能,晕死.参考下面的ticket,
https://bugs.chromium.org/p/webrtc/issues/detail?id=10008
然后EMB这傻叉不支持Embed Dynamic Framework,有人题了一个ticket给emb,但是我怀疑EMB是否有足够的资源去实现这一功能.

我们只能使用第三方的编译的静态库了,参考下面的url

Google的程序员有时很SB

ffmpeg的开发者很生气,google在Android 7之后强制要求所有的NDK的library不能有Text Relocation。
说这么做的理由是会导致系统变慢,但是ffmpeg的开发者反驳这么做会导致很多汇编代码需要重写,重写的代码可能会变慢,会花很多时间去调试,Google又不会赞助程序员重写的费用。
ffmpeg的开发者表示google的SB锅我们不背。
https://trac.ffmpeg.org/ticket/4928

x264也被这个问题影响了,也被x264的开发者给怼了,为了快那么几个毫秒,影响了x264的2万行手写的汇编代码。大家一致公认google傻逼
https://mailman.videolan.org/pipermail/x264-devel/2016-March/011589.html

同步内容