Linux下dlclose函数在什么情况会产生core

　在Linux系统下编译link时出现了错误，提示“undefined reference’dlclose@xxx函数”错误，相信不少用户也遇到这个问题，这个问题不难解决，下面小编给大家介绍下undefined reference错误的解决方法。

编译完link的时候，报了一句undefined reference’dlclose@xxx函数‘，找主程过来看了下，说是dl库没有包进去，查了下dl库是用来做动态库加载的（dynamic load），项目用到了libmysqld.so，加了之后还是有问题，将-ldl链接选项改到最后才可以。

比较常见的undefined reference问题：

1.dl库

undefined reference to ‘dlerror’

undefined reference to ‘dlopen’

undefined reference to ‘dlerror’

增加-ldl链接选项 （-l是链接选项的前缀）

2.pthread库

undefined reference to ‘pthread_create’

undefined reference to ‘pthread_xxxx‘

增加-lpthread链接选项

3.rt库

undefined reference to `clock_gettime’

增加-lrt链接选项

如果是使用codeblocks，可以再link option里加，不过因为依赖顺序的问题，如果link option里加了还是报错，直接在link file里添加pthread dl rt等即可

如果是你自己的库出现这undefined reference什么函数，先去查下库的源代码，看看具体问题。

上面就是Linux编译link出错的解决方法介绍了，本文除了介绍link出错外，还总结了一些undefined reference问题，希望对你有所帮助。

从接触unix开始就一直听到和遇到core dump，特别是刚学着使用C语言在AIX下编写程序的时候，core dump更是时不时就会不请自来。记得当时刚写应用的时候，提交程序时最怕的就是在运行过程时遇到core dump，对于银行核心系统，特别是使用静态应用进程，如果一个相对频繁一点的交易导致core dump，那么毫无疑问，除了赶紧定位错误改程序外，重启进程甚至无法争取到多少缓冲的时间来进行代码的更正和测试。而且往往导致core dump的，就是程序中一个小小的未注意到或者未测试到的一个疏忽。

虽然常常遇到core dump，不过很长时间内，都是出于知道这个名字，知道它导致的后果，知道一部分导致它出现的原因，其他的就都不甚了了了。说起来，就是自己太懒了，懒得看书......少壮不努力啊。看过一则统计，说60岁以上的老人，超过70%都后悔少壮不努力，不知统计的数据能否反映整个社会的情况。不过总的来说，这句古话还是有些道理的。大家不要学我。哈哈

core dump，翻译过来讲，就是核心转储。大致上就是指，如果由于应用错误，如浮点异常、指令异常等， *** 作系统将会转入内核的异常处理，向对应的进程发送特定的信号（SIGNAL），如果进程中没有对这些信号进行处理，就会转入默认的处理，core dump就是其中的一种。如果进程core dump，系统将会终止该进程，同时系统会产生core文件，以供调试使用。这个core文件其实就是内存的映像，即进程执行的时候内存的内容，也就是所谓的core dump。平常大家说某某进程core dump了，其实主要的意思就是说：某某进程因为错误而被系统自动终止了。

AIX上提供了dbx工具可以对core dump进行调试，协助定位引起core dump的代码。最普通的语法是：

dbx 应用名 core文件， 然后使用where命令来显示调试信息

一般来讲，根据工作中遇到的情况，dbx还是能够比较轻松的根据提示的内容来定位代码的。不过也有一些特殊情况时，dbx显示的调试信息过于模糊或者不直观，这个时候就只能根据经验来逐步定位了。有时定位起来会耗用相当长的时间。遇到这种情况时，使用日志文件，通过在代码中穿插多个写log的语句，也可以协助发现。因为进程core dump时，日志当然也中断了，根据日志在哪个代码行之后或之前中止了，可以有效缩小寻找的范围。甚至，在有些情况下，使用日志定位是唯一简便的方法了。

---