升级到ubuntu 14.04遇到的问题

Posted on 2014年9月20日 15:57

本来用着12.04打算一直用到不能用为止,但前两天看ubuntu touch发布新版,想升级以下ubuntu SDK看看(之前第一次发布的SDK bug成堆,根本没法用)。新版的SDK只支持14.04,所以干脆升级一下好了。然后果然遇到问题,都跟输入法有关。

1. ibus无法关闭

只能切换输入法状态到英文来输入英文,不能关闭输入法。无奈卸载ibus,改用fcitx。

更新:这纯粹是unity的bug,换用其他桌面环境问题消失。

 

2.切换输入法快捷键有问题

在fcitx的配置中设置快捷键时,如果先按Ctrl,则后面不管按什么都被识别为Ctrl + LCtrl。多试几次发现必须先按Space再按Ctrl才能设置成Ctrl + Space。

不过设置成Ctrl + Space也不管用,最后发现必须把 系统设置-文本输入 中的快捷键设置成别的(换成fcitx之前修改过这里)。

这个地方猜想unity和ibus作了继承,切换输入法的快捷键被拦截下来,没有发给应用程序(或者fcitx,不清楚快捷键的流程)。这方法只考虑了ibus,而ibus还不好使,这LTS版真心不靠谱。

 

3. 系统设置中大部分选项丢失

本来没必要删除ibus,之前我在12.04下就是fcitx和ibus都安装了,只启动一个就好。但14.04却把两个都启动了。不想找麻烦,于是干脆删除ibus,结果因为依赖关系把unity-control-center给删了。

 

解决方法很简单:sudo apt-get install unity-control-center

不过不上网搜还真不知道为什么突然系统设置变得空空如也。

有人贴了这个bug的链接:https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1294482

一开始以为是ibus依赖ubuntu-control-center,结果是反过来的。到系统里一看,ibus果然又在那里了。。。

 

C/C++运算符优先级补记

Posted on 2013年9月20日 15:31

虽然是非常基础的知识,但还是重新总结一下,免得哪天掉坑里。

优先级的列表就不再贴了,wikipedia上总结的很好了。但是若仔细搜索一下,会发现能找到多个不同的版本,显然有些是错的。

下面是需要注意的点:

1.前置自增/自减和后置自增自减的优先级是不同的,有人给出的优先级列表就犯了这种错误。后置自增自减的优先级更高。

2.位运算的&  ^  |三者优先级不同,且都低于比较运算符。逻辑运算符&&比||优先级高,这几点很坑,为了防止混淆,用的时候最好加括号。

3.逗号运算符的优先级最低,除去::(反正它基本不会产生混淆),[] . ->的优先级位于第一梯队。

 

[其他]ThunderBird的恼人特性:自动转换文本附件的换行

Posted on 2013年3月12日 14:58

一直使用ThunderBird收发邮件,昨天突然发现ThunderBird的一个奇葩特性:自动转换文本附件的换行方式为windows下的\r\n。

 

继续阅读

[ARM]在PandaBoard OMAP4上安装ubuntu 12.10 for arm

Posted on 2012年10月28日 15:51

    从12.10开始,ubuntu for arm的镜像不再是预安装的版本,而是标准的liveCD,因此安装方法也与之前不同。下面是我安装时的简要过程。

 

继续阅读

[ARM]ARM平台处理器简介-ARMv7

Posted on 2012年9月27日 20:24

    初次接触到ARM的时候,我直接被众多的处理器版本、系列搞晕了,查了好多资料才理清。现在在这里总结一下,希望能帮到别人。

 

继续阅读

[Lua]Lua的posix模块

Posted on 2012年5月06日 00:03

luaposix是一个lua的POSIX库,其中也包括了curses库的实现。这个项目托管在github上:https://github.com/rrthomas/luaposix

 

继续阅读

[Linux]Ubuntu的ld不搜索/usr/lib/x86_64-linux-gnu的问题

Posted on 2012年3月23日 22:03

今天在ubuntu(for AMD64)下编译gcc-4.6.3时遇到如下错误:

/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: ld 返回 1

继续阅读

[Unix]编译定制一个可移动的Vim

Posted on 2012年1月07日 21:33

    Mint 12源里面的Vim并不支持lua脚本扩展,于是就想自己编译一个。如果能编译成可以移动的就更好了,这样使用不同机器的时候只需要scp一个目录就可以了。

    下载了Vim 7.3的源码包准备编译,首先就发现不能外部构建,必须要在源代码目录下configure,因为源代码根目录下的configure文件是这样写的:

cd src && exec ./configure "$@"

然后研究了一下可用的选项,最后使用的选项如下:

./configure --prefix=/opt/vim73/ --with-features=huge --disable-darwin \
--disable-selinux --enable-luainterp=yes  --enable-cscope --enable-xim \
--enable-gui=gtk2 --without-local-dir --with-vim-name=pvim --with-ex-name=pex \
--with-view-name=pview

不过这些选项里并没有指明使用的vimrc以及其他.vim文件的路径,如此编译安装后,使用的的vimrc应该还是和系统自带的Vim是一样的。我希望编译出的Vim使用它安装目录下的vimrc。不过configure脚本似乎没有选项可以指明这个。

 

    细想一下,默认的vimrc的路径有可能是在代码中指定的,于是用grep搜索代码,发现src/feature.h这个文件甚是可以,打开一看发现这个文件就是预留用来自定义某些配置的。关于vimrc主要有一下几个宏:

/* #define VIMRC_FILE   ".vimrc" */
/* #define GVIMRC_FILE  ".gvimrc" */

