我安裝了新版本的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或其他系統啟動階段構建程序.

標簽：c-3,c,linux,gcc

來源： https://codeday.me/bug/20190724/1525072.html

總結

以上是生活随笔為你收集整理的linux编译避免污染源码分离,如何避免linux上的系统标准C/C++库？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。