遇到的debug整理20190107

已解决：最后的链结失败: 错误的值

RT0.o: relocation R_X86_64_PC32 against symbol \`phgTetFaceVertexi\' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 最后的链结失败: 错误的值
collect2: error: ld returned 1 exit status

运行如下代码，查看返回情况。

ldd test
linux-vdso.so.1 =>  (0x00007fff0fd95000)
libsofile.so => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f937b5de000)
/lib64/ld-linux-x86-64.so.2 (0x0000563f7028c000)

如上代码输出发现，确实是找不到对应的.so文件。
这是由于linux自身系统设定的相应的设置的原因，即其只在/lib and /usr/lib下搜索对应的.so文件，故需将对应so文件拷贝到对应路径。

sudo cp libsofile.so /usr/lib

再次执行./test，即可成功运行。

已解决：ubuntu init.c:(.text+0x30)：对‘main’未定义的引用

网上大部分资料都是说因为Makefile中源码部分，应该将含有main函数的源程序名字放在第一个，不然找不到入口，总的来说就是因为main入口不对。总结一下，造成这个错误的原因有如下：

main拼写错误
主函数中没有main函数
makefile中源程序放置顺序应该是含有main函数的在前面
makefile中源程序没有加后缀名

已解决： Makefile:xxx: recipe for target xxx failed

原因：原来是linux下面的那些命令，比如iconv，mv等，执行结果的，如果是没有错误的，会返回0，表示正常的，而此处hhc是windows下面的工具，其返回1表示执行结果正常，导致了makefile收到1，以为是程序执行错了呢，所以报错。
解答：设置合适的返回值，例如C语言，主函数设置返回值为0.

已解决：问题：Python文件运行时报TabError: inconsistent use of tabs and spaces in indentation

原因：说明Python文件中混有Tab和Space用作格式缩进。这通常是使用外部编辑器编辑Python文件时，自动采用Tab进行格式缩进。
解决：将Tab转换成4个Space（通常）或者用Python编辑器（如pyDev）格式化。

已解决：关于发邮件报错535 Error：authentication failed解决方法

调用163邮箱服务器来发送邮件,我们需要开启POP3/SMTP服务,这时163邮件会让我们设置客户端授权码，这个授权码替代上面代码部分的passwd即可成功发送邮件。

已解决：/bin/sh^M：损坏的解释器: 没有那个文件或目录

脚本文件保存时使用了DOS格式，用DOS2UNIX转为UNIX格式，也可以用vim打开，用:set ff=unix转换。

不要在 Windows下编辑脚本文件，否则经常会遇到这种问题。
解决：可以用 vim 打开文件，然后执行冒号命令：

vim
:set ff=unix
:wq

已解决：warning: initialization makes pointer from integer without a cast [-Wint-conversion]

解决：检查指针有没有错误赋值，这个警告会造成段错误。

已解决： recipe for target ‘TestFuncPointer’ failed

makefile:20: recipe for target 'TestFuncPointer' failed
make: *** [TestFuncPointer] Error 1

原来是linux下面的那些命令，比如iconv，mv等，执行结果的，如果是没有错误的，会返回0，表示正常的，而此处hhc是windows下面的工具，其返回1表示执行结果正常，导致了makefile收到1，以为是程序执行错了呢，所以报错.

已解决:xerbla.f:(.text+0x69): undefined reference to '_gfortran_st_write`

xerbla.f:(.text+0x69): undefined reference to '_gfortran_st_write'
xerbla.f:(.text+0x7d): undefined reference to '_gfortran_transfer_character'
xerbla.f:(.text+0x91): undefined reference to '_gfortran_transfer_integer'
xerbla.f:(.text+0x99): undefined reference to '_gfortran_st_write_done'
xerbla.f:(.text+0xa5): undefined reference to '_gfortran_stop_numeric'
collect2: ld returned 1 exit status

解决这个错误的方法就是在链接库的时候加 -lgfortran

已解决 warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]

const char* str= "some string";

如果是长字符串加上const!

已解决:“undefined reference to” 问题汇总及解决方法

参考"undefined reference to" 问题汇总及解决方法
在链接命令中给出所依赖的库时，需要注意库之间的依赖顺序，依赖其他库的库一定要放到被依赖库的前面，这样才能真正避免undefined reference的错误，完成编译链接。

已解决：warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings

在C++11中有明确规定

char* p = "abc"; // valid in C, invalid in C++

如果你进行了这样的赋值，那么编译器就会跳出诸如标题的警告。但是如果你改成下面这样就会通过warning

char* p = (char*)"abc"; //OK
char const *p="abc";//OK

这到底是怎么一回事呢？事实上，我们在学习c或者c++的时候都知道，如果在赋值操作的时候，等号两边的变量类型不一样，那么编译器会进行一种叫做 implicit conversion 的操作来使得变量可以被赋值。

在我们上面的表达式中就存在这样的一个问题，等号右边的"abc"是一个不变常量，在c++中叫做string literal，type是const char *，而p则是一个char指针。如果强行赋值会发生什么呢？没错，就是将右边的常量强制类型转换成一个指针，结果就是我们在修改一个const常量。编译运行的结果会因编译器和操作系统共同决定，有的编译器会通过，有的会抛异常，就算过了也可能因为操作系统的敏感性而被杀掉。

像这种直接将string literal 赋值给指针的操作被开发者们认为是deprecated，只不过由于以前很多代码都有这种习惯，为了兼容，就保留下来了。