/* #define USR_VIMRC_FILE       "~/foo/.vimrc" */
/* #define USR_VIMRC_FILE2      "~/bar/.vimrc" */
/* #define USR_VIMRC_FILE3      "$VIM/.vimrc" */

/* #define USR_GVIMRC_FILE      "~/foo/.gvimrc" */
/* #define USR_GVIMRC_FILE2     "~/bar/.gvimrc" */
/* #define USR_GVIMRC_FILE3     "$VIM/.gvimrc" */

/* #define SYS_VIMRC_FILE       "/etc/vimrc" */
/* #define SYS_GVIMRC_FILE      "/etc/gvimrc" */

和上面贴的一样,在src/feature.h中这些宏都是注释掉的。这其中主要起作用的宏有:

USR_VIMRC_FILE
SYS_VIMRC_FILE
USR_GVIMRC_FILE
SYS_GVIMRC_FILE

添加这几个宏的定义,使得vimrc的路径依赖于VIMRUNTIME变量。然后make && make install。

 

    看起来似乎大功告成,但这时我发现只要将安装好的Vim移动到别的路径,Vim就找不到各种配置文件了。看来VIMRUNTIME的预设值也是在编译时确定的。google了一下这个变量,发现如果在Vim执行前用export设置这个变量的值到正确的路径,那么Vim仍然能够找到vimrc等配置文件。

 

    这样依赖就有两种方法来解决:

1.用shell脚本wrap一下Vim的可执行文件。

2.修改Vim源文件,在main函数刚开始的地方用setenv设置这个环境变量。

    考虑了一下决定采用第二种方法,结果发现在程序中获取可执行文件的路径竟然相当麻烦(上一篇博客讲了这个问题)。不过毕竟我的环境基本是Linux,于是写了一个Linux Only的patch,哪天需要在新环境使用再改吧。

diff --git a/src/main.c b/src/main.c
index 435e607..cf3a0fc 100644
--- a/src/main.c
+++ b/src/main.c
@@ -174,6 +174,29 @@ main
 #endif
 
     /*
+     * Set $VIMRUNTIME.
+     */
+#ifdef UNIX
+    char exe_path_buff[512];
+    char *exe_path_ptr;
+    ssize_t exe_path_len = 
+        readlink("/proc/self/exe", exe_path_buff, sizeof(exe_path_buff));
+    if(exe_path_len > 0)
+    {
+        exe_path_buff[exe_path_len] = 0;
+        exe_path_ptr = exe_path_buff + exe_path_len;
+        while(exe_path_ptr != exe_path_buff && *exe_path_ptr != '/')
+            exe_path_ptr --;
+        *exe_path_ptr = 0;
+        while(exe_path_ptr != exe_path_buff && *exe_path_ptr != '/')
+            exe_path_ptr --;
+        *exe_path_ptr = 0;
+        strcat(exe_path_buff, "/share/vim/vim73/");
+        setenv("VIMRUNTIME", exe_path_buff, 0);
+    }
+#endif
+
+    /*
      * Do any system-specific initialisations.  These can NOT use IObuff or
      * NameBuff.  Thus emsg2() cannot be called!
      */

[Unix]在程序中取得当前程序可执行文件的路径

Posted on 2012年1月07日 02:44

  出乎意料,这个貌似简单的问题麻烦的紧,在Unix下没有通用且简单的方法解决。stackoverflow上有人问了这个问题:

http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

简单但平台相关的方法(stackoverflow上的回答):

  • Mac OS X: _NSGetExecutablePath() (man 3 dyld)
  • Linux: readlink /proc/self/exe
  • Solaris: getexecname()
  • FreeBSD: sysctl CTL_KERN KERN_PROC KERN_PROC_PATHNAME -1
  • BSD with procfs: readlink /proc/curproc/file
  • Windows: GetModuleFileName() with hModule = NULL
下面有人补充了一个FreeBSD的另一个方法:readlink /proc/curproc/file

HP的一个页面上有一个通用的方法:
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=88086d6e1de021106d6e1de02110275d6e10RCRD
程序挺长,方法是根据argv[0]来判断是由绝对/相对路径执行的当前程序还是通过$PATH的方式执行的。对于后一种执行方式,通过在$PATH中依次查找的方式找到具体的路径。

想来想去,我也没想到更好的方法。对于上面那个通用的方法,到$PATH中查找的过程可以改为通过popen调用which的方式简化一些。

PS:有意思的是,搜索的时候发现不管是中文页面还是英文页面,都有不少语文不好的同学建议使用getcwd()...

.eh_frame的一些资料

Posted on 2011年10月12日 16:26

http://www.x86-64.org/pipermail/discuss/2004-September/005114.html

  这封邮件中提到CIE pointer在“当前”版本的gcc中实现为当前地址和CIE起始地址的差。

 

http://www.x86-64.org/pipermail/discuss/2004-August/005017.html

  这封邮件后面的附件中描述的eh_frame的格式。

附件的地址:

http://www.x86-64.org/pipermail/discuss/attachments/20040816/914f9b7c/attachment.txt

 

http://www.airs.com/blog/archives/460

  这篇文章描述了eh_frame的一些相关信息。其中提到gcc处理异常的时候会生成eh_frame。推测eh_frame完全是依赖编译器的实现,因此dwarf规范没提到这东西。

 

根据前面的几篇文章中的信息,可以确定在eh_frame中,CIE_id的值应该是0。现在不确定debug_frame中CIE_id是否和此不同。但根据实际测试,debug_frame中的通常是-1。

 

http://www.airs.com/blog/archives/166

  GCC Exception Frame,也就是eh_frame。这里提到eh_frame是dwarf调试信息的变体(variant)