-
Jérome Perrin authored
It seems some programs can only be built by the same gcc than the one used to build golang itself. For example, when system gcc is gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, grafana-server fail to build with: /data/slappart11_testnode/cqg/inst/test0-0/tmp/shared/golang1.12/fbee59cfb3c995382cf70d409615aa54/pkg/tool/linux_amd64/link: running gcc failed: exit status 1 /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /usr/bin/ld: /tmp/go-link-305363633/000000.o: unable to initialize decompress status for section .debug_info /tmp/go-link-305363633/000000.o: file not recognized: File format not recognized collect2: error: ld returned 1 exit status Also generally, if we don't trust system gcc to build golang, we cannot trust it to build golang programs. The downside is that if components or software want to use a specifig golang version they have to set both golang= and the corresponding gcc-bin-directory= in their [gowork]
bf2ca5e9