2019年已过去 30.11%
Compiling Project V on merlin-arm-eabi    @ 2018-09-20, 23:39

要在一个刷了梅林系统的路由器上,编译 Project V

在安装了 entware 以及 opkg/gcc/binutils/bash/vim 等一系列必备环境后,因为 Free Pascal 最新版 3.0.4 没有提供 arm 版,所以下载 Free Pascal 3.0.2 arm-linux-eabi。解压后有 install.sh 安装脚本,但由于 BusyBox的 tar 参数有区别,需要将脚本中的 tar 的 --no-same-owner 参数删去,然后才能执行。安装完,fpc 即可正常运行了。

然后尝试用 fpc 编译 Project V,在连接阶段出错:

...
Linking out/proj_v
/opt/bin/ld: warning: out/link.res contains output sections; did you forget -T?
/opt/bin/ld: cannot find -lpthread
/opt/bin/ld: cannot find -ldl
/opt/bin/ld: cannot find -lc
proj_v.lpr(184) Error: Error while linking
proj_v.lpr(184) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /tmp/mnt/sda1/entware/bin/ppcarm returned an error exitcode

搜索 libpthread 文件后,将其所在的工具链目录加入编译选项

-Fl/tmp/mnt/sda1/entware/lib/gcc/arm-openwrt-linux-gnueabi/6.3.0/

重新编译,却得到了不同的错误信息:

...
Linking out/proj_v
/opt/bin/ld: warning: out/link.res contains output sections; did you forget -T?
/tmp/mnt/sda1/entware/lib/fpc/3.0.2/units/arm-linux/rtl/ucprt0.o: In function `_start':
(.text+0x50): undefined reference to `__uClibc_main'
/tmp/mnt/sda1/entware/lib/fpc/3.0.2/units/arm-linux/rtl/system.o: In function `SYSTEM_$$_SYSTEM_EXIT':
system.pp:(.text.n_system_$$_system_exit+0xc): undefined reference to `_haltproc_eabi'
proj_v.lpr(184) Error: Error while linking
proj_v.lpr(184) Fatal: There were 1 errors compiling module, stopping

错误提示说找不到 __uClibc_main 函数,可知编译器连接的 ucprt0.o 文件使用的是 uClibc,而不是 glibc。然后在 github 中找到了华硕梅林的工具链库,在其中的 am-toolchains/brcm-arm-sdk/hndtools-arm-linux-2.6.36-uclibc-4.5.3/lib 目录中,包含了 uClibc 的相关库,将此目录中的所有文件,放置在一个新目录(/tmp/mnt/sda1/entware/libuc),将之前添加的 fpc 编译参数改为:

-Fl/tmp/mnt/sda1/entware/libuc

再编译错误提示没有找到 libpthreadlibdl

/opt/bin/ld: cannot find -lpthread
/opt/bin/ld: cannot find -ldl

需要在 libuc 目录中为这两个库做软链:

$ln -s libpthread-0.9.32.1.so libpthread.so
$ln -s libdl-0.9.32.1.so libdl.so

再行编译,出现新的错误提示:

Linking out/proj_v
/opt/bin/ld: warning: out/link.res contains output sections; did you forget -T?
/tmp/mnt/sda1/entware/lib/fpc/3.0.2/units/arm-linux/rtl/system.o: In function `SYSTEM_$$_SYSTEM_EXIT':
system.pp:(.text.n_system_$$_system_exit+0xc): undefined reference to `_haltproc_eabi'
proj_v.lpr(184) Error: Error while linking
proj_v.lpr(184) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /tmp/mnt/sda1/entware/bin/ppcarm returned an error exitcode

这个错误提示着实令人郁闷了很久,做了很多尝试都失败了。幸好,Free Pascal 是开源的,看似无解的问题最终可以从源码上找答案。于是去下载了 fpc 3.0.2 的源码,在源码的 rtl/linux/system.pp 文件中,查找到 _haltproc_eabi 相关的部分:

