題記：如題
目錄：
爲何要自己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引擎的渲染正常了，整個世界都和諧了！
