Software > Applications and Porting
[DEV] applying patches to old version of gcc
TimKelly:
Hello,
I am currently trying to build the Self-Boot Engine component natively on a Raptor Blackbird, running Debian
# uname -a
Linux 99-224-155-23 6.1.0-37-powerpc64le #1 SMP Debian 6.1.140-1 (2025-05-22) ppc64le GNU/Linux
It has gcc/g++ 12.2. Unfortunately, the SBE code has code that violates C++17 standards, which were implemented with g++ 11. I need to build gcc/g++ 10, which is not supported so there not a binary package available. However, the source code is available at
https://sources.debian.org/src/gcc-10/10.2.1-6/debian
It does not compile
build/genhooks -d \
../.././gcc/doc/tm.texi.in > tmp-tm.texi
genhooks: No place specified to document hook TARGET_ASM_OPEN_PAREN
The solution to this appears to apply patches as noted at
https://lists.debian.org/debian-gcc/2011/10/msg00002.html
Patches to Debian for gcc are available at
https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches
The problem is I can not see a unified patch that applies all of them, nor can I figure out which ones I will specifically need, since many of them are architecture and language specific. I applied one patch, bootstrap-no-unneeded-libs.diff, but it failed on one of the two files. It may be due to necessary changes that other patches apply.
Does anyone have any advice? I am not particularly versed with Linux or gcc (not my preferred development environment).
Thank you,
tim
ClassicHasClass:
I don't know off the top of my head what you'd do with genhooks, but does passing -std=c11 (or c++11, as appropriate) to the compiler help with the other issues?
TimKelly:
I have made a significant mis-statement. I said the SBE code had the C++ that failed C++17. This is not correct, and I apologize for the confusion. It is ppe42-gcc that has the C++ code. ppe42-gcc is the default compiler for the SBE. The error
../.././gcc/reload1.c: In function ‘void init_reload()’:
../.././gcc/reload1.c:89:24: error: use of an operand of type ‘bool’ in ‘operator++’ is forbidden in C++17
89 | (this_target_reload->x_spill_indirect_levels)
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
../.././gcc/reload1.c:444:7: note: in expansion of macro ‘spill_indirect_levels’
444 | spill_indirect_levels++;
| ^~~~~~~~~~~~~~~~~~~~~
from the following compile
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I../.././gcc/../libbacktrace -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../.././gcc/reload1.c
Oddly, reload1.c is not a C++ file, but it is embedded in a long list of files compiled with g++.
Changing the instruction manually to
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I../.././gcc/../libbacktrace -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo -std=c++11 ../.././gcc/reload1.c
did actually compile. Thanks!!!
I wish I could say
$ CFLAGS='-std=c11' CXXFLAGS='-std=c++11' ./configure
(after make distclean) solves the problem, but CXXFLAGS is not being passed, even though it is in the Makefile:
./Makefile:337:CXXFLAGS_FOR_BUILD = -std=c++11
The command remains
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I../.././gcc/../libbacktrace -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../.././gcc/reload1.c
Otherwise this is an encouraging gain on the problem. I had been attempting to solve the problem by recreating a QEMU VM closer to the original build, with Debian 10 and gcc 8. I've gotten libmpc and libmpfr installed, but there is an error in the Makefile construction.
Thanks again!
tim
TimKelly:
There appears to be a bug in the transfer of CXXFLAGS to the out-of-tree build Makefile. The master Makefile at the root level of ppe42-gcc has
CFLAGS = -std=c11
LDFLAGS =
LIBCFLAGS = $(CFLAGS)
CXXFLAGS = -std=c++11
LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
GOCFLAGS = $(CFLAGS)
but the Makefile in ./host-powerpc64le-unknown-linux-gnu/gcc has
CFLAGS = -g
CXXFLAGS = -g
LDFLAGS = -static-libstdc++ -static-libgcc
It doesn't matter if I pass CXXFLAGS on the command line or export to a shell variable, or use CXXFLAGS_FOR_BUILD, the -std=c++11 never gets passed to the actual build Makefile. If I manually add it to the build Makefile and compiling in the out-of-tree build directory, things build until the next failure, in a different part of the compilation.
cy384:
It's unlikely anyone has tried to manually build this outside of the full openpower build environment in forever. Grab the talos or blackbird openpower repository to see what it's doing (https://scm.raptorcs.com/scm/git/blackbird-op-build). There are probably tons of extra build flags and maybe patches being applied, along with a version specific version of the compiler. I'm not very familiar with buildroot but it seems like there's some stuff in openpower/package/ppc42-gcc
If you don't really absolutely need to build it in isolation from the rest of the system, I'd recommend sticking with the full build and modifying just the parts you care about inside of it.
Please excuse me if this is a patronizing or X-Y problem response!
Navigation
[0] Message Index
[#] Next page
Go to full version