[求助]glibc2.7编译不通过，大家帮忙看看哈，已经折腾了一天了，没有解决，只好上来求助了。

pinkme005

反正我觉得直接修改源码里面的include路径没有什么问题，我的GLIBC-2.7现在用得好好的，暂时还没有发现有什么编译，运行异常的

pjincz

^_^ 3ks 那我继续折腾了，不过现在感觉上班了时间都不是自己的了哈。
我发现自己老倒霉了，嘿嘿，今天编译boost又没编译过去

d00m3d

boost 我吃过很大的亏，结果最後还是等到 boost 出新版 1.35 才搞定

http://www.linuxsir.cn/bbs/thread320391.html

今天最新版是 1.36 但未玩过，也不太算玩了

ppluer

今天给同事装battery life tool kit 发现ubuntu连libdev X11lib都没有装
总要apt-get回来一番
建议楼主换livecd做宿主 少去很多烦恼

d00m3d

吾用 Debian unstable 做 host，同样无往而不利，CLFS-SVN 都行 ：）

pjincz

折腾了半宿，还是没有搞定boost1.36，连1.33都没搞定哈。
最后还是拿qt4写了程序，汗。qt4 linux下倒是无所谓 win下好大的dll的说。。。。

pjincz

10月31 boost马上要出1.37了，好汗的说一句，发行密度怎么越来越高啊。
1.33->1.34 22个月
1.34->1.35 10个月
1.35->1.36 5个月
1.36->1.37 2个月？？？？

d00m3d

兄弟可否说说 boost 其实有何用途，谢谢。

pjincz

boost的库还是很不错的哈。毕竟号称C++备用标准库哈。
我那个程序主要是用到多线程，恩恩，为了可移植么，呵呵。
所以哈就是pthread boost 还有qt4三选一哈（其他库我不会哈）
其实最理想的是boost，依赖比较小，可移植和健壮性最大。qt4实在太庞大了。
事实证明boost库不是一般的强悍哈，今天我用stl和boost把代码重构了。
重构前我的程序中某个函数peek时间是0.109微秒，分析得知主要瓶颈在qt4的tss（线程附加数据）库哈。
重构完后竟然反而上升到了0.334微秒，汗一个，分析了一下，发现stl的hash_map竟然占据了93.7%的时间，我晕。
干掉stl的hash_map换成qt4的QHash，时间下降到了0.051微秒，Happy啊。
boost的线程库可见强悍啊，Qt4的QHash速度也不是徒有虚名哈，不过stl倒是让我伤心了老一阵子哈。

ppluer

Post by pjincz;1899817
boost的库还是很不错的哈。毕竟号称C++备用标准库哈。
我那个程序主要是用到多线程，恩恩，为了可移植么，呵呵。
所以哈就是pthread boost 还有qt4三选一哈（其他库我不会哈）
其实最理想的是boost，依赖比较小，可移植和健壮性最大。qt4实在太庞大了。
事实证明boost库不是一般的强悍哈，今天我用stl和boost把代码重构了。
重构前我的程序中某个函数peek时间是0.109微秒，分析得知主要瓶颈在qt4的tss（线程附加数据）库哈。
重构完后竟然反而上升到了0.334微秒，汗一个，分析了一下，发现stl的hash_map竟然占据了93.7%的时间，我晕。
干掉stl的hash_map换成qt4的QHash，时间下降到了0.051微秒，Happy啊。
boost的线程库可见强悍啊，Qt4的QHash速度也不是徒有虚名哈，不过stl倒是让我伤心了老一阵子哈。

原来LZ是达人 呵呵