{$if defined(CPUARM) and defined(FPC_ABI_EABI)}
procedure haltproc(e:longint);cdecl;external name '_haltproc_eabi';
{$else}
procedure haltproc(e:longint);cdecl;external name '_haltproc';
{$endif}

只知道了 _haltproc_eabi 定义在外部(不在此文件内)。然后在所有源码文件中搜索 _haltproc_eabi,在 rtl/linux/arm/ 目录中的四个 .as 文件(汇编源码)中找到,但该目录下实际有五个 .as 文件,而唯独之前打过交道的 ucprt0.as(也就是之前提到的调用 uClibcucprt0.o 的汇编源码)中没有 _haltproc_eabi 的定义,这样就能说得通了。通过对比 cprt0.as(使用 glibc 的版本)和 ucprt0.as,在 ucprt0.as 的第155行插入如下代码:

        .globl  _haltproc_eabi
        .type   _haltproc_eabi,#function
_haltproc_eabi:
        ldr r0,=operatingsystem_result
        ldrb r0,[r0]
        mov r7,#248
        swi 0x0
        b _haltproc_eabi

并将修改后的 ucprt0.as 放入 fpc 相应目录中 /tmp/mnt/sda1/entware/lib/fpc/3.0.2/units/arm-linux/rtl,使用 as 将其汇编

$as ucprt0.as -o ucprt0.o

再回到 fpc 编译 Project V,编译通过。

尝试运行,正常。

以上是摸索了不少时间后,整理出来的逻辑,看起来简单不少,但其实整个摸索过程却不会这样有条理。尤其最后将问题定位到 ucprt0.o,还是偶然通过查看连接过程中生成的 link.res 文件找到一丝线索的(link.res 文件明确指出了连接时使用的是 ucprt0.o)。

我爱 Pascal。

软硬兼施 | 3 个评论 | 1,195 次阅读
简短地址:http://ncblog.net/1483/
我的静电容键盘折腾史    @ 2018-09-08, 21:38

2014年5月20日前,我一直是用机械键盘(青轴)的。

那时的某一天,在知乎上看到有人说,要解毒机械键盘,必须用更毒的静电容键盘。于是知道了静电容键盘这样一个物种,除开布局“怪异”的 HHKB,当时全球静电容键盘最主要的品牌就是日本的 Realforce,在2014年5月20日到手了 Realforce 的黑色分区压力104U。

所谓分区压力,是指 Realforce 键盘的一个特色:按键压力克数按照手指分区,小指按键区域为30克压力,ESC 和 NumLock 为55克压力,其余按键为45克压力。应该说这是一个相当人性化的一个特性。

在那之后,我就再也不会对机械键盘有任何兴趣了,真的彻底解毒。说到静电容与机械键盘的体验差异,其实是很难文字描述的。非要说的话,我个人体验是感觉静电容按键更像按在有足够弹性的肉肉上面,而机械键盘更像敲击在膝盖这样的关节骨头上。当然每个人可能会有不同的体验或者喜好,我也有朋友就是不喜欢静电容,这不奇怪。

对静电容的中毒之路当然不可能就此戛然而止,大半年后,在2015年2月1日,又入手了同样是 104U 的白色分区款。Realforce 的白色款相当的复古,但又让人觉得有点闷骚。

在有了黑白双煞之后(一把家里用,一把在公司用),安生了好久。

然而在 2015年9月,又意外发现新出了十周年纪念版的蓝灰配色的韩国定制版,顿觉销魂,但是只有80%款的 87U,没有小数字键盘部分。

心心念念,必有回响,当月下旬还是忍不住淘宝下单韩国代购,在 2015年国庆假期期间到了中国,来不及等 EMS 上班送货,10月3日便自己去邮局领取了。也于是在那个假期里,有了当时发的这个朋友圈,有了我的 blog 的这个副标题:

