为什么MGC的glic和gcc不愿意跟随版本的更新？
其实红旗和EVL的GCC3运行库版本比MGC的要低，GCC是GCC4.1，GCC4目前稳定版本是4.2。对于编译器gcc和glibc的选择，到底是处于什么样的考虑？为什么MGC2.1仍然基于GCC3进行编译呢？以GCC4的版本发展速度的确无法让人适应，发行版本也不可能频繁更换底层的东西。随着Linux的发展，硬件支持的改善，国外大型商业软件的支持（特别是firefox）、文泉驿开源字体的发展，大家也看到了linux的共享软件悄然增多，这和98年win国产共享软件壮大有着很多相似的地方。对于安全，该如何去做一个准备工作呢。一个是包的管理，随着共享软件增多，系统类库和软件依赖类库该如何划分，如何保证系统类库的安全？如何保证软件源的安全，如何取代rpm包来安装软件？（个人以为rpm很不安全）
有不少Linux共享软件作者正在努力，当然他们属于淘金类型的(非gnu)，因此源码基本是锁源的。目前几款共享软件都只闻其声不见其面，比较大的原因可能是MGC2.1还没有发布过beta以上的版本吧，他们所惯用的系统的glibc gcc版本都比较高，给出的二进制程序不能用于MGC2.1。
[ 本帖最后由 haulm 于 2007-11-1 23:40 编辑 ] 如果迁移到gcc4的话，所有底层的包要不要重新编译？补丁要重写吗？如果要，我赞成gcc3。毕竟，再折腾的话，magic2.1就要等到奥运会了！
现在觉得opensuse10.3很舒服，犹豫如果2.1出了，要不要回来。不过看样子一两个月内不用考虑这个问题了:wink: opensuse感觉速度很慢。 2.1 铁板钉钉使用GCC3，beta版本发布也不远了。至于疑问只是问大家所想的，呵呵。
2.1 的界面大家也有所了解了，应该不负所望吧。 关于这两个关键软件包目前为什么不升级，我不想再多谈，我们不是没有升级过，这些以前陆续已经提到，核心问题就两个字：“兼容”，这也是 magic 改善易用性的重要一环。当然，这里面考虑的因素很多，我们也是结合用户现实情况才这样做的，有些不便在这里说，希望大家深入思考，理解不要停留在字面上。我想 sejishikong、kanker 和我都能给你详尽的解释。
的确国内的开源软件不多，大环境恶劣是一方面，开发者自身的处境、需求、观念则起了决定作用。大多数共享软件我们可以找到不错的替代品，共享软件在 linux 世界里不是主流。至少目前缺少这些东西，不会对 magic 造成什么伤害，我们不怕。相信 magic 的易用性和群众基础最终会吸引相当一批开发者在 magic 下面重新打包他们的作品。 一方面是为更好的兼容性，另一面因为gcc3够用了。 支持用GCC3，GCC4会带来很大的麻烦，编译过程要是因为编译器引起没法通过对于一半用户来说是灾难，应为GCC4带来的语法过于严格编译不通过，一半用户根本没法解决。 to haulm:
我觉得你可以自己把gcc4 .x的包打好上转啊。
就像debian的sid一样
我发现gcc有三个版本gcc3.x gcc4.1 gcc4.2
好像还有gcc2.9.x,内核还是gcc4.1的产品，其它东西现在几乎都是gcc4.2的产品了
多个版本共存很好啊。有段时间我就把gcc4.1和4.2都安装了也没有问题。 rpm可以加入数字签名来保证安全 gcc4下面很多软件编译时都十分痛苦啊 原帖由 guazi111 于 2007-11-7 09:40 发表 http://www.linuxfans.org/bbs/images/common/back.gif
gcc4下面很多软件编译时都十分痛苦啊
现在已经很少了。 其实，从 gcc3 开始，gcc 的版本开始与编译出来后的程序无关了。真正导致不能运行的原因是 lib 的问题，这个问题可以部分借助程序的静态编译方式解决。这个编译会导致程序体型增大，但兼容性增强。
如果动态库方式编译，只能针对某一个特定的版本，就连系统的软件包升级，都可能导致程序出问题。
用 Gentoo 的人，都知道这个痛苦。不然 gentoo 就不会有一个 revdep-rebuild 了。
页:
[1]