nod*_*kai 7 c++ linux gdb gnu-toolchain binutils
请参阅标签部分.
这个决定背后的理由是什么？合并是否会影响构建最新binutils和GDB的建议方式？(事实上当我检查binutils-2_25_1并跑步时make all && make install,我也得到了gdb.)
Tom*_*mey 15
我做了转换.我将它们作为连接存储库的原因部分是历史的,部分是实用的.
从历史上看,gdb和binutils几乎总是在一起.当它们被保持在天鹅座内时,它们在一个单一的源树(称为"devo")中.然后,稍后,当sourceware.org建立时,他们共享一个存储库(称为"src").您可能没有注意到这一点,因为存储库使用CVS模块让开发人员只检查树的一部分.
实际上,gdb和binutils共享很多代码.他们分享他们的构建基础设施(configure等); 他们共享支持库(libiberty和include)目录; 他们共享BFD库; 他们共享操作码库.对我而言,将它们保持在一起更有意义,既避免了来回不断的合并(这已经为GCC的一些组件做了,这是一个真正的痛苦),并且还试图最大限度地减少一个项目的变化带来负面影响的问题影响对方.例如,至少在理论上,在BFD上进行常规开发的人应该构建gdb 和 binutils.
configure共享存储库使用的顶级脚本允许开发人员使用禁用任何特定目录--disable-DIR.例如,如果您不想构建gdb,请传递--disable-gdb.