不过由于我的使用习惯,没有了数字小键盘感觉到相当地不方便,试着习惯了一个多月仍然不能忍。而后 Realforce 已经有了十周年的中国定制版,还推出了之前很罕见的104键的全域30克版本(也就是全部按键的压力克数都是30克)。于是在 12月14日,成功将 87U 在闲鱼上出手后,就下单了全域30克的 104 Pro。

次日就收到了货,红灰配色确实更骚气,但是发现一个重要问题是,之前对全域 30克的迷思,真的只是一种迷思。因为到手后,才实际感受到 30克太软了,之前我说的那种肉肉的感觉没有了。幸好老婆觉得还不错,于是就给了老婆在当时 Mera 公司里使用。而我在当天,也就是12月15日继续下单了代替刚出手的蓝灰配的 87U的,依然是蓝灰配色,但是是静音版、全键盘的 104U。我是个颜控,蓝灰配色在我眼中仍然是无敌的。

这样,我和老婆在家分别使用黑色和白色的 104U,在公司我用蓝灰色静音版的 104U,老婆用红灰色的 104Pro,由此置备下了四个 Realforce 静电容。

然而,我的蓝灰色 104U是静音版,所谓静音版就是在内部加了垫圈能降低30%的按键声音,但是却影响了手感,这就为后续的折腾埋下了伏笔。

使用静音版两周后,依然觉得远不如非静音版敲击起来那么爽快的感觉,这不能将就。但蓝灰配色又是那么销魂,怎么办?折腾没有局限,我把蓝灰色的键帽与家里的黑色104U的键帽对换了一下,于是产生了一把蓝灰色分区 104U,和一把黑色静音版 104U,并且把黑色静音在闲鱼上贱价转让了。虽然很亏,但是看着剩下的可能是全球唯一的,自行组合出来的,完美的,蓝灰色分区的104U,感到满足。

因为少了一把键盘,在家里老婆重新用起了茶轴,就这样保持了一长段时间,直到 Mera 项目结束,团队解散,从办公室搬回了家。从办公室撤回后,就又多出一把键盘,因为经济原因,2016年12月,在闲鱼上把全域30克的红灰版也转手了。

今年 2月到深圳参加即将入职CTO的长颈公司的年会,抽中了二等奖 Realforce 红灰色的全域45克版键盘,外观与之前拥有过的全域30克完全一样,区别只在压力克数都是45克,不像30克那么软,所以成了在深圳时使用的键盘。

从外观来说,当年拍的这张照片就是我现在拥有和使用的两把键盘。

老婆用的白色分区 104U,灰色键也给换成了我后来买的一套蓝色键帽了。

静电容的折腾应该就此为止了,折腾过程还是挺费钱的,现在对于身边的朋友,我都是推荐分区非静音的静电容键盘,这也是在我的折腾一大圈后得到的一个简单结论。全都试过了,知道自己喜欢什么想要什么了,就没有遗憾了。

软硬兼施 | 1 个评论 | 1,063 次阅读
简短地址:http://ncblog.net/1468/
Visual Studio Code    @ 2018-07-29, 02:03

6月底在深圳时,由于主要工作平台成了 Macbook Pro,而 Lazarus 在 Mac 平台上几乎不可用,于是写 Pascal 代码时就不得不用其他编辑器取代。之前用的 Atom 已经实在臃肿不堪,越来越无法忍受,于是放弃了 Atom 转投了 Visual Studio Code。

配置完 vsc 后,对比之下,Atom 实在差太多了。不说运行速度与轻巧的感受,单单扩展插件的丰富与完善程度,就值回票价。尤其在对 Pascal 语言的支持上,OmniPascal 扩展支持自动完成、声明跳转、语法着色等基本功能,还能直接调用 Free Pascal 编译器编译,对不涉及 GUI 的代码,写起来毫无阻力。Numbered Bookmarks 扩展更是让我在 Delphi 之外唯一能找回 Ctrl+数字 来为代码做书签快速跳转的功能。由此,我在 Mac 上也能愉快地编写 Pascal 代码了。

