已解决:最后的链结失败: 错误的值
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,只不过由于以前很多代码都有这种习惯,为了兼容,就保留下来了。