c語言編譯工具鏈

⑴ riscv-gnu-toolchain 交叉編譯器如何構建

探索RISC-V架構的GNU工具鏈構建之旅

要構建RISC-V架構的GNU工具鏈，你需要精心配置和安裝一系列關鍵組件。首先，確保你的系統已安裝必要的依賴工具，包括 sudo apt-get install git autoconf automake autotools-dev curl python3 libmpc-dev libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf patchutils bc libexpat-dev libglib2.0-dev ninja-build zlib1g-dev pkg-config libboost-all-dev libtool libssl-dev libpixman-1-dev libpython-dev virtualenv libmount-dev libsdl2-dev。

然後，開始下載RISC-V工具鏈的核心組件：

1. 獲取RISC-V編譯器基礎庫

從Gitee克隆riscv-gnu-toolchain的主分支:

git clone https://gitee.com/mirrors/riscv-gnu-toolchain

接著，分別克隆RISC-V的C編譯器（riscv-gcc）配孫、測試框架（riscv-dejagnu）、GNU C庫（riscv-glibc）以及輕量級嵌入式庫（riscv-newlib）:

git clone -b riscv-gcc-10.2.0 https://gitee.com/mirrors/riscv-gcc
git clone https://gitee.com/mirrors/riscv-dejagnu
git clone -b riscv-glibc-2.29 https://gitee.com/mirrors/riscv-glibc
git clone https://gitee.com/mirrors/riscv-newlib

2. 調試器的加入

為了調試，還需下載RISC-V版本的GDB:

git clone -b fsf-gdb-10.1-with-sim https://gitee.com/mirrors/riscv-binutils-gdb riscv-gdb

接下來，進入構建過程：

- 配置工具鏈

在終端創建一個名為"build"的目錄，然後切換到該目錄，執行以下配置命令：

cd build
../configure --prefix=/opt/riscv/gcc --enable-multilib --target=riscv64-multlib-elf

這個配置將工具鏈安裝到"/opt/riscv/gcc"，需要超級用戶許可權，所以請確保使用sudo。

- 編譯與安裝

使用多線程（-j8）加速編譯過程：

sudo make -j8

編譯完成後，工具鏈將自動安裝到指定目錄，可以通過驗證版本信息來確認安裝是否成功：

cd /opt/riscv/gcc/bin
riscv64-unknown-elf-gcc -v

通過以上步驟，你已成功構建飢賣前了RISC-V架構的GNU工具鏈，現在你可以在RISC-V平台上愉快地進行C語言編譯和調試了。這個工具鏈不僅包含了C編譯器，還涵蓋了測試框架和必要的庫爛清支持，為RISC-V開發者提供了強大的開發環境。

⑵ arm-linux-gcc 和 arm-elf-gcc 的區別

在基於ARM的嵌入式系統開發中，常常用到交叉編譯的GCC工具鏈有兩種：
arm-linux-*和 arm-elf-*，兩者區別主要在於使用不同的C庫文件。arm-linux-*使用
GNU的Glibc，而arm-elf-*一般使用 uClibc/uC-libc或者使用REDHAT專門為嵌入式系統
的開發的C庫newlib.Glibc。uClibc/uC-libc以及 newlib都是C語言庫文件，只是所應
用的領域不同而已，Glibc是針對PC開發的，uClibc/uC-libc是與Glibc API兼容的小型
化C語言庫，實現了Glibc部分功能。

關於uClibc/uC-libc的說明，詳見如下：

There are two libc libraries commonly used with uClinux. uC-libc and
uClibc. They are quite different despite their similar names. Here is a
quick overview of how they are different.

uC-libc is the original library for uClinux. It was based on sources
from the Linux-8086 C library which was part of the ELKs project with m68000
support added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete
libc implementation, however, some of the API's are a little non-standard
and quite a few common libc routines are not present. Currently it has
stable support for m68000, ColdFire and ARM (Non-MMU) architectures. It was
primary design goal is to be small and light weight. It does try to conform
to any standards, although its API tries to be compatible with most libcs,
it is not always exactly the same.

The uClinux distribution provides an environment that can compile using
either uC-libc or uClibc depending on your needs. For m68000 and Coldfire
platforms it is generally better to chose uC-libc as it supports shared
libraries and is the most commonly used libc for these CPUs. uClibc also
works quite well with almost all platforms supported by the distribution.
Which libc you choose to use will be decided by your requirements

uClinux有兩個經常使用的libc庫：uC-libc和uClibc。雖然兩者名字很相似，其實有差
別，下面就簡單的介紹一下二者的不同之處。uC -libc是最早為uClinux開發的庫，是
Jeff Dionne和Kenneth Albanowski為在EKLs項目中支持m68000在Linux-8086 C庫源碼
上移植的。uC-libc是一個完全的libc實現，但其中有一些api是非標準的，有些libc的
標准也沒有實現。uC-libc穩定地支持 m68000，ColdFire和沒有MMU的ARM。其主要設計
目標是「小」、"輕"，並盡量與標准一致，雖然它的API和很多libc兼容，但是似乎並
不像它期望的那樣和所有標准一致。

