• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            runsisi

              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              45 隨筆 :: 15 文章 :: 26 評論 :: 0 Trackbacks

            盡管是老生常談,但是在比較之前,還是先明確一下什么叫做工具鏈。

            LFS/CLFS工具鏈是一套用于從C/C++源代碼生成可執行文件的軟件組件適當地組合在一起形成的系統。它包括4大部分,缺一不可:

            1、一套頭文件,包含了這些源代碼所需要訪問的系統接口。

            2、binutils,包含一些處理二進制可執行文件所需的工具,如匯編器、連接器等等。

            3、gcc,包含了編譯C/C++源代碼所需的工具,并且還能自動調用相關的binutils工具來完成生成源代碼的工具

            4、glibc,包含了系統接口的具體實現。

            在上面的定義中,請注意這些軟件必須適當地組合,才能形成完整的工具鏈。那么怎么才算適當組合呢?當然,這個工具鏈必須能夠發揮作用,也就是確實能夠編譯出目標代碼,然后才能算適當組合。

            那么,一個適當組合的工具鏈應當具有什么特點呢?一般我們把工具鏈運行的機器稱為host,所產生的代碼稱為target。那么對于工具鏈的要求便是:它必須要能在host上運行,所產生的代碼必須能在target上運行。再進一步分析:

            1、頭文件:必須是針對target的,因為使用這個工具鏈編譯的源代碼需要訪問的系統接口是trget上的。

            2、binutils:必須能在host上運行,然而產生target的代碼。

            3、gcc:和binutils一樣。不過這里要注意的是,gcc自身帶有一個庫,稱為libgcc,它必須是target上的代碼。

            4、glibc:必須是target上的代碼。

            有了這些基本認識,讓我們來看一看一些實際的工具鏈構造過程。

            LFS工具鏈構造順序:binutils p1->gcc p1->頭文件->glibc->adjust->gcc p2->binutils p2

            其中最后兩步應該可以互換,但頭兩步不行。如果你有留意編譯過程,會發現,當gcc編譯的時候,一旦內部編譯第一次gcc完成,產生了xgcc文件,隨后的編譯就會利用新編譯的gcc以及第一遍的binutils,而不是宿主的gcc和binutils。

            正如youbest指出的,第一遍的binutils和gcc存在的意義,僅僅是為了能編譯出glibc。而glibc的編譯需要工具鏈所有其它內容,包括binutils,gcc和頭文件。

            LFS不使用交叉編譯,因此host和target永遠是一樣的。在編譯參數中,我們永遠看不到--host和--target的身影。但是,由于工具鏈的引用路徑需要反復變化,因此我們需要通過修改specs來更改。這點是LFS比較容易出錯的地方。

            CLFS顧名思義,是要采用交叉編譯的。其構造順序如下:

            頭文件->cross binutils->cross-gcc c->glibc->gcc final (c/c++)

            我們首先看到頭文件被放在了開頭。這不是必須的,它完全可以放在glibc之前。cross-gcc只能編譯出C編譯器,因為這時候工具鏈還不全,glibc還不存在,不可能編譯出C++編譯器。然后構建glibc。之后,我們才能編譯出C++編譯器,完成我們的工具鏈。

            CLFS-SYSROOT的工具鏈稍有不同,順序如下:

            頭文件->cross-binutils->glibc頭文件->cross-gcc c->gibc->gcc-final (c/c++)

            我們看到這里多了一個glibc頭文件的安裝。事實上,這是由于這里編譯的gcc是要用sysroot的緣故。在gcc/configure里面有一段代 碼,大家在vi里面輸入/inhibit_libc=false就可以發現,在交叉編譯,而沒有SYSROOT的情況下,inhibit_libc的值會 成為true,而要是sysroot了,就false了。

            這個變量的作用,如同有關的注釋所述,是用來關閉gcc對glibc頭文件的依賴。因此,在sysroot下我們才會需要這樣一個安裝glibc頭文件的步驟。

            我想在sysroot下消除這個步驟,之前測試過這個補丁可行:

            使用這個sed命令打個補丁即可:

            cp gcc/configure{,.orig}

            sed -e 's/inhibit_libc=false/inhibit_libc=true/g' gcc/configure.orig > gcc/configure

            不過最近發現有更簡單的方法:在configure的時候加個參數--with-newlib即可。建議采用這個方法,因為不需要打任何補丁。

            在此再說一句,工具鏈構建過程中,編譯腳本對于是否交叉編譯的判斷非常簡單,只要host!=target,就會被認為正在交叉編譯。這也就是為什么 CLFS中使用的$CLFS_HOST通常都是i686-cross-linux-gnu這樣的形式。原因很簡單,因為要確保$CLFS_HOST 與$CLFS_TARGET不同。這樣,你完全可以在i686上"交叉編譯"i686的代碼。

            這點非常重要,這意味著我們不需要打任何補丁,即可利用CLFS和CLFS-SYSROOT代替LFS來完成系統。對于想做Multilib的朋友,這也是一個福音。畢竟,CLFS-SYSROOT比起CLFS和LFS來,節省了大量的編譯過程。

            最后,我們來理解一下如何作CCLFS工具鏈。這意味著我們要在一個平臺上構建在第二個平臺上運行、生成第三個平臺上代碼的工具鏈。我們用build表示 構建工具鏈的機器,host表示工具鏈要運行的機器,target表示工具鏈生成的代碼所在機器。而在工具鏈組件上,host-target binutils表示該binutils在host上運行,要生成target的代碼。

            步驟如下:

            host 頭文件->build-host binutils->build-host gcc c->host glibc->target 頭文件->build-target binutils->build-target gcc c->target glibc->host-target binutils->host-target gcc final (c/c++)

            注意事項如下。首先,頭文件必須在相應的glibc之前安裝。其次,build-target的binutils和gcc在這里的目的是生成target glibc。而build-host binutils 還會被構建host-target binutils和gcc的過程使用到。最后,前兩次的gcc都可以只生成c編譯器,因為他們的目的都只是生成glibc。只有最后一次gcc需要完整生成。

            from: http://www.linuxsir.org/bbs/thread325648.html


            posted on 2009-06-25 11:56 runsisi 閱讀(547) 評論(0)  編輯 收藏 引用 所屬分類: embedded system
            欧美伊人久久大香线蕉综合 | 国产精品久久久久久久人人看| 久久免费小视频| 99久久精品这里只有精品| 理论片午午伦夜理片久久| 久久久精品国产| 97久久超碰国产精品2021| 91久久精品国产91性色也| 欧美久久久久久精选9999| 一本久久a久久精品vr综合| 久久久久国产精品| 久久婷婷五月综合国产尤物app| 国产精品久久久久jk制服| 久久久久九九精品影院| 国产人久久人人人人爽| 亚洲第一永久AV网站久久精品男人的天堂AV | 久久久久亚洲av无码专区| 国产精品VIDEOSSEX久久发布| 国产精品成人久久久| 91麻豆精品国产91久久久久久 | 大伊人青草狠狠久久| 无码人妻久久一区二区三区蜜桃| 久久精品国产亚洲av麻豆小说 | 国内精品久久久久久不卡影院 | 久久精品成人影院| 国产精品久久久久久一区二区三区| 久久影院亚洲一区| 99热热久久这里只有精品68| 久久亚洲国产成人精品性色| 婷婷久久精品国产| 久久久久亚洲av毛片大| 久久99久久无码毛片一区二区 | 久久婷婷五月综合国产尤物app| 国产精品美女久久久久av爽| 日本精品久久久中文字幕| 69久久夜色精品国产69| 久久精品www人人爽人人| 日韩AV无码久久一区二区| 99久久国产综合精品女同图片| 国内精品久久久久影院亚洲| 伊人久久大香线蕉成人|