也就是说extern有两个作用,第一个,当它与"C"一起连用时,如: extern “C” void fun(int a, int b);则告诉编译器在编译fun这个函数名时按着C的规则去翻译相应的函数名而不是C++的,C++的规则在翻译这个函数名时会把fun这个名字变得面目 全非,可能是fun@aBc_int_int#%$也可能是别的,这要看编译器的"脾气"了(不同的编译器采用的方法不一样),为什么这么做呢,因为 C++支持函数的重载啊,在这里不去过多的论述这个问题,如果你有兴趣可以去网上搜索,相信你可以得到满意的解释!
第二,当extern不与"C"在一起修饰变量或函数时,如在头文件中: extern int g_Int; 它的作用就是声明函数或全局变量的作用范围的关键字,其声明的函数和变量可以在本模块活其他模块中使用,记住它是一个声明不是定义!也就是 说B模块(编译单元)要是引用模块(编译单元)A中定义的全局变量或函数时,它只要包含A模块的头文件即可,在编译阶段,模块B虽然找不到该函数或变量, 但它不会报错,它会在连接时从模块A生成的目标代码中找到此函数。
具体现象表现为使用SecureCRT登陆时,出现如下出错提示:
Public-key authentication with the server for user sw failed. Please verify username and public/private key pair.
查看服务器日志,找不到有用的相关记录。
之后直接在另一台机器上使用ssh连接,打开verbose模式(ssh -vvv),如下:
123
...
debug1: Next authentication method: password
sw@xxx.xxx.xxx.xxx's password:
求助万能的Google,发现serverfault上有一个案例的现象和出错信息与我遇到几乎一样,提问者怀疑是SELinux导致的。
案例 见 http://www.linuxidc.com/Linux/2013-07/87267p2.htm
下面的回复证实了确实是SELinux的问题,并且给出了解决方案:
Yes, SELinux is likely the cause. The .ssh dir is probably mislabeled. Look at /var/log/audit/audit.log. It should be labeled ssh_home_t. Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.
Yep, SELinux was the cause: type=AVC msg=audit(1318597097.413:5447): avc:denied { read } for pid=19849 comm=“sshd” name=“authorized_keys” dev=dm-0 ino=262398 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
It works after running “restorecon -r -vv /root/.ssh”. Thanks a lot.