學(xué)計(jì)算機(jī)圖形學(xué)用到OpenGL，不過想在Ubuntu下進(jìn)行實(shí)現(xiàn)，查查了查，OpenGL 在linux下的C綁定是Mesa，可是安裝這玩意兒可是費(fèi)了我一番功夫。
首先，從www.Mesa3D.org下載了三個(gè)文件，MesaDemos-X.Y.Z.tar.gz , MesaGLUT-X.Y.Z.tar.gz,MesaLib-X.Y.Z.tar.gz,分別是Demo，GLUT庫和最主要的Mesa（OpenGL）鏈接文件。這里X.Y.Z是Mesa的版本，我下載的是7.6.1。解壓后的得到一個(gè)文件夾Mesa-X.Y.Z。
在bash中進(jìn)入這個(gè)文件夾中，執(zhí)行./configure進(jìn)行配置，額，少了一些庫。
首先是libdrm，在軟件包管理器中，找到了libdrm-dev，安裝后，再次執(zhí)行./configure。
還是少庫。
少了dri2proto。
查了查，找到了x11proto-dri2-dev,安裝后執(zhí)行./configure
少庫。
少了xxf86vm。
在軟件包中找到libxxf86vm-dev安裝后，額，不抱希望了，執(zhí)行./configure。
…………少庫。
這次是xt。
找了找，在軟件包中找到了libxt-dev，安裝后。./configure。
成功了！提示我make。
哈哈，真高興！可是make就出問題了,提示我少了fdepend這個(gè)東西。
可是我怎么都找不到這個(gè)東西在哪里。
很郁悶。
繼續(xù)上www.Mesa3D.org看看官方的說明，上面說安裝Mesa需要４個(gè)東西。
-
dri2proto version 1.99.3 or later
-
Linux 2.6.28
-
libDRM version 2.4.3 or later
-
Xorg server version 1.5 or later
前三個(gè)，我都有安阿？第四個(gè)是什么東西，繼續(xù)在軟件包管理器中搗鼓。找到了xorg-dev這個(gè)安裝。再次make,竟然成功了！好吧，make install，也成功了。
然后接下來，驗(yàn)證Mesa能不能用。
轉(zhuǎn)到Mesa-X.Y.Z/progs/demos目錄下，執(zhí)行./gears，提示找不到libglut.so.3(好像是這個(gè)，記不大清了)，看看Mesa3D上讓執(zhí)行這么幾個(gè)命令。
-
cd lib/ （轉(zhuǎn)到了Mesa-X.Y.Z/lib/目錄下)
-
export LD_LIBRARY_PATH=${PWD}
-
export LIBGL_DRIVERS_PATH=${PWD} (if using DRI drivers)
現(xiàn)在再執(zhí)行Mesa-X.Y.Z/progs/demos/gears可以運(yùn)行了，看到了齒輪在轉(zhuǎn)動(dòng)！
可是在Mesa-X.Y.Z/progs/samples/編譯一個(gè)文件
gcc `pkg-config opengl --cflags --libs ` point.c -o point
出現(xiàn)了好多錯(cuò)誤。
額，怎么回事？
才知道，編譯文件是找不到glut庫，仔細(xì)一看才發(fā)現(xiàn)，自己編譯文件用的命令錯(cuò)了，應(yīng)該是
gcc `pkg-config glut --cflags --libs ` point.c -o point
好了，現(xiàn)在一切沒有問題了，安裝成功！
測試代碼如下：
#include <stdlib.h>
#include <unistd.h>
int main(){
void* p=malloc(512*1024*1024);
if(p==NULL) return -1;
sleep(10000000);
return 0;
}
然后我用g++ 4.3.2編譯
g++-4.3.2 -o testm testm.c
開了5個(gè)，開到第6個(gè)的時(shí)候，malloc就返回-1了。可是，可是，令人驚奇的是
這個(gè)時(shí)候，我無論是用vmstat還是用mdb看，我都還有大量的空閑的物理內(nèi)存
>::memstat
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 144849 565 14%
ZFS File Data 62043 242 6%
Anon 146323 571 14%
Exec and libs 3640 14 0%
Page cache 34357 134 3%
Free (cachelist) 35896 140 3%
Free (freelist) 600734 2346 58%
Total 1027842 4015
Physical 1027841 4015
這與我開這幾個(gè)程序之前，沒有明顯的變化。（相比而下，在windows下，這個(gè)時(shí) 候系統(tǒng)已經(jīng)卡的快嗝屁了）
然后我用ps來看
# ps -eo pid,vsz,rss,args |grep testm
1298 527292 1356 ./testm
1309 4224 1256 grep testm
1300 527292 1356 ./testm
1302 527292 1356 ./testm
1296 527292 1356 ./testm
1304 527292 1356 ./testm
# pmap 1296
1296: ./testm
08046000 8K rwx-- [ stack ]
08050000 4K r-x-- /tmp/testm
08060000 8K rwx-- /tmp/testm
08062000 524296K rwx-- [ heap ]
FEB70000 320K r-x-- /lib/libm.so.2
FEBCF000 8K rwx-- /lib/libm.so.2
FECD0000 24K rwx-- [ anon ]
FECE0000 1280K r-x-- /usr/lib/libc/libc_hwcap1.so.1
FEE20000 28K rwx-- /usr/lib/libc/libc_hwcap1.so.1
FEE27000 8K rwx-- /usr/lib/libc/libc_hwcap1.so.1
FEE30000 52K r-x-- /usr/lib/libgcc_s.so.1
FEE4C000 4K rwx-- /usr/lib/libgcc_s.so.1
FEE50000 4K rwx-- [ anon ]
FEE60000 856K r-x-- /usr/lib/libstdc++.so.6.0.10
FEF45000 160K rwx-- /usr/lib/libstdc++.so.6.0.10
FEF6D000 24K rwx-- /usr/lib/libstdc++.so.6.0.10
FEF80000 4K r--s- /var/ld/ld.config
FEF90000 4K rwx-- [ anon ]
FEFA0000 4K rw--- [ anon ]
FEFB0000 4K rw--- [ anon ]
FEFBE000 180K r-x-- /lib/ld.so.1
FEFFB000 8K rwx-- /lib/ld.so.1
FEFFD000 4K rwx-- /lib/ld.so.1
total 527292K
系統(tǒng)的確給這個(gè)進(jìn)程分配了地址空間（看它的heap有多大），但是壓根兒就沒有給 它分配物理內(nèi)存。我想不出的是，它依據(jù)什么來拒絕新的申請(qǐng)。
由于環(huán)境有限，我沒有找到良好的環(huán)境在freebsd下重復(fù)這個(gè)實(shí)驗(yàn)。我在 freebsd.unix-center.net上做這個(gè)測試，但是把每個(gè)進(jìn)程分配的內(nèi)存縮小到64M, 然后開了100個(gè)這樣的進(jìn)程，據(jù)估計(jì)至少需要6G的內(nèi)存，malloc一直都是成功的， 我的手酸了，懶得弄了。
最有趣的在于這個(gè)：
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
int main(){
void* p=malloc(512*1024*1024);
if(p==NULL) return -1;
memset(p,0,512*1024*1024);
free(p);
sleep(10000000);
return 0;
}
用ps/pmap去看，事實(shí)證明，free函數(shù)根本就沒有釋放物理內(nèi)存。free是把malloc 得到的物理內(nèi)存還給了自己進(jìn)程，而不是還給了操作系統(tǒng)。
在這一點(diǎn)上，freebsd是有差別的。執(zhí)行完free之后，rss明顯降了下來