I built the gcc-15.2.0 deb package for Bianbu 2.2.1 and Debian. For the Bianbu installation, I had to additionally build the latest binutils. For Debian, I didn’t need to create a package, as the required version is already in the repository.
And here’s something I noticed. The gcc-15.2.0 deb package I built weighs 1.01 GB, which is a bit confusing, to say the least. Meanwhile, gcc-14_14.2.0-19_riscv64.deb from the repository is only 529,260 bytes.
Perhaps I did something wrong during the compilation process.
Now I found instructions , which describe the process of creating a deb package in detail. And dpkg-buildpackage -sa -uc -us -etest@spacemit.com-mtest@spacemit.com always gives me an error. I can’t build a deb package this way!
I only managed to build it with sudo fpm…
I’d still like to understand the requirements for creating deb packages, what information is required (licenses, vendors, etc.), and how to properly build packages for bianbu 2.2.1?
configure.ac:35: error: Please use exactly Autoconf 2.69 instead of 2.71
I managed to get around this by installing both versions of auconf and creating a hard link from autoconf to auconf2.69. After that, configuration ran without errors.
Then, various errors arose related to missing programs or libraries.
Eventually, the build started running, despite the build limitation on the number of cores (like -j$(($(nproc)-2)) and the like). It wouldn’t build with the limitation, always trying to load all 8 cores… I finally managed to fix this by adding
DEB_BUILD_OPTIONS=“parallel=$(($(nproc)/2-1))”
DEBUILD_OPTIONS=“-j$(($(nproc)/2+1))” to the environment.
After that, the system stopped freezing during the build, but the build still failed with the error
dh_auto_install: error: make -j5 install DESTDIR=/gcc-15.2.0/debian/gcc-15 AM_UPDATE_INFO_DIR=no returned exit code 2
I finally got around to changing the build command to look like this:
time dpkg-buildpackage -us -uc -ariscv64 --host-type riscv64-linux-gnu | tee build.log
But the above error still persisted, and now it’s popping up with a message about insufficient resources, either on disk or memory.
I tried various options, but I can’t even remember them now, as they always resulted in similar errors. I didn’t bother remembering or saving the logs or taking screenshots.
Eventually, I got around to using sudo fpm, which allowed me to build the package in two stages, although not right away – various difficulties arose as well.
sudo fpm -s dir -t deb -n gcc-15 -v 15.2.0 --iteration 1 -C …/…/gcc-pkg --description “GCC 15.2.0 for RISC-V64 (rv64imafd lp64d)” --license “GPL-3.0-or-later” --vendor “GNU Project” --url “https://gcc.gnu.org/” -p gcc-15_15.2.0_riscv64.deb usr
P.S. I found your instructions mentioned above after the build was finished and I saw the final size of the deb package.
Here are the last configured rules
So, after not getting any answers here, I analyzed the error message using qwen2.5:3B running Bianbu 2.2.1, and here’s what it recommended:
2.Increase Stack Size (if necessary):
If -fvar-tracking-assignments is indeed the cause, you may need to increase stack size for the build
process. This can be done by setting the environment variable CCOPTS before running your build
commands:
export CCOPTS="-O2 -Wextra -g"
Then, rerun your build command.
3.Disable -fvar-tracking-assignments:
If possible, try to disable this option and see if the build process continues successfully. You can
do this by setting:
4Check for Memory Constraints:
If you are building on a system with limited memory or disk space, this could also contribute to the
issue. Ensure that there is sufficient free space and that your kernel’s limits are not too restrictive
(e.g., ulimit).
I’ve just started a rebuild on 5 cores, the build should finish in about 14 hours.
Adding the export CCOPTS=“-O2 -Wextra -g -fno-var-tracking-assignments” variable before building the package did not fix the situation, the build error is repeated.
For comprehensive knowledge about Debian packaging, please refer to the official Debian Maintainer Guide. This documentation covers essential topics including debian/control, debian/rules, debian/changelog, and the complete build workflow.
Regarding your gcc-15 backport attempt, the primary challenge lies in dependency resolution. Backporting gcc-15 to Bianbu 2.2.1 (based on Debian) typically involves:
Build dependencies: Newer gcc versions often require updated binutils, libc-dev, and other toolchain components that may not be available in the target release
Runtime dependencies: Libraries linked against newer gcc may introduce ABI incompatibilities with the base system
Bootstrap requirements: GCC sometimes requires itself (or a specific version) to build, creating circular dependency scenarios
The significant size difference you observed (1.01 GB vs 529 KB) strongly suggests the official package uses split packaging (gcc-15, gcc-15-base, libgcc-15-dev, etc.) and debug symbol stripping, whereas your fpm-built package likely bundles everything monolithically with full debug info.
We have internally logged your gcc-15 backport request for the Bianbu team to prioritize. Meanwhile, the above resources should help you understand the packaging complexity involved.
Signal 9 indicates possible multithreaded compile-time OOM.
You can try to reduce the number of compilation threads in the gcc-15 root directory by using dpkg-buildpackage -us -uc -b -j4 (note that -j4 may not be fully passed down in debian/rules, and you may need to modify debian/rules; you can observe during compilation using htop/top commands).
Can I understand that currently you have a functionally available GCC-15 (though it is quite large in size), and the goal is to create a GCC-15 organized more like a Debian package? Or is it that this 1.01 GB GCC-15 is not fully functional?
This is good news. Tnx. I’ll be waiting for a fresh version of gcc in bianbu-2.2.1. But will this version also be available in the repository for Debian-13?
Yes. I was able to build a deb package for Debian 13, then installed it on Bianbu-2.2.1. With some link edits, the compiler seemed to work, but when I got to AI , I struggled with building PyTorch and TensorFlow for a long time. Because I encountered so many errors during the build, I had to remove gcc-15.2.0 from the system.
After building the gcc-15.2.0 deb package, I came across this link. And yes, the fact that the size matched reassured me a bit, but on the other hand, I began to doubt that the package had built correctly in my case.
I understood this, but I couldn’t split it into separate packages. My inexperience in preparing for building a package as large as gcc was showing. I had to build it as one big package, and the resulting package size amazed me.
Thanks again for your understanding and promptness in adding this version of gcc to the priority list.
Yes, I tried building the package using the commands dpkg-buildpackage -us -uc -b -j2 and even dpkg-buildpackage -us -uc -b -j1 . However, building the package using these methods still failed.
Yes. I was able to build a deb package for Debian 13, then installed it on Bianbu-2.2.1. With some link edits, the compiler seemed to work, but when I got to AI , I struggled with building PyTorch and TensorFlow for a long time. Because I encountered so many errors during the build, I had to remove gcc-15.2.0 from the system.
So it seems that the GCC-15 you built yourself still has some stability issues. Do you think the independently released GCC-15 on GitHub can meet your needs? If not, what are the main problems with it?
Alternatively, to put it another way, I’d like to understand the benefits of directly installing a GCC 15.2 deb package in Bianbu compared to this independent GCC-15 version (aside from the size difference, as mentioned earlier).
Yes and no. Just today, I successfully built Tensor Flow Lite from source, and the installation seemed to go smoothly. However, building PyTorch and TFL was quite tedious, and I haven’t had a chance to test them yet, nor have I returned to gcc-15.2.0. I plan to take a short break for a couple of days, and then I’ll do some testing and so on. As far as I remember, the gcc-15.2.0 package had issues with replacing the correct links in /usr/bin, so I had to fix all the links manually. Something like that.
I’d like to finish building gcc-15.2.0. First of all, it’s a custom package, so if something doesn’t work, it’s my fault, not anyone else’s—like the developers on GitHub, for example. Overall, it was a good experience for me and an opportunity to figure out how to build a package for this toolchain - set of compilers.