编译scull源码时出现的一些问题及解决方法。
编译环境：CentOS 6.3（kernel version 2.6.32）
编译错误：
make -C /lib/modules/2.6.32-279.14.1.el6.i686/build M=/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull LDDINC=/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/../include modules
make[1]: Entering directory `/usr/src/kernels/2.6.32-279.14.1.el6.i686'
scripts/Makefile.build:49: *** CFLAGS was changed in "/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/Makefile". Fix it to use EXTRA_CFLAGS. Stop.
make[1]: *** [_module_/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.32-279.14.1.el6.i686'
make: *** [modules] Error 2
解决方案：
CFLAGS与Makefile.build中的CFLAGS冲突，错误提示要求将CFLAG换成EXTRA_CFLAGS重新编译即可；
编译错误：
error: linux/config.h: No such file or directory
解决方案：
从linux-2.6.20起，config.h就已经被移除了.
将#include <linux/config.h>修改成如下——>
#include <linux/version.h>
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18))
#include <linux/config.h>
#endif
编译错误：
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c: In function ‘scull_p_read’:
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:131: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:131: error: (Each undeclared identifier is reported only once
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:131: error: for each function it appears in.)
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:131: error: implicit declaration of function ‘signal_pending’
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:131: error: implicit declaration of function ‘schedule’
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c: In function ‘scull_getwritespace’:
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:168: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c: In function ‘scull_p_write’:
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:219: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:223: error: ‘SIGIO’ undeclared (first use in this function)
/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.c:223: error: ‘POLL_IN’ undeclared (first use in this function)
make[2]: *** [/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull/pipe.o] Error 1
make[1]: *** [_module_/mnt/HappyStudy/MyDesigner/Linux/LDD3/examples/scull] Error 2
解决方案：
实验四十 Windows Server 2012 RDS桌面虚拟化之十一RemoteApp应用程序分组和用户分配
在Windows Server 2012中可以对RemoteApp应用程序进行按组分类，方便程序管理，而且可以对RemoteApp应用程序进行用户分配，只有指定的用户或组才可以访问相应的RemoteApp程序
说明：环境基于实验三十九
1 接着上节实验，登录RemoteApp服务器把“计算器“添加为RemoteApp程序发布出来
2在Remote App服务器上编辑Remoteapp程序的属性，指定程序所属的文件夹的组，然后通过RDweb访问测试分组效果
3登录Remote App服务器编辑Remoteapp程序的属性，指定用户VD1可以访问Adobe Reader程序，用户VD2可以访问”计算器”程序，然后通过RDweb访问测试用户分配效果
安装过程视频分享：http://pan.baidu.com/share/link?shareid=578580&uk=1025659618
静态库，是在可执行程序连接时就已经加入到执行码中，在物理上成为执行程序的一部分；使用静态库编译的程序运行时无需该库文件支持，哪里都可以用，但是生成的可执行文件较大。动态库，是在可执行程序启动时加载到执行程序中，可以被多个可执行程序共享使用。使用动态库编译生成的程序相对较小，但运行时需要库文件支持，如果机器里没有这些库文件就不能运行。
2． 如何使用动态库
如何程序在连接时使用了共享库，就必须在运行的时候能够找到共享库的位置。linux的可执行程序在执行的时候默认是先搜索/lib和/usr/lib这两个目录，然后按照/etc/ld.so.conf里面的配置搜索绝对路径。同时，Linux也提供了环境变量LD_LIBRARY_PATH供用户选择使用，用户可以通过设定它来查找除默认路径之外的其他路径，如查找/work/lib路径,你可以在/etc/rc.d/rc.local或其他系统启动后即可执行到的脚本添加如下语句：LD_LIBRARY_PATH =/work/lib:$(LD_LIBRARY_PATH)。并且LD_LIBRARY_PATH路径优先于系统默认路径之前查找（详细参考《使用LD_LIBRARY_PATH》）。
不过LD_LIBRARY_PATH的设定作用是全局的，过多的使用可能会影响到其他应用程序的运行，所以多用在调试。（LD_LIBRARY_PATH的缺陷和使用准则，可以参考《Why LD_LIBRARY_PATH is bad》 ）。通常情况下推荐还是使用gcc的-R或-rpath选项来在编译时就指定库的查找路径，并且该库的路径信息保存在可执行文件中，运行时它会直接到该路径查找库，避免了使用LD_LIBRARY_PATH环境变量查找。
3．库的链接时路径和运行时路径
现代连接器在处理动态库时将链接时路径（Link-time path）和运行时路径（Run-time path）分开,用户可以通过-L指定连接时库的路径，通过-R（或-rpath）指定程序运行时库的路径，大大提高了库应用的灵活性。比如我们做嵌入式移植时#arm-linux-gcc $(CFLAGS) –o target –L/work/lib/zlib/ -llibz-1.2.3 (work/lib/zlib下是交叉编译好的zlib库)，将target编译好后我们只要把zlib库拷贝到开发板的系统默认路径下即可。或者通过-rpath（或-R ）、LD_LIBRARY_PATH指定查找路径。
小问题：
1．编译时的-L选项是否影响LD_LIBRARY_PATH的值？
举一个实例：
当前文件夹结构如下：
test.c tools/
tool下有tool.c tool.h my_err.h 以及由此生成的libtool.so
tool下编译生成库文件
gcc -Wall -g -shared -o tool.so tool.c
在当前文件夹引用：
gcc -Wall -g –o test.c -Ltools -ltool
编译不报错，但是运行加载的时候就出现cannot open shared object file。
如果将该库文件拷贝到/usr/lib下就没有错误，正常运行。
说明编译时的-L选项并不影响环境变量LD_LIBRARY_PATH，-L只是指定了程序编译连接时库的路径，并不影响程序执行时库的路径，系统还是会到默认路径下查找该程序所需要的库。