使用SecureCrt觉得最不爽的问题一个是颜色,一个是显示宽度。颜色的问题在这篇文章 linux开发环境配置 已经解决了,今天仔细研究一下,发现原来显示宽度也是可以修改的,如下图
在option->Global options里面,修改 Maximum columns的值就可以了。原来只有132,显示文本太长的话就会自动换行,现在改成200,基本上都可以显示完全了。
PS:修改完这两个选项后,SecureCRT和xshell一样好用了。
2014年4月22日星期二
2014年4月2日星期三
source insight 不能解析namespace关键字的问题
如果在项目里使用了namespace关键字,并且其他文件使用了namespace里面的函数,则在source insight里面看这些函数都是黑色的。解决办法:source insight 解析 namespace
具体设置如下:
具体设置如下:
勾选“Ignore namespace declaration”选项即可
2014年3月26日星期三
gcc (g++) 编译时只链接静态库
为啥编译时要只链接静态库呢?链接动态库时,编译后的程序需要目标机器安装对应的动态库。链接静态库就不存在这个问题了。而且有时候链接的动态库还依赖于其他动态库,只要有一个版本不对就抓虾了。
今天就碰到这样的一个问题:我们的程序使用了google protocol buffers库,在开发机器上(suse 10)安装了pb库,编译正常,程序运行也正常。但是在测试机器上就有问题了。首先在测试机器上安装了pb库,安装顺利,运行pb库的make check也显示所有测试通过。但是运行时提示: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.10' not found (required by /usr/lib64/libprotobuf.so.8),然后我把开发机器上的 libstdc++.so.6 拷贝过来,还是不行。这就抓瞎了(后来发现了错误,libstdc++.so.6只是一个软链接,链接到libstdc++.so.6.0.8这个文件的。所以我只是拷贝了一个软链接!)
当时时间比较急,所以就把程序重新用pb的静态库文件编译了。这里大概总结一下链接只链接静态库的方法。
1.gcc (g++) 编译选项里面 -l 选项是默认先链接动态库的,所以我一开始用 -lprotobuf 选项链接的都是 libprotobuf.so.8 这个库。
2.要只链接静态库 libprotobuf.a 这个文件的话,可以直接写死静态库路径(相当与把静态库当作.o文件来使用),比如:g++ /usr/local/lib/libprotobuf.a -o myserver,或者用 g++ -o myserver /usr/local/lib/libprotobuf.a 也可以。同时把原来的-lprotobuf选项去掉,这样就可以了。最后链接完成后,用ldd myserver就可以看到程序里面已经没有pb的动态库了。
3.可以把libprotobuf.a文件拷贝到makefile的搜索路径里面。比如我的搜索路径设置为当前的./lib目录,然后就把libprotobuf.a拷贝到这个目录里面。(这个方法其实还是有问题的,有时候链接的还是动态库)
4.最好的办法:使用-Wl,-Bstatic选项。在要链接的库文件前加入这个选项,可以强制链接静态库。比如我的makefile最后就写成这个样子:
-Wl,-Bstatic -lprotobuf -Wl,-Bdynamic -lgcc_s
-Wl,-Bstatic -lprotobuf 即强制链接libprotobuf.a
-Wl,-Bdynamic -lgcc_s 这个是因为需要gcc_s的动态库,所以在前面加了一个使用动态库的选项。
5.-static选项:这个选项是全局的,一旦用了就要求全部链接静态库。
今天就碰到这样的一个问题:我们的程序使用了google protocol buffers库,在开发机器上(suse 10)安装了pb库,编译正常,程序运行也正常。但是在测试机器上就有问题了。首先在测试机器上安装了pb库,安装顺利,运行pb库的make check也显示所有测试通过。但是运行时提示: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.10' not found (required by /usr/lib64/libprotobuf.so.8),然后我把开发机器上的 libstdc++.so.6 拷贝过来,还是不行。这就抓瞎了(后来发现了错误,libstdc++.so.6只是一个软链接,链接到libstdc++.so.6.0.8这个文件的。所以我只是拷贝了一个软链接!)
当时时间比较急,所以就把程序重新用pb的静态库文件编译了。这里大概总结一下链接只链接静态库的方法。
1.gcc (g++) 编译选项里面 -l 选项是默认先链接动态库的,所以我一开始用 -lprotobuf 选项链接的都是 libprotobuf.so.8 这个库。
2.要只链接静态库 libprotobuf.a 这个文件的话,可以直接写死静态库路径(相当与把静态库当作.o文件来使用),比如:g++ /usr/local/lib/libprotobuf.a -o myserver,或者用 g++ -o myserver /usr/local/lib/libprotobuf.a 也可以。同时把原来的-lprotobuf选项去掉,这样就可以了。最后链接完成后,用ldd myserver就可以看到程序里面已经没有pb的动态库了。
3.
4.最好的办法:使用-Wl,-Bstatic选项。在要链接的库文件前加入这个选项,可以强制链接静态库。比如我的makefile最后就写成这个样子:
-Wl,-Bstatic -lprotobuf -Wl,-Bdynamic -lgcc_s
-Wl,-Bstatic -lprotobuf 即强制链接libprotobuf.a
-Wl,-Bdynamic -lgcc_s 这个是因为需要gcc_s的动态库,所以在前面加了一个使用动态库的选项。
5.-static选项:这个选项是全局的,一旦用了就要求全部链接静态库。
2014年3月5日星期三
linux 开发环境配置
一.命令配置(alias)。
用l,“..” ,“...”命令习惯了,换到新机器的时候没这几个命令还不习惯,所以这样来设置:root用户,先执行cd,进入到用户目录,然后vi .bashrc,加入
alias l='ls -al'
alias ..='cd ..'
alias ...='cd ../..'
这三条,这样就ok了。
二.颜色设置
如果用Xshell的话,那就很方便了,颜色配置很好,基本不用改。
如果用securCrt的话,默认情况下用蓝色显示文件夹,基本上看不清楚,必须修改,方法如下:
1.设置终端类型为linux,勾选ansi color,不选 Use color scheme(如果选了,则在终端-外观-颜色 里面选中的方案就会生效,这里面的颜色方案个人不太喜欢).
2.在SecureCrt全局选项里面修改颜色,在这里才能把文件夹的蓝色修改掉,修改Bold colors里面的蓝色,Normal colors不变。如图:
这样修改后,SecurCrt的颜色就好看多了
用l,“..” ,“...”命令习惯了,换到新机器的时候没这几个命令还不习惯,所以这样来设置:root用户,先执行cd,进入到用户目录,然后vi .bashrc,加入
alias l='ls -al'
alias ..='cd ..'
alias ...='cd ../..'
这三条,这样就ok了。
二.颜色设置
如果用Xshell的话,那就很方便了,颜色配置很好,基本不用改。
如果用securCrt的话,默认情况下用蓝色显示文件夹,基本上看不清楚,必须修改,方法如下:
1.设置终端类型为linux,勾选ansi color,不选 Use color scheme(如果选了,则在终端-外观-颜色 里面选中的方案就会生效,这里面的颜色方案个人不太喜欢).
![]() |
| 终端颜色设置 |
这样修改后,SecurCrt的颜色就好看多了
2014年1月24日星期五
strstk_r 分隔符之坑
今天发现一个问题,用strstk_r来分割字符串,发现结果不是想象的那样。原因是分割符参数是多个字符,而strstk_r是把分割符看成一个集合,只要匹配集合里面的任何一个元素就会进行分割。用了才知道坑啊。
socket编程手记
1.同一socket连着两次connect会发生什么?
第一次connect成功后,第二次connect会提示 EISCONN,/* Transport endpoint is already connected */,即该socket已经连接上了。
2.客户端connect成功后退出,server端收到什么
客户端connect成功后退出,发送一个fin到server端,server端调用recv返回空数据
linux 手册里面的:If no messages are available to be received and the peer has performed an orderly shutdown,recv() shall return 0
客户端退出后,往server端发送了一个fin:
14:07:10.118038 IP client.49032 > server.30010: F 1:1(0) ack 1 win 64 <nop,nop,timestamp 1558633984 1558633984>
14:07:10.119100 IP server 30010 > client 49032: . ack 2 win 64 <nop,nop,timestamp 1558633985 1558633984>
这时tcp连接处于半关闭状态.协议栈还是等待server端发出关闭信息。
server端退出后(或者主动close),tcpdump可以看到server端的确认关闭的信息:
14:21:20.802625 IP server.30010 >client.49032: F 1:1(0) ack 2 win 64 <nop,nop,timestamp 1558846656 1558633984>
14:21:20.802628 IP client.49032 > server.30010: R 1502573033:1502573033(0) win 0
3.listen socket设置成为非阻塞,accept后的connected socket还是非阻塞吗?
第一次connect成功后,第二次connect会提示 EISCONN,/* Transport endpoint is already connected */,即该socket已经连接上了。
2.客户端connect成功后退出,server端收到什么
客户端connect成功后退出,发送一个fin到server端,server端调用recv返回空数据
linux 手册里面的:If no messages are available to be received and the peer has performed an orderly shutdown,recv() shall return 0
客户端退出后,往server端发送了一个fin:
14:07:10.118038 IP client.49032 > server.30010: F 1:1(0) ack 1 win 64 <nop,nop,timestamp 1558633984 1558633984>
14:07:10.119100 IP server 30010 > client 49032: . ack 2 win 64 <nop,nop,timestamp 1558633985 1558633984>
这时tcp连接处于半关闭状态.协议栈还是等待server端发出关闭信息。
server端退出后(或者主动close),tcpdump可以看到server端的确认关闭的信息:
14:21:20.802625 IP server.30010 >client.49032: F 1:1(0) ack 2 win 64 <nop,nop,timestamp 1558846656 1558633984>
14:21:20.802628 IP client.49032 > server.30010: R 1502573033:1502573033(0) win 0
3.listen socket设置成为非阻塞,accept后的connected socket还是非阻塞吗?
int s1 = socket();s1设置成为非阻塞,在s1上面listen,有连接建立后,accept后得到的是一个新的socket(s2),这个socket默认是阻塞的。所以accept后,在s2上面recv数据是阻塞的。
2014年1月21日星期二
开发日记
这篇主要记录工作中碰到的一些问题,特别是奇怪的问题。
1.‘ucontext_t’ was not declared in this scope
先说一下开发环境:通过samba使用远程机器进行开发,代码都放在远程目录下面,然后用sourceinsight写代码。
这个问题真是神奇,原来编译得好好的代码,突然就编译不过,然后提示如上。然后我加上 #include <sys/ucontext.h> ,不行,换成#include <ucontext.h> 还是不行。然后仔细的想今天做过什么改动,终于想起来了,因为在sourceinsight里面没有include 系统头文件,所以我就拷贝一份系统头文件到工作目录,结果makefile就包含了这个目录,导致编译出错。
解决办法很简单,就是把工作目录下的系统头文件删掉就可以了。
1.‘ucontext_t’ was not declared in this scope
先说一下开发环境:通过samba使用远程机器进行开发,代码都放在远程目录下面,然后用sourceinsight写代码。
这个问题真是神奇,原来编译得好好的代码,突然就编译不过,然后提示如上。然后我加上 #include <sys/ucontext.h> ,不行,换成#include <ucontext.h> 还是不行。然后仔细的想今天做过什么改动,终于想起来了,因为在sourceinsight里面没有include 系统头文件,所以我就拷贝一份系统头文件到工作目录,结果makefile就包含了这个目录,导致编译出错。
解决办法很简单,就是把工作目录下的系统头文件删掉就可以了。
订阅:
博文 (Atom)