uClibc就是為了解決這個問題從uC-libc中發展出來的。它的所有API都是標準的(正確
的返回類型，參數等等)，它彌補了uC-libc中沒有實現的libc標准，現在已經被移植到
多種架構中。一般來講，它盡量兼容glibc以便使應用程序用uClibc改寫變的容易。
uClibc能夠在標準的 VM linux和uClinux上面使用。為了應用程序的簡潔，它甚至可以
在許多支持MMU的平台上被編譯成共享庫。Erik Anderson在uClibc背後做了很多的工
作。uClibc支持許多系列的處理器：m68000，Coldfire，ARM，MIPS，v850， x86，
i960，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。不斷增加的平台支持顯示uClibc
能夠很容易的適應新的架構。uClinux發行版提供了環境能夠讓你選擇使用uC-libc或是
uClibc編譯。對於m68000和Coldfire平台來說，選擇uC-libc還是稍微好一點，因為它
支持共享庫，而共享庫是這些cpu經常使用的 libc.uClibc也幾乎和所有的平台都能很
好的工作。選擇哪種libc取決於你的需求。

newlib 是一個用於嵌入式系統的開放源代碼的C語言程序庫，由libc和libm兩個庫組
成，特點是輕量級，速度快，可移植到很多CPU結構上。newlib實現了許多復雜的功
能，包括字元串支持，浮點運算，內存分配(如malloc)和I/O流函數(printf，fprinf()
等等)。其中libc提供了c 語言庫的實現，而libm提供了浮點運算支持。

在為ARM交叉編譯gcc編譯器時，對gcc指定不同的配置選項時，使用的C語言庫就不同，
gcc編譯器默認使用Glibc，也可以使用 uClibc/uC-libc(基本兼容Glibc API)，當使用
--with-newlib時，gcc編譯器不使用Glibc。當沒有交叉編譯Glibc時，可以使用
--with-newlib禁止連接Glibc而編譯bootstrap gcc編譯器。從gcc源目錄下的
config/arm中的t-linux和t-arm-elf中可以看出，不同的--target也影響gcc連接C語言
庫，t-linux(--target=arm-linux)默認使用Glibc，-arm-elf(--target=arm-elf)使用
- Dinhibit_libc禁止連接Glibc，這時我們就可以使用newlib等其他C語言庫編譯GCC工
具鏈。

雖然GCC工具鏈配置了不同的的C語言庫，但由於這些C語言庫都可以用來支持GCC，它們
對核心數據的處理上不存在較大出入。因而arm-linux-* 和 arm-elf-*區別主要表現在
C語言庫的實現上，例如不同系統調用，不同的函數集實現，不同的ABI\啟動代碼以及
不同系統特性等微小的差別。

arm-linux-*和 arm-elf-*的使用沒有一個絕對的標准，排除不同庫實現的差異，gcc可
以編譯任何系統。arm-linux-*和 arm-elf-*都可以用來編譯裸機程序和操作系統，只
是在遵循下面的描述時系統程序顯得更加協調：

arm-linux-*針對運行linux的ARM機器，其依賴於指定的C語言庫Glibc，因為同樣使用
Glibc的linux而使得arm-linux-*在運行linux的ARM機器上編譯顯得更加和諧。

arm-elf-*則是一個獨立的編譯體系，不依賴於指定的C語言庫Glibc，可以使用newlib
等其他C語言庫，不要求操作系統支持，當其使用為嵌入式系統而設計的一些輕巧的C語
言庫時編譯裸機程序(沒有linux等大型操作系統的程序)，如監控程序，bootloader等

能使得系統程序更加小巧快捷。

Linaro prebuilt toolchain does support both hard and soft floating
point. You can get it from https://launchpad.net/linaro-toolchain-binaries/+milestone/2012.08 try: ./arm-linux-gnueabihf-gcc -print-multi-lib

The default configure is --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb

To use soft floating, you need options: -marm -march=armv4t -mfloat-abi=soft.

In your case, please try to change -march=armv5 to "-march=armv4t"

If you want to change to configure to cortex-a8 and armv5. You need
* Change cortex-a9 to cortex-a8 in
samples/linaro-arm-linux-gnueabihf/crosstool.config
* Change armv4t to armv5 in
contrib/linaro/patches/gcc/linaro-4.7-2012.08/multilib.patch,

Then follow the instructions to rebuild the toolchain
(contrib/linaro/doc/README.txt)

BTW: crosstool-ng-linaro does not support multilib for eglibc. It uses
the prebuilt sysroot from Ubuntu Precise. If it does not work for you,
please use the latest crosstool-ng from http://crosstool-ng.org/.