2025.01.07. 초안
2025.01.08. 업데이트
일단 두서없이 기록 중..
설치 환경 셋업 다 되면 언젠간 정리할 예정
어쩌다보니 ASIC 설계에 risc-v core를 넣게 되어 관련 셋업 중임.
https://github.com/riscv-collab/riscv-gnu-toolchain/tree/master
GitHub - riscv-collab/riscv-gnu-toolchain: GNU toolchain for RISC-V, including GCC
GNU toolchain for RISC-V, including GCC. Contribute to riscv-collab/riscv-gnu-toolchain development by creating an account on GitHub.
github.com
서버환경: CentOS
쉘: C-Shell
리눅스 CentOS서버라서 아래와 같이 prerequisition들을 설치
sudo yum install autoconf automake python3 libmpc-devel mpfr-devel gmp-devel gawk bison flex texinfo patchutils gcc gcc-c++ zlib-devel expat-devel libslirp-devel
아래의 명령어를 통해 riscv-gnu-toolchain 레포지토리 클론
git clone https://github.com/riscv/riscv-gnu-toolchain
근데 지금까지 확인했을 때는 내부에 링크되어 있는 레포지토리들이 비어있음
링크가 잘 안된거같음
submodule로 되어있는 레포지토리를 처음 클론해봐서 그런 것이었음
아래의 명령어로 처음부터 클로닝을 했었어야함.
git clone --recurse-submodules https://github.com/riscv/riscv-gnu-toolchain
벌써 했다면 아래의 명령어 입력해서 서브모듈들 클로닝할 수 있음
cd <클론한_레포지토리_경로>
git submodule update --init --recursive
클로닝 중 아래와 같은 에러가 출력됨
Cloning into 'dejagnu'...
fatal: unable to access 'https://git.savannah.gnu.org/git/dejagnu.git/': The requested URL returned error: 502
Clone of 'https://git.savannah.gnu.org/git/dejagnu.git' into submodule path 'dejagnu' failed
DejaGnu에서 레포지토리 경로를 https://git.savannah.gnu.org/cgit/dejagnu.git으로 가져오길래 들어가보니까 여기는 502 gateway 에러가 뜨는 것으로 보임
근데 https://git.savannah.gnu.org/git/dejagnu.git 여기 주소는 또 잘 들어가진다는 것...
교내 서버에서 막힌건지 확인이 필요할 것 같은데 우선은 그냥 DejGnu에서 최신 코드 다운로드 받음
https://ftp.gnu.org/gnu/dejagnu/
Index of /gnu/dejagnu
ftp.gnu.org
위 경로의 1.6.3이 최신인 것 같음
아래의 명령어를 통해 tar.gz파일 받고 압축해제 가능
wget https://ftp.gnu.org/gnu/dejagnu/dejagnu-1.6.3.tar.gz
tar -xzvf dejagnu-1.6.3.tar.gz
mv dejagnu-1.6.3 dejagnu
dejagnu는 따로 받았으니까 submodule recursive clone 과정에서 dejagnu는 받을 필요가 없음
아래의 명령어를 통해 dejagnu clone 관련된 내용들은 삭제함
vim .gitmodules
vim .git/config
그래도 계속 안되서 아래 명령어 치고 다시 압축풀었음
git rm -f dejagnu
tar -xzvf dejagnu-1.6.3.tar.gz
mv dejagnu-1.6.3 dejagnu
이 이후로는 큰 문제 없이 repository submodule들 클로닝 잘 되어 가는중
클로닝 다 된 이후에 아래의 코드 입력해서 make 수행
./configure --prefix=[설치경로]/riscv --with-arch=rv32gc --with-abi=ilp32d
set path=([설치경로] /riscv/bin $path)
make linux
겁나 오래 걸려서 했더니 아래와 같은 에러가 뜬다
configure: error:
*** These critical programs are missing or too old: make
*** Check the INSTALL file for required versions.
make: *** [stamps/build-glibc-linux-rv32gc-ilp32d] 오류 1
make 버전이 오래됐나보다....
사용하는 운영체제가 CentOS라서 yum 명령어로 make 새로 받기보다 그냥 아래 방식으로 make 다시 설치했음
wget http://ftp.gnu.org/gnu/make/make-4.4.tar.gz
tar -xzf make-4.4.tar.gz
cd make-4.4
./configure
make
sudo make install
make --version 명령어로 4.4로 잘 설치된 것 확인하고 다시 실행
make 명령이 엄청 오래 걸려서 tmux 환경에서 다시 실행...
다음날 출근해서 확인하니 또 다시 동일한 에러 발생..
이번에도 또 동일한 에러가 뜨는 걸 봐서는 make 버전 문제가 아니라 뭔가 누락된 프로그램들이 있나보다
configure: error:
*** These critical programs are missing or too old: make
*** Check the INSTALL file for required versions.
make: *** [Makefile:444: stamps/build-glibc-linux-rv32gc-ilp32d] Error 1
전체 로그를 찍어보니까 이렇게 나온다
checking build system type... x86_64-pc-linux-gnu
checking host system type... riscv32-unknown-linux-gnu
checking for riscv32-unknown-linux-gnu-gcc... riscv32-unknown-linux-gnu-gcc
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether riscv32-unknown-linux-gnu-gcc accepts -g... yes
checking for riscv32-unknown-linux-gnu-gcc option to enable C11 features... none needed
checking for gcc... gcc
checking whether the compiler supports GNU C++... no
checking whether this-is-not-the-compiler-youre-looking-for accepts -g... no
checking for this-is-not-the-compiler-youre-looking-for option to enable C++11 features... uns
upported
checking for this-is-not-the-compiler-youre-looking-for option to enable C++98 features... uns
upported
checking whether this-is-not-the-compiler-youre-looking-for can link programs... no
checking for sysdeps preconfigure fragments... aarch64 alpha arc arm csky hppa i386 loongarch
m68k microblaze checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
mips nios2 or1k powerpc riscv s390 sh checking for grep that handles long lines and -e... (cac
hed) /usr/bin/grep
checking for egrep... (cached) /usr/bin/grep -E
sparc x86_64
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for [설치경로]/riscv/lib/gcc/riscv32-unknown-linux-gnu/14.2.0/../../../../riscv32-
unknown-linux-gnu/bin/ld... [설치경로]/riscv/lib/gcc/riscv32-unknown-linux-gnu/14.2.0/../..
/../../riscv32-unknown-linux-gnu/bin/ld
checking version of [설치경로]/riscv/lib/gcc/riscv32-unknown-linux-gnu/14.2.0/../../../../r
iscv32-unknown-linux-gnu/bin/ld... 2.43.1, ok
checking for gnumake... no
checking for gmake... gmake
checking version of gmake... 3.82, bad
checking for gnumsgfmt... no
checking for gmsgfmt... no
checking for msgfmt... msgfmt
checking version of msgfmt... 0.19.8.1, ok
checking for makeinfo... makeinfo
checking version of makeinfo... 5.1, ok
checking for sed... /usr/bin/sed
checking version of /usr/bin/sed... 4.2.2, ok
checking for gawk... /usr/bin/gawk
checking version of /usr/bin/gawk... 4.0.2, ok
checking for bison... bison
checking version of bison... 3.0.4, ok
checking if riscv32-unknown-linux-gnu-gcc is sufficient to build libc... yes
checking for python3... python3
checking version of python3... 3.6.8, ok
configure: error:
*** These critical programs are missing or too old: make
*** Check the INSTALL file for required versions.
make: *** [Makefile:444: stamps/build-glibc-linux-rv32gc-ilp32d] Error 1보면 gmake 버전 체크에서 3.82 버전인데 bad가 뜨는걸 볼 수 있다.
make --version으로 확인하면 4.4로 나오는데 gmake랑 make가 참조하는 바이너리 경로가 다른 것 같다.
which make
which gmake
위의 명령어로 make와 gmake 바이너리를 참조하는 경로를 볼 수 있다.
나의 경우 현재 아래와 같은 경로에 바이너리들이 있는 것을 확인할 수 있었다.
make -> /usr/local/bin/make
gmake -> /usr/bin/gmake
gmake는 /usr/bin 경로에 있고, 또 보니까 같은 경로에 있는 make를 심볼릭 링크로 가져오고 있는 것을 확인했다.
/usr/bin/make는 3.82버전인 것으로 보아하니 이게 문제의 원인이 맞다.
ln -Tfs /usr/local/bin/make /usr/bin/gmake #ln -Tfs [새로바꿀경로] [바꿀심볼릭링크]
위의 명령어를 통해 /usr/bin/gmake의 심볼링 링크 경로를 새로 설치한 make로 변경하였고, gmake --version 명령어를 입력하면 이제 정상적으로 4.4 버전으로 나오는 것을 확인할 수 있다.
이제 다시 make linux 명령어를 입력하여 소스코드 빌드 시작..
이번에는 또 아래 에러가 발생...
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for x86_64-pc-linux-gnu-ranlib... ranlib
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for dlfcn.h... yes
checking for windows.h... no
checking for library containing dlsym... -ldl
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking whether g++ supports C++17 features by default... no
checking whether g++ supports C++17 features with -std=gnu++17... no
checking whether g++ supports C++17 features with -std=gnu++1z... no
checking whether g++ supports C++17 features with -std=c++17... no
checking whether g++ supports C++17 features with +std=c++17... no
checking whether g++ supports C++17 features with -h std=c++17... no
checking whether g++ supports C++17 features with -std:c++17... no
checking whether g++ supports C++17 features with -std=c++1z... no
checking whether g++ supports C++17 features with +std=c++1z... no
checking whether g++ supports C++17 features with -h std=c++1z... no
checking whether g++ supports C++17 features with -std:c++1z... no
configure: error: *** A compiler with support for C++17 language features is required.
make[2]: *** [Makefile:10856: configure-gdbsupport] Error 1
make[2]: Leaving directory '[설치경로]/riscv/riscv-gnu-toolchain/build-gdb-linux'
make[1]: *** [Makefile:1028: all] Error 2
make[1]: Leaving directory '[설치경로]/riscv/riscv-gnu-toolchain/build-gdb-linux'
make: *** [Makefile:398: stamps/build-gdb-linux] Error 2
이번에는 g++가 C++17을 지원 안한다고 문제이다.
g++ --version 명령어로 버전을 확인해보니까 현재 설치되어 있는 것은 4.8.5버전.
C++17 표준은 gcc 7.3 버전 이상부터 지원한다고 한다.
CentOS의 경우 아래 명령어로 최신 버전을 설치하라고 한다.
sudo dnf install gcc-c++
하지만 이 명령어로 설치할 수 있는 최신 버전이 4.8.5으로 보인다.
gcc 최신 버전을 받으려고 아래 사이트에서 버전을 확인해봤는데 이 글 작성 시점에서는 14.2.0 버전까지 나와있는 것으로 보인다.
너무 최신 버전은 버그가 있을수도 있으니 13.3.0버전으로 설치를 진행해보았다.
아래의 링크는 gcc 소스 코드를 받을 수 있는 경로이다.
gcc 설치는 아래와 같이 명령어를 입력하여 진행하였다.
wget http://ftp.gnu.org/gnu/gcc/gcc-13.3.0/gcc-13.3.0.tar.gz
tar -xzvf gcc-13.3.0.tar.gz
cd gcc-13.3.0.tar.gz
mkdir build
cd build
../configure --prefix=/usr/local/gcc-13.3.0 --disable-multilib --enable-languages=c,c++
make -j64
sudo make install
이거 하면서 알게되었는데 make 명령어에 -j코어수 를 쓰면 동시에 진행되는 작업 수를 설정할 수 있다더라.
이걸 몰라서 엄청 오랜 시간에 걸려서 make 명령어를 실행시키고 있었었나보다.
위의 코드가 다 돌고 나면 /usr/local/gcc-13.3.0/bin에 gcc 및 g++가 설치된다.
해당 경로의 gcc랑 g++을 실행시키려고 하면 권한 문제로 접근이 안된다.
설치된 gcc-13.3.0의 폴더 권한이 750으로 되어 있어서 그렇다.
아래의 명령어를 입력하여 권한을 변경한다.
sudo chmod 755 /usr/local/gcc-13.3.0/ -R
/usr/local/gcc-13.3.0/bin/gcc --version으로 확인해보면 13.3.0 버전으로 잘 설치된 걸 볼 수 있다.
하지만 gcc --version으로 확인해보면 여전히 4.8.5버전으로 출력된다.
앞서 했던 것과 같이 심볼릭 링크 경로를 변경하고 환경변수를 업데이트했다.
sudo ln -Tfs /usr/local/gcc-13.3.0/bin/gcc /usr/bin/gcc
sudo ln -Tfs /usr/local/gcc-13.3.0/bin/g++ /usr/bin/g++
set path=(/usr/local/gcc-13.3.0/bin $path)
set LIBRARY_PATH=(/usr/local/gcc-13.3.0/lib64/ $LIBRARY_PATH) # 만일 LIBRARY_PATH 변수가 없었다면 set LIBRARY_PATH=(/usr/local/gcc-13.3.0/lib64/)로 입력
set LD_LIBRARY_PATH=(/usr/local/gcc-13.3.0/lib64/ $LD_LIBRARY_PATH)
이후 gcc --version 및 g++ --version을 통해 확인해보면 정상적으로 13.3.0버전으로 출력되는 것을 확인할 수 있다.
이젠 진짜 될 것 같다.
머나먼 길을 돌아왔지만 다시 한번 riscv-gnu-toolchain make를 해본다.
./configure --prefix=[설치경로]/riscv --with-arch=rv32gc --with-abi=ilp32d
set path=([설치경로] /riscv/bin $path)
make linux -j54
드디어 성공한 듯
'코딩일지 > RISC-V' 카테고리의 다른 글
| RISC-V 개발 시 유용한 사이트 정리 (0) | 2025.01.17 |
|---|---|
| riscv-gnu-toolchain을 이용한 바이너리 -> hex code 변환 방법 (0) | 2025.01.08 |
댓글