C++博客-wooohahttp://www.cppblog.com/woooha/zh-cnMon, 06 Apr 2026 00:11:25 GMTMon, 06 Apr 2026 00:11:25 GMT60Mesa安装手记--在Ubuntu 9.10http://www.cppblog.com/woooha/archive/2010/03/08/109156.html杨帆杨帆Sun, 07 Mar 2010 16:36:00 GMThttp://www.cppblog.com/woooha/archive/2010/03/08/109156.htmlhttp://www.cppblog.com/woooha/comments/109156.htmlhttp://www.cppblog.com/woooha/archive/2010/03/08/109156.html#Feedback5http://www.cppblog.com/woooha/comments/commentRss/109156.htmlhttp://www.cppblog.com/woooha/services/trackbacks/109156.html

    学计算机图形学用到OpenGL，不过想在Ubuntu下进行实现，查查了查，OpenGL 在linux下的C绑定是Mesa，可是安装这玩意儿可是费了我一番功夫。

    首先，从www.Mesa3D.org下载了三个文件，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。解压后的得到一个文件夹Mesa-X.Y.Z。

    在bash中进入这个文件夹中，执行./configure进行配置，额，少了一些库。

    首先是libdrm，在软件包管理器中，找到了libdrm-dev，安装后，再次执行./configure。

    还是少库。

    少了dri2proto。

    查了查，找到了x11proto-dri2-dev,安装后执行./configure

    少库。

    少了xxf86vm。

    在软件包中找到libxxf86vm-dev安装后，额，不抱希望了，执行./configure。

    …………少库。

    这次是xt。

    找了找，在软件包中找到了libxt-dev，安装后。./configure。

    成功了！提示我make。

    哈哈，真高兴！可是make就出问题了,提示我少了fdepend这个东西。

    可是我怎么都找不到这个东西在哪里。

    很郁闷。

    继续上www.Mesa3D.org看看官方的说明，上面说安装Mesa需要４个东西。

  1. dri2proto version 1.99.3 or later

  2. Linux 2.6.28

  3. libDRM version 2.4.3 or later

  4. Xorg server version 1.5 or later

    前三个，我都有安阿？第四个是什么东西，继续在软件包管理器中捣鼓。找到了xorg-dev这个安装。再次make,竟然成功了！好吧，make install，也成功了。

    然后接下来，验证Mesa能不能用。

    转到Mesa-X.Y.Z/progs/demos目录下，执行./gears，提示找不到libglut.so.3(好像是这个，记不大清了)，看看Mesa3D上让执行这么几个命令。

  1. cd lib/ （转到了Mesa-X.Y.Z/lib/目录下)

  2. export LD_LIBRARY_PATH=${PWD}

  3. export LIBGL_DRIVERS_PATH=${PWD} (if using DRI drivers)

    现在再执行Mesa-X.Y.Z/progs/demos/gears可以运行了，看到了齿轮在转动！

    可是在Mesa-X.Y.Z/progs/samples/编译一个文件

             gcc `pkg-config opengl --cflags --libs ` point.c -o point

    出现了好多错误。

    额，怎么回事？

    才知道，编译文件是找不到glut库，仔细一看才发现，自己编译文件用的命令错了，应该是

                gcc `pkg-config glut --cflags --libs ` point.c -o point

    好了，现在一切没有问题了，安装成功！




杨帆 2010-03-08 00:36 发表评论
]]>在不同系统下分配大内存的测试（c.c.l.c上一人的帖子，在老家网吧不方便实验，记下啦，试试）http://www.cppblog.com/woooha/archive/2010/02/18/108034.html杨帆杨帆Thu, 18 Feb 2010 12:01:00 GMThttp://www.cppblog.com/woooha/archive/2010/02/18/108034.htmlhttp://www.cppblog.com/woooha/comments/108034.htmlhttp://www.cppblog.com/woooha/archive/2010/02/18/108034.html#Feedback0http://www.cppblog.com/woooha/comments/commentRss/108034.htmlhttp://www.cppblog.com/woooha/services/trackbacks/108034.html
测试代码如下：
#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个，开到第6个的时候，malloc就返回-1了。可是，可是，令人惊奇的是
这个时候，我无论是用vmstat还是用mdb看，我都还有大量的空闲的物理内存
>::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
这与我开这几个程序之前，没有明显的变化。（相比而下，在windows下，这个时 候系统已经卡的快嗝屁了）

然后我用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


系统的确给这个进程分配了地址空间（看它的heap有多大），但是压根儿就没有给 它分配物理内存。我想不出的是，它依据什么来拒绝新的申请。
由于环境有限，我没有找到良好的环境在freebsd下重复这个实验。我在 freebsd.unix-center.net上做这个测试，但是把每个进程分配的内存缩小到64M, 然后开了100个这样的进程，据估计至少需要6G的内存，malloc一直都是成功的， 我的手酸了，懒得弄了。


最有趣的在于这个：
#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去看，事实证明，free函数根本就没有释放物理内存。free是把malloc 得到的物理内存还给了自己进程，而不是还给了操作系统。
在这一点上，freebsd是有差别的。执行完free之后，rss明显降了下来





杨帆 2010-02-18 20:01 发表评论
]]>