基于Linux的glibc
我目前使用的是 ubuntu 9.10 和 glibc 版本 2.11.1-0， 好吧，我正在做一个项目，我想用 glibc 的另一个版本（2.5-58）进行测试，我想知道以下与此相关的事情：
如何编译 2.5-58 的版本，但保留以前的版本？
如何将现有程序与新版本 glibc 的二进制文件链接？
如果有人能帮助我，我将不胜感激！
谢谢
I am currently using ubuntu 9.10 with the glibc version 2.11.1-0,
well i am doing a project, that i want to test with the another version of glibc that is 2.5-58, i wanted to know following things regarding this:
How to compile the version of 2.5-58, however keeping the previous version?
How to link the existing programs with the binaries of newer version of glibc?
I would be highly obliged if anybody can help me!!!
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果你想手动编译另一个版本的glibc，那么我建议你使用
--prefix选项配置（./configurescript run）它不安装到/lib， /usr/lib 但到 /home/mehul/glibc2.5.58test/lib 和 /home/mehul/glibc2.5.58test/usr/lib但是编译 glibc 并不是一件容易的事，所以另一种方法是获取 glibc 2.5- 58 以编译形式从其他 linux 中下载并手动将其复制到某个子目录。然后你可以覆盖 gcc 的库搜索路径并使用子目录中的 libc 重新编译你的库。
或者您可以使用 LD_LIBRARY_PATH 覆盖已编译二进制文件的库搜索路径以使用较旧的 glibc，如下所示：
If you want to manually compile another version of glibc, then I suggest you configuring (
./configurescript run) it with--prefixoption to install not to /lib, /usr/lib but to /home/mehul/glibc2.5.58test/lib and /home/mehul/glibc2.5.58test/usr/libBut compiling of glibc is not very easy thing, so another way is to get glibc 2.5-58 in compiled form from other linux and manually copy it to some subdirectory. Then you can override library search path of gcc and recompile your lib with libc from subdirectory.
Or you can use
LD_LIBRARY_PATHto override library search path of compiled binary to use older glibc like this:如果您知道旧发行版中使用了该版本的 libc，则可以将该发行版安装在 chroot/scratchbox/kvm/qemu/livecd 或其他此类系统中以进行测试和构建。或者可能还有其他构建农场类型的解决方案。然后您将拥有一个可以测试的真实系统，该系统不会弄乱您的最新系统。如果您保留该系统映像，它也将是可重复的。
如果这不是关于特定的旧版本，那么您究竟为什么要针对特定的非常旧的 libc 进行测试？
If you know that that version of libc is used in an older ditribution, you could install that distribution in a chroot/scratchbox/kvm/qemu/livecd or other such system for testing and building. Or there may be some other build farm type solution. Then you'll have an authentic system to test on that will not mess up your up to date one. It'll also be repeatable if you keep that system image.
If this isn't about a specific older release, why on earth would you want to test against a specific very old libc?