软硬兼施 | 评论已关闭 | 1,019 次阅读
简短地址:http://ncblog.net/1416/
坏了一块硬盘    @ 2018-04-25, 23:44

从细选网时代至今,工作了整整六年的一块硬盘挂了,于是工作室墙上多了一个挂饰。

软硬兼施 | 评论已关闭 | 1,260 次阅读
简短地址:http://ncblog.net/1380/
GitLab(社区版)    @ 2016-07-23, 17:51

陆陆续续折腾了一周,终于把 GitLab 部署完善并且用于改善公司内部开发流程管理了。

GitLab (社区版)本质上就是一个可供自行 host 的 GitHub 的克隆,将项目的人员权限管理/需求管理/bug 管理/开发分支管理/里程碑管理/自动化测试、build/项目wiki 全部集成。很爽,基本复刻了 90% 以上的 GitHub。适合不想在 GitHub 花钱托管私有项目或者希望自行 host 代码库的中小团队,而且社区活跃,开发进展速度极快,强烈推荐。

软硬兼施 | 评论已关闭 | 3,491 次阅读
简短地址:http://ncblog.net/1227/
phpRedisAdmin    @ 2013-08-01, 09:14

自从使用redis以来,一直在试图寻找一个redis的数据浏览工具,使用redis-cli命令行方式毕竟不够方便以及直观。

前阵子找到一个(貌似也是目前我能找到的唯一一个)基于web的redis数据浏览工具 phpRedisAdmin

给工作学习带来了极大方便,我和我的小伙伴们都惊呼了。

软硬兼施 | 评论已关闭 | 5,494 次阅读
简短地址:http://ncblog.net/1092/
不要再碰virtualbox    @ 2013-06-04, 23:18

又浪费了一晚上时间。以后不要再尝试virtualbox! :evil:

软硬兼施 | 3 个评论 | 11,793 次阅读
简短地址:http://ncblog.net/1085/
搜狗拼音 for linux(fcitx)    @ 2013-05-07, 10:51

自从将linux作为主工作环境以来,唯一一直不太理想的,就是中文输入法了。虽然去年用上了谷歌输入法(A fork from google pinyin on android),感觉还可以,但终究是从较早版本的android平台下挖出来的,非官方,也有不少缺陷。

今天发现前不久随Deepin beta版发布的搜狗输入法0.0.1-1版(fcitx-sogoupinyin)的deb包,立刻装上,非常爽。另外,它还支持繁体。不过,貌似官方还没有正式发布,但也已经非常完善了。

不过,我还是更期待google官方能出google拼音 for linux,才好同步我的云词库。

软硬兼施 | 评论已关闭 | 7,853 次阅读
简短地址:http://ncblog.net/1081/
Lazarus 1.0    @ 2012-08-31, 09:37

出于对Pascal的热爱,关注Lazarus当然已经n多年了,具体什么时候开始的,已经记不清了,至少在2005年6月Free Pascal 2.0发布之前,我已经知道并且下载过Lazarus早期版本了,当时的版本当然是非常原始的。

与Lazarus深度接触的开始,还是2009年上半年,开发 LazSkin的时候,当时版本是0.9.26.2,那时的版本,虽然bug仍然较多,但我觉得已经达到了可用的程度了。所以将SUISkin移植到了上面,有了 LazSkin

之后一段时间脚本语言使用较多,没有再关注。直到前几天发现Lazarus 发布了1.0RC2版,心中不禁欣喜——当一个著名开源项目,宣称版本号达到1.0程度时,一般已经意味着,该项目的可用度已经达到了一个非常的高度了。于是赶紧下载下来,安装后初步使用发现确实没有什么明显的问题了。之后,试着将几个简单的Delphi工程转换成Lazarus工程,编译、运行,也完全没有问题。令人惊喜的是,转换过程相当顺利,界面定义frm文件转换后,也没有出现任何界面上的变形、错位等问题。由于那几个Delphi工程都很简单,没有涉及到Windows API调用,因此编译后也很顺利的在目前使用的主要桌面环境Linux Mint 13下运行。

