gcc-9.2.0 failure to compile

[mikeburr]

im trying to install gcc 9.2.0
updated all libraries and tried various compile options
eg configure --enable-languages=c,c++ --disable-multilib
and
configure --prefix=/usr --enable-languages=c,c++ --disable-multilib \
--disable-bootstrap \
--with-system-zlib



instructions summarised but have tried variants
[obviously after ..make distclean ]


GCC_VERSION 9.2.0
yum -y update
yum -y install bzip2 wget gcc gcc-c++ gmp-devel mpfr-devel libmpc-devel etc ...
[gcc --version = 4.8.5 20150623 as per current centos ]
wget https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/gcc-9.2.0.tar.gz
tar zxf gcc-9.2.0.tar.gz
mkdir gcc-9.2.0
cd gcc-9.2..0

./configure --enable-languages=c,c++ --disable-multilib

[or .SED=sed \
../configure --prefix=/usr \
--enable-languages=c,c++ \
--disable-multilib \
--disable-bootstrap \
--with-system-zlib .... makes no apparant difference ]

make -j 4

the compilation gets fairly close to completion before stopping at the same point about 80% of the way through judging by completed log on web

looks like a 32 bit problem


error details followed by a few bits of info :-

if test -z "$objects"; then \
echo 'int __libgcc_eh_dummy;' > eh_dummy.c; \
/usr/share/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/xgcc -B/usr/share/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -I. -I. -I../../host-x86_64-pc-linux-gnu/gcc -I../.././libgcc -I../.././libgcc/. -I../.././libgcc/../gcc -I../.././libgcc/../include -I../.././libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -fvisibility=hidden -DHIDE_EXPORTS -c eh_dummy.c \
-o eh_dummy.o; \
objects=eh_dummy.o; \
fi; \
ar rc libgcc.a $objects
mv tmp-libgcc.map libgcc.map
ranlib libgcc.a
# @multilib_flags@ is still needed because this may use
# /usr/share/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/xgcc -B/usr/share/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include and -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector directly.
# @multilib_dir@ is not really necessary, but sometimes it has
# more uses than just a directory name.
/bin/sh ../.././libgcc/../mkinstalldirs .
/usr/share/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/xgcc -B/usr/share/gcc-9.2.0/host-x86_64-pc-linux-gnu/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && (echo "/* GNU ld script"; echo " Use the shared library, but some functions are only in"; echo " the static library. */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > ./libgcc_s.so
/bin/ld: skipping incompatible /lib/../lib/libc.so when searching for -lc
/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching for -lc
/bin/ld: i386 architecture of input file `/lib/../lib/crti.o' is incompatible with i386:x86-64 output
/bin/ld: i386 architecture of input file `/lib/../lib/crtn.o' is incompatible with i386:x86-64 output
collect2: error: ld returned 1 exit status
make[2]: *** [libgcc_s.so] Error 1
make[2]: Leaving directory `/usr/share/gcc-9.2.0/x86_64-pc-linux-gnu/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/usr/share/gcc-9.2.0'
make: *** [all] Error 2

---------------------------------------------------------------------

crti.o binary states ==> GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-39)
-----------------------------------------------------------------------

these packages already installed

Package bzip2-1.0.6-13.el7.x86_64 already installed and latest version
Package wget-1.14-18.el7_6.1.x86_64 already installed and latest version
Package gcc-4.8.5-39.el7.x86_64 already installed and latest version
Package gcc-c++-4.8.5-39.el7.x86_64 already installed and latest version
Package 1:gmp-devel-6.0.0-15.el7.x86_64 already installed and latest version
Package mpfr-devel-3.1.1-4.el7.x86_64 already installed and latest version
Package libmpc-devel-1.0.1-3.el7.x86_64 already installed and latest version
Package 1:make-3.82-24.el7.x86_64 already installed and latest version



if this isnt recognised ill try and pass it on to the GCC people as it may be a fault in the make

regards mikeb

[chemal]

Is this system of any importance to you? What you are doing is going to break it.

[mikeburr]

@chemal
good question ... ive written a load of programs in assembler 32 bit which i want to transfer to Linux and eventually onto a Zedboard ... it would be nice to use the GCC -mfpu neon-fp16 setting to compile stuff but ideally i want to run the whole lot 64 bit [this actually precludes using KVM as the Cortex-9 doesnt support it ] so its a try out .. i kind of need the 32 bit stuff to transfer to [probably QT5 GUI calling the programs reassembled using NASM
32 bit so i can get them running .. then migrated to 64 bit ] once ive got them running under linux im hoping to try them out first on the Zedboard maybe using centos as an op sys and then with some functionality transferred into pseudo hardware on the FPGA in the hopes that i can get a lot more parallelism
into the processes

as i dont know a lot about it its a fairly steep learning curve
back t your original question
i downloaded REDasm and found it required an upgrade to the compiler

if youve got any thoughts on this i would be very glad of them
thanks mike b
ps the system hasnt broken yet .. ive upgraded the core to 5 from 3 and added quite a few other bits requiring upgrades and apart from the 'backticks' issue which you very kindly pointed out to me in a previous post its gone very well .. the Centos system has proved to be very resilient, works well,[far better than Ubuntu and Mint both of which i tried briefly but are obviously less stable ] .. just got a bit confounded by this one as couldn't really trace it in the makefile .. so its been a bit of an exercise in seeing where and how things work on a linux system .. a bash command in a day course .. that sort of thing ..frustrating at times but thoroughly enjoying it

[chemal]

Install glibc-devel.x86_64. Then your gcc build should finish.

[jlehtone]

Does it have to be gcc-9.2? Would gcc-8.3.1 suffice? That is in SCL:
To 8.3.1 install:

Code: Select all

sudo yum install centos-release-scl-rh
sudo yum install devtoolset-8-toolchain

To use:

Code: Select all

scl enable devtoolset-8 bash
<compile your programs>
exit

[mikeburr]

@chemal
thanks as you must have spent a lot of time looking at the problem
id already been through quite a few options including this and looking at the i386 stuff ...
"Package glibc-devel-2.17-292.el7.x86_64 already installed and latest version
Nothing to do"
it would help if i knew where it was located in the make but i cant find it

@jheltone
this is an excellent option and works very well
I appreciate the fact that you can switch back and forth between the tried and trusted
4.8 that ships with centos as a 'just in case' and the significantly more current GCC 8
and i must thank you for this option and those who developed it as its a smart way to work
as for the version
well i think that 9 probably has a more stabilised Arm compile which
i am hoping to use

NOTE: I didnt include it in my attempts to compile 9.2
[using --disable-multilib instead where i could have tried including arm*-*-* as an option ]
because i encountered what looked
like a 32 bit library/compile problem originally

regards and thank you both for your help
it is much appreciated and of course it benefits other people who may
try the same thing in the future
mikeb

[jlehtone]

@chemal
thanks as you must have spent a lot of time looking at the problem
id already been through quite a few options including this and looking at the i386 stuff ...
"Package glibc-devel-2.17-292.el7.x86_64 already installed and latest version
Nothing to do"
it would help if i knew where it was located in the make but i cant find it

The 64-bit installation (on x86, no idea about arm) has only 64-bit binaries by default, but the repository has 32-bit binaries too:

Code: Select all

# yum -q list glibc-devel
Installed Packages
glibc-devel.x86_64       2.17-292.el7        @base 
Available Packages
glibc-devel.i686         2.17-292.el7        base

You can be explicit:

Code: Select all

sudo yum install glibc-devel.i686

[Mike_Rochefort]

Something to be aware of is DTS 9 will be released sometime in the next month or so with RHEL 8.1’s official release. I would like to assume it will be made available with RHEL 7 soon afterward, meaning CentOS will have the ability to rebuild it for 7. DTS 9 (based off RHEL 8 info) will use GCC 9.1.1, and the update that will likely happen in the spring will update this to GCC 9.3.x or 9.2.x.

Cheers,
Mike