如何避免linux上的系统标准C/C++库？

我安装了新版本的GCC,这对我的linux系统造成了污染.我计划以更好的方式处理多个版本的GCC.我计划在/ opt / tools目录下安装所有不同的版本.然后我的项目makefile显式指定要使用的版本.这包括所有二进制可执行文件,即...

我安装了新版本的GCC,这对我的linux系统造成了污染.我计划以更好的方式处理多个版本的GCC.我计划在/ opt / tools目录下安装所有不同的版本.然后我的项目makefile显式指定要使用的版本.这包括所有二进制可执行文件,即g,gcc等,以及头文件,库……

这种方法的好处很明显.构建更具可重复性.它不承担版本,而是选择非常具体的版本.在不同的编译器版本之间切换都发生在makefile中.

为了实现这一点,我使用“-nostdinc”并将所有include路径显式地放入我的编译命令行.我的代码包含limits.h,它会导致奇怪的构建错误.

limits.h是我的debian中安装的libc6-dev的一部分.但它不在gcc的include目录中.一些在线资料称标准C lib是OS的一部分.我的问题是,构建独立于系统头文件和库的代码是否实用？我怀疑gcc可能缺少其他标题.最初,我认为gcc带有一切.情况并非如此？

换句话说,系统库和头文件是否取决于debian发行版附带的特定GCC版本？我觉得系统头文件和库是GCC 4.7,而我使用的是GCC 5.3,这让我感到很不舒服.

解决方法:

在与程序编译相关的典型Linux /“free unix”系统中有几层.

>内核.用户级程序很少直接与内核交互,尽管它们可以.
>特定于内核的头文件,由内核模块使用并绑定到特定的Linux内核版本.在Debian中,这些头文件位于linux-headers-< kernel-version>中.可能有多个专用于相应内核版本的包.除非您的程序是内核模块或类似程序,否则您不需要它们.
> libc的内核特定部分.在Debian系统中,这包含在linux-libc-dev包中.通常这个包不是特定于特定的内核版本,而是特定于“版本的一代”(它发展缓慢并反映新内核用户级设施,常量等的外观).您确实需要此包来编译典型的复杂用户域程序,因为它包含重要的系统范围常量和类型定义
> libc.这个库提供了所有常用的“C库”函数,设施等,有时它包装相应的内核工具(想想open(),send(),brk()函数),有时它提供自己的高级功能(例如qsort( )实施).您确实需要库来构建几乎任何程序.在debian系统中,它有几个包,头文件在libc6-dev中.可能有多个不同的libc实例同时在单个Linux内核上运行(例如,在chroots中),但由于库依赖于某些文件层次结构,通常只有一个.
>编译器.编译器带有自己的头文件集,但是对于C编译器来说,编译器特定的头文件比例如C编译器要少得多,因为通常C编译器有自己的STL实现,这是一个头库通过语言设计. C编译器中的大多数这些.h头文件负责各种特定于编译器的技巧,如varargs处理(stdarg.h)或Cilk内容.例如,在Debian 7的gcc-4.7包中,只有47个.h文件,其中大多数是libgcc的一部分

实际上,在Debian中你可以安装任意数量的编译器,它们不会相互干扰.例如,现在在我的Ubuntu-16.04中,有4个gcc版本可立即安装：4.7.4,4.8.5,4.9.3,5.3.1,以及4个铿锵版本：3.5,3.6,3.7和3.8 .所有这些不同版本的编译器都可以使用apt-get install< package-name>进行安装.我想现代的Debian或多或少都有相同的设置.使用相对简单的规则,您可以为任何给定的编译器和任何给定的版本构建一个包.

在使用CC环境变量进行编译期间可以选择所需的C编译器,并且不需要为此更改Makefile.

只有在计划使用完全不同的libc实现时才需要-nostdinc,这通常不是这种情况.但有时它很有用,例如用于在没有“完整环境”的情况下为initrd或其他系统启动阶段构建程序.