题记：如题
目录：
为何要自己make libgl
当年学习opengl时，觉得自己系统里面的opengl版本有点低。。。然后就下载了linux下用Mesa
编译之后，make install到了自己的系统中。
Linux安装应用，对于大部分普通用户，都只要用对应的包管理器安装就可以了。ubuntu下的apt-get，CentOS下的yum，都十分简便好用。
但对于一些对软件版本要求比较高的情况，例如我想要安装的软件，源里面只有一个老版本，这时，往往会考虑编译安装。
编译安装的弊端
无论是在什么系统下，编译安装其实都是最简单的安装方式，也是开发者开发的方式，将开发环境搭建起来，利用编译指令，将项目构建好，这个过程就是make。但很多情况下，linux软件还会附带一个make install的功能。你需要这样跑：
make
sudo make install于是，这个库会被安装到一个他默认推荐的路径下。
linux软件的相互协作往往是一种契约的方式，A软件假若想用B软件，那么A软件就去B软件的安装目录找一找，或者去他越定的配置文件的存放地点，读取对应的配置文件。
这种工作方式有自己的优势，那就是简化了配置，每款软件的安装路径如果是固定的，那么这个路径存在，软件就存在，不用去向windows下查找注册表了。
然而，也是一种非常不安全的做法。
现在我就面临了这个尴尬，我编译了mesa库，熟悉linux的用户应该都有所了解，mesa版本的opengl库是常用的底层绘图库，桌面GUI基本上全是由这个库渲染的，这个库一旦出问题，轻则显示出问题，重则整机瘫痪，进不去GUI界面。
第一次显示异常
刚刚make install后，一切正常，我觉得还挺高兴，用上了新版的opengl，然而没高效多久，一次系统更新，完全打乱了之前的平静。
桌面上所有窗口的标题栏突然都不见了！
我根本不知道发生了什么。
于是我开始检查系统错误。
这里介绍一下我自己检查系统异常的经验。
linux系统有个比较大的毛病，就是他出现问题了，不是弹个对话框给你显示出来，而是很坑人的什么也不说，就告诉你出错啦，但是出什么错，对不起，自己检查log去吧。
于是对linux系统的查错，首要就是查log，在/var/log/目录下
一般系统底层的异常，可以查看系统log：syslog文件
cat /var/log/syslog | grep EEgrep EE的作用是，筛选出有EE标识的行，linux系统错误，经常用WW表示该行log是Waring，EE是Error
同理，经常需要查看的还有faillog和lastlog
显示系统的log一般就是X Window的log，查看Xorg.0.log等log文件。
特别的，对于ubuntu，桌面GUI服务是叫lightdm
例如，我们重启桌面GUI，只需要在Ctrl+Alt+F1的环境下输入：
sudo lightdm restart然后再按Ctrl+Alt+F7切换回GUI界面就可以了。
有时，显示问题，也需要查看lightdm文件夹下的log
另外，lightdm文件夹下的log读取居然还要root权限，不知是何原因。
通过查log发现，一个so库报错了，位置在这里：
/usr/lib/x86_64-linux-gnu/dri看的dri这个文件夹，我想起了些什么，Mesa库安装好后的目录是/usr/local/lib，文件夹里面也放了个dri目录。
我想应该是系统升级后，用了我的Mesa库，但是更新了libgl1-mesa-dri这个包，于是两者版本冲突，于是我从apt-get中禁止更新了这个包，并且用Mesa库带的dri文件夹替换了原来系统中的dri目录，然后系统就恢复了。
然而没问题仅仅是一种假象
虽然系统修复了，但还是会出一些问题，但我都没有想到是这个库的问题。就在昨天，我再次尝试安装nvidia显卡驱动时，发现了这个问题。
按照网上ubuntu官方教程，安装了nvidia-346驱动，并且装好了nvidia-settings这个工具包，开始双显卡切换，然而，一旦切换到了nvidia显卡下，桌面就进不去了。
我继续查看log，发现说的很晦涩，一个nvidia驱动中的so库报了错，这错误上哪找去！你要是开源的还好办，你一个闭源的so库报错，让人怎么查。
然后我查看了nvidia驱动的一些资料，偶然间发现，这个驱动好像也要求合适版本的libgl1-mesa-dri，OMG，原来也是这个东西搞得鬼。
于是我决定将自己编译的mesa完全移除我的系统。
重装了libgl1-mesa-dri这个库，再安装驱动，哦，天啊，一遍就成功了。
nvidia驱动装好后
nvidia的GTX850M显卡正常工作了，CUDA能用了，linux版文明5跑起来了，虚幻4引擎的渲染正常了，整个世界都和谐了！
