build GCC fails on Debian x64 platform.
build GCC fails on Debian x64 platform.
My platform is Debian x64, the posted tools are for x86 hense I follow the procedure to build myself the toolchain for x64.
Everything goes well and I can complete build gdb and binutils, when building gcc the “make all-gcc” runs for a long time and finally stops at this:
In file included from ../../../source/gcc-4.9.2-20150423/gcc/cp/except.c:1013:0:
cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ previously declared here
cfns.gperf: At global scope:
cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const char*, unsigned int)’ used but never defined
Makefile:1060: recipe for target ‘cp/except.o’ failed
make[1]: *** [cp/except.o] Error 1
make[1]: Leaving directory ‘/home/eddie/Downloads/rl78/build/gcc/gcc’
Makefile:3935: recipe for target ‘all-gcc’ failed
make: *** [all-gcc] Error 2
This is the source code for toolchain for RL78 from gcc-4.9.2-20150423_rl78_v15.02.tar.bz2
However exactly the same problem happens when building the toolchain for RX from gcc-4.8.4_rx_v15.02.tar.bz2.
I traced the issue to cfns.h and took the liberty to change a couple lines to just let the build process continue:
#ifdef __GNUC__
#ifdef __GNUC_STDC_INLINE__
__attribute__ ((__gnu_inline__))
#else
__inline
#endif
#endif
const char * libc_name_p (const char *, unsigned int);
Now the build continues for a long time but ultimately fails with another error (this time the error is different for RX than for RL78), at this point I rather not introduce more changes to I’m reporting it.
Note: I can use the x86 pre-built toolchains -in fact I’m using them – but I thought it’d be important to bring this matter to your attention so you can take a look and fix the conflict in next builds.
Thanks
I downloaded the gcc-4.8.4.201803-GNURX-ELF.run file from the gcc-renesas.com site and changed the permissions to allow it to execute, but I keep getting the error message “No such file or directory”. I am on a 64 bit machine running Ubuntu 18.04.2. How did you get the .run file to run on your Debian machine? Where did you download your .run file?
sure 😀 Without doing “+x” I will not being able to execute it. Without the dot-slash the error is not any strange to me
I try another way. I install this: apt install lib32ncurses5 lib32z1
After doing it the “No such file or directory” error did not come again and the “.run”-file was executeable. I think, this is not a mainstream error, because many people install some multilib-stuff and the packages above are still installed.
On other Linux distributions you got a “32bit ELF not executable” or “wrong architecture” or something similar.
FIXED
On 64-bit Debian, installation of these packages resolved the issue with gcc-8.3.0.201904-GNURX-ELF.run :
sudo apt-get install libc6-i386
sudo apt-get install lib32stdc++6
By the way, why there is no official Debian package for the toolchain?
I am also attempting to build for the RX and get the same failure when I build gcc. I am using Ubuntu 18.04 LTS and would like to either build my own or find a compatible pre-built toolchain for the RX and other Renesas families. Can anyone provide a solution to the gcc failure?
HI. I am running a “fresh” Debian on a 64 bit machine. I try to run the gcc-4.8.4.201803-GNURX-ELF.run file and get “No such file or directory”. That strange error mostly occurs, if the run-binary does not fit to the system.
It is true, that the “.run” executable is 32bit only?
Will it run, if I install some special multilib packages?
Hello,
Thank you for bringing this to our attention.
We have a dedicated page with build instructions for the RL78 platform, available at https://gcc-renesas.com/wiki/index.php?title=Building_the_RL78_Toolchain_under_Ubuntu_14.04
The instructions above are also working for the Ubuntu 14.04 x64 platform. Would you mind telling us if this is something you had used when attempting the build?
—
Thank you,
The GNU Tools Team