分享未来 ^Internet _Technology

      今日捣鼓cubieboard开发板，打算通过netbeans远程开发主机模式将linux c/c++远程编译在arm板上。以前笔者用的是Netbeans 7的版本，是可以完美运行编译环境的，但是今日升级到8.0.2版本后就无法配置C++构建主机了，填写好IP和账号密码怎么也没法识别到开发板上的gcc环境,提示为None()。查阅Netbeans官方的bugzilla记录（https://netbeans.org/bugzilla/show_bug.cgi?id=245243），发现也有好多人反馈和笔者一样的问题，在arm开发板上无法配置构建主机。于是逐篇翻阅反馈记录发现了一些解决问题的方法，估记录下来。

netbeans在配置远程主机的时候会在远程linux的/var/tmp目录下创建一个和ssh连接的账号名相关的目录，比如我用root连接主机，那么会创建dlight_root名字的目录。进入这个目录会发现在其子目录下会创建一个pty的二进制文件，我们用ldd的方式去跟踪这个二进制可执行文件所调用的so时会发现：

其调用的libc动态链接库路径为/lib/arm-linux-gnueabi/libc.so.6。

       我们可以看到这里的so放在arm-linux-gnueabi的目录下，这个目录是什么含义呢？查阅资料可知这个目录存放的是arm体系中的armel浮点运算单元模式，而如果我们的远程主机系统中没有此so文件，那么pty这个可执行文件就无法正常运行，也就会导致我们的构建主机配置失败，导致怎么都无法识别到我们的gnu开发环境，同时我们配置samba的映射目录也是会失败的。因此当我们的Netbeans C++构建主机配置失败的时候我们首先去远端确认pty文件是否能正常执行。

        找到了原因就好办了，我的cubieboard开发板默认只安装了armhf浮点运算的libc库，没安装armel版本的，故导致pty文件运行的失败。执行

[code="bash"]
apt-get install libc6:armel
[/code] 

命令即解决问题。

文件描述符集合的区别：

 在poll中描述符集合是一个struct pollfd结构类型的数组，用于存放需要检测其状态的Socket描述符；每当调用这个函数之后，系统不会清空这个数组，操作起来比较方便；特别是对于socket连接比较多的情况下，在一定程度上可以提高处理的效率；这一点与select()函数不同，调用select()函数之后，select()函数会清空它所检测的socket描述符集合，导致每次调用select()之前都必须把socket描述符重新加入到待检测的集合中；因此，select()函数适合于只检测一个socket描述符的情况，而poll()函数适合于大量socket描述符的情况。

 

文件描述符特性的区别：

poll() 函数不会受到socket描述符上的O_NDELAY标记和O_NONBLOCK标记的影响和制约，也就是说，不管socket是阻塞的还是非阻塞的，poll()函数都不会收到影响；而select()函数则不同，select()函数会受到O_NDELAY标记和O_NONBLOCK标记的影响，如果socket是阻塞的socket，则调用select()跟不调用select()时的效果是一样的，socket仍然是阻塞式TCP通讯，相反，如果socket是非阻塞的socket，那么调用select()时就可以实现非阻塞式TCP通讯；

两者移植性的区别：

poll() 函数的功能和返回值的含义与 select() 函数的功能和返回值的含义是完全一样的，两者之间的差别就是内部实现方式不一样，select()函数基本上可以在所有支持文件描述符操作的系统平台上运行(如：Linux 、Unix 、Windows、MacOS等)，可移植性好，而poll()函数则只有个别的的操作系统提供支持(如：SunOS、Solaris、AIX、HP提供支持，但是Linux不提供支持)，可移植性差；

 

今日在封装一个类时遇到execvp的传参个数问题，execvp允许传入两个参数，第一个参数是执行的文件路径（可以是命令名也可以是文件绝对路径名），第二个参数包括执行的命令以及命令参数构造的一个二维数组，我用stl的string来构造第二个参数的时候申明了一个char*的一维字符指针，通过string的const_cast方式构造一个参数列表，但是发现执行的execvp老是失败，strace的时候发现构造的数组在传入的时候会多了一项，在学习c/c++的时候标准说过数组的维数+1都是合法的，故在最后一项后的一项也一并传入了execvp。 例如我申明了一个char *arr[5]，实际上arr[5] 这一项也会传入，故我们需要在赋值的时候对这一项申明arr[5]='\0' ，从而避免这一项污染执行的命令。

今天将log4cplus引入自己的程序，由于log4cplus需要线程库的支持，在静态编译的时候加上了-lpthread,但是始终在编译的时候提示找不到线程函数：

[code="plain"]
liblog4cplus.a(socketappender.o): In function `log4cplus::thread::PthreadMutexAttr::set_type(log4cplus::thread::Mutex::Type)':
../include/log4cplus/helpers/syncprims-pthreads.h:80: undefined reference to `pthread_mutexattr_settype'
liblog4cplus.a(socketappender.o): In function `~PthreadMutexAttr':
../include/log4cplus/helpers/syncprims-pthreads.h:58: undefined reference to `pthread_mutexattr_destroy'
liblog4cplus.a(socketappender.o): In function `ManualResetEvent':
../include/log4cplus/helpers/syncprims-pthreads.h:200: undefined reference to `pthread_cond_init'
liblog4cplus.a(socketappender.o): In function `~PthreadMutexAttr':
../include/log4cplus/helpers/syncprims-pthreads.h:58: undefined reference to `pthread_mutexattr_destroy'
liblog4cplus.a(socketappender.o): In function `~ManualResetEvent':
../include/log4cplus/helpers/syncprims-pthreads.h:210: undefined reference to `pthread_cond_destroy'
../include/log4cplus/helpers/syncprims-pthreads.h:210: undefined reference to `pthread_cond_destroy'
liblog4cplus.a(socketappender.o): In function `log4cplus::thread::ManualResetEvent::timed_wait(unsigned long) const':
../include/log4cplus/helpers/syncprims-pthreads.h:272: undefined reference to `pthread_cond_timedwait'
[/code]

于是搜索发现必须在编译的时候加上"-pthread" 才能正常编译通过。

附上g++中-pthread和-lpthread的区别说明文章：

http://blog.chinaunix.net/uid-25909722-id-3026989.html

http://chaoslawful.iteye.com/blog/568602

http://kasicass.blog.163.com/blog/static/395619200992410313759/