2019年已过去 22.03%
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,053 次阅读
简短地址:http://ncblog.net/1483/
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 代码了。

我用软件 | 评论已关闭 | 915 次阅读
简短地址:http://ncblog.net/1416/
GitLab(社区版)    @ 2016-07-23, 17:51

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

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

我用软件 | 评论已关闭 | 3,434 次阅读
简短地址:http://ncblog.net/1227/
phpRedisAdmin    @ 2013-08-01, 09:14

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

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

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

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

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

我用软件 | 3 个评论 | 11,702 次阅读
简短地址: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,789 次阅读
简短地址: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,241 次阅读
简短地址: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,277 次阅读
简短地址:http://ncblog.net/915/
解决Chrome经常狂读硬盘僵在那里    @ 2011-06-08, 12:57

Chrome/Chromium毫无疑问是速度最快的主流浏览器。不过,时常遇到其狂读硬盘僵在那里的情况,感觉有点诡异。
google一下发现了解决方法:
将“高级选项”中的“启用针对网上诱骗和恶意软件的防护功能”功能关闭即可。

我用软件 | 评论已关闭 | 8,342 次阅读
简短地址:http://ncblog.net/901/
恶心的腾讯微博    @ 2011-05-30, 14:10

虽然很隐蔽,但终于还是被我发现了。

在腾讯微博,你成功发出的微博,follow你的人未必能看到,而且始终搞不清楚G点在哪里?!!你要觉得触到G点了,就明说不准发,搞这种下三滥小儿科。太幼稚。

其实,微博是媒体属性远远大于社交娱乐属性的产品。腾讯根本没有媒体基因,而只有社交娱乐基因。凡是和社交娱乐有关的产品,腾讯做一个就成功一个(很多赴美上市的公司号称自己是中国的facebook,但其实真正意义上的中国的facebook,有且只有腾讯。而除社交娱乐以外的领域,腾讯几无收获。有个说法,70%的记者,只有新浪微博,剩下的,是两个微博都有。

新浪的基因,就是媒体,所以名人博客也好,微博也好,必成。

谁会在微博上,整天关注某个朋友现在是在上班,还是上床,还是上厕所?

我用软件 | 评论已关闭 | 7,103 次阅读
简短地址:http://ncblog.net/897/