而今天,发现1.0正式版已然发布!
我希望在我今后的工作中能用 Lazarus 作为编译语言的选项,成为脚本语言的补充。Python做界面还是麻烦,以前有个类似的工具boa,可惜貌似不维护了。

Delphi 是早就可以进历史了,Lazarus(Free Pascal)生命力却越来越强。
Delphi 多年以前想做却一直没有做成的跨平台(kylix?mac?x64也是直到去年才支持,连个unicode都是前两年才支持),这些东西,Lazarus从最初就是原生支持。
Delphi IDE的品质,在版本6-7时达到顶峰,然后就一路走上迷信微软的路(8.0曾经只支持.NET,不再支持原生;后来又加回来,一个编译语言,IDE却用Java来搞,用java来搞就算了,讽刺的是却又不能跨平台 -_-!),质量还越来越差,而Lazarus 的品质,却越来越好。

Delphi已死,后继者Lazarus!Write once,Compile anywhere!
如果你依然热爱 Pascal (现代化的),如果你怀念过去的Delphi的辉煌,那就拥抱Lazarus吧,无论你的平台是是Windows、Mac OS,还是Linux!
http://www.lazarus.freepascal.org/

软硬兼施 | 评论已关闭 | 8,300 次阅读
简短地址:http://ncblog.net/1032/
顺利切换到redis    @ 2011-07-09, 14:01

网站为提高响应速度,越来越依赖在内存中存放数据。之前使用memcached,但却发现了一些由memcached的内存分配机制以及LRU导致的问题(详见 http://ahuaxuan.iteye.com/blog/225692)——简单来说是这样的,我们发现,在memcached还没有用尽其内存时,它就开始踢那些“永不超时”的数据了。对于memcached的设计理念是作为缓存来说,这当然不算是问题,或者可以说是有意设计的,但对于我们的实际需求来说(“永不超时”的数据必须保持在内存中)是无法接受的了。毕竟,缓存是缓存,数据是数据。

于是上周着手寻找新的替代方案,后来确定了使用redis。

“Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作,是我知道的性能最快的Key-Value DB。”(http://www.iteye.com/topic/524977

相比memcached,Redis毕竟是以DB为设计目标的,因此功能强大很多(比如内存中的数据维护功能,memcached几乎为0),却非常小巧,编译安装也非常方便。

“和Memcached不同,Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev,但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。”(http://timyang.net/tag/redis/

redis支持很多客户端(http://redis.io/clients),我们使用的php(phpredis)和python(redis-py)当然都有,代码从memcached切换到redis几乎不用做改动,转移成本极小。

昨晚redis顺利部署到线上。切换后总结带来的好处如下:
1、当然是完成了切换到redis的初衷——保持web服务器内存中数据的完整性,避免类似memcached的LRU那样踢数据。
2、之前用memcached的时候,必须在线上用脚本将后台postgresql的关系数据“跑”进内存(memcached)里,这个步骤比较费时,在线上跑并不是很合适;现在用redis可以用线下服务器将关系数据跑进内存里,生成磁盘文件,再把该文件上传到线上服务器即可,线上服务器短时间就可以完成数据更新的切换(相当于把线下服务器的内存“拷贝”到了线上服务器的内存)。数据更新部署的流程简化多了。
3、不再担心重启memcached服务甚至重启服务器时,带来的内存中数据长时间空缺导致线上服务受到影响(见上一条“必须在线上用脚本将后台postgresql的关系数据“跑”进内存(memcached)里,这个步骤比较费时”),redis服务本身的维护也相当方便。

当然,基于切换的初衷,我们更多的还是把redis当作一个更合适的memcached来用,所以我们没有启用redis的VM特性(内存足够,性能是唯一要求)。redis更多强大功能,暂时还没有体会。

Redis官方网址:http://redis.io/

软硬兼施 | 4 个评论 | 13,357 次阅读
简短地址:http://ncblog.net/915/