Build RPMs for version 9

[dmik]

We need a new set of GCC RPMs. They will be independent of the gcc4 set because a lot has been changed and we're taking a fresh Fedora .spec for GCC 9.

[dmik]

There is a lot to check/consider but I expect to make it before the NY.

Some things will be certainly different. In particular, -march will default to i686 now which enables some important things like GCC atomic builtins (__atomic_fetch_add and friends) and some other useful stuff which requires an i486 or higher CPU (all previous builds of GCC defaulted to i386 which is way too outdated given that i686 is the minimum CPU our RPMs are targeted at).

Also, there will be some DLL and subpackage renames (with the respective forwarders and provides) to better reflect the cross-platform considerations and our toolchain layout. Stay tuned.

[dmik]

All the main work is done (yes there was a lot). The last step is to migrate some OS/2 specific bits from gcc4.spec, including legacy libgcc DLLs, stdcpp forwarders, wlink virtual packages etc.

[dmik]

Ive built it all but unfortunately an attempt to build GCC again with the fresh one installed from GCC 9 RPMs fails with a very strange message. A popup message box appears with something like SYS1ххх saying about an out of memory condition. In the build log I see this (made two attempts):

echo timestamp > s-config
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-opinit.h insn-opinit.h
build/genattrtab.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/common.md D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/config/i386/i386.md insn-conditions.md \
    -Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-latencytab.c
OS/2 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... echo timestamp > s-target-def
build/genautomata.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/common.md D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/config/i386/i386.md \
  insn-conditions.md > tmp-automata.c
yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-opinit.c insn-opinit.c
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-attrtab.c    insn-attrtab.c

out of memory allocating 4064 bytes after a total of 4262550444 bytes

and

echo timestamp > s-opinit
build/genemit.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/common.md D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/config/i386/i386.md \
  insn-conditions.md > tmp-emit.c
gcc3
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-emit.c insn-emit.c
checking how to run the C++ preprocessor... echo timestamp > s-emit
build/genextract.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/common.md D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/config/i386/i386.md \
  insn-conditions.md > tmp-extract.c
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-extract.c insn-extract.c
echo timestamp > s-extract
build/genoutput.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/common.md D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/config/i386/i386.md \
  insn-conditions.md > tmp-output.c
g++ -E
checking for ld used by g++... ld
checking if the linker (ld) is GNU ld... no
checking whether the g++ linker (ld) supports shared libraries... yes
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-output.c insn-output.c
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-attrtab.c    insn-attrtab.c
echo timestamp > s-output
build/genpeep.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/common.md D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/config/i386/i386.md \
  insn-conditions.md > tmp-peep.c
/@unixroot/usr/bin/sh.exe D:/Users/dmik/rpmbuild/BUILD/gcc-9.2.0/gcc/../move-if-change tmp-dfatab.c     insn-dfatab.c

out of memory allocating 4064 bytes after a total of 4206582700 bytes

Really strange. Not sure ever seen that before. And of course due to lousy make logging in -jX mode, I have no idea which command this error comes from. But it looks like building (running?) some configure test. I have to debug it somehow outside of rpmbuild...

[martinrotter]

Is there any experimental set of RPMs ready for testing or alpha usage? I have some Qt app which I would like to add support for OS/2 for.

[dmik]

BTW, here is a screen shpt of the popup:

And the error message comes from libiberty/xmalloc.c when xmalloc falis. When and why it fails, is still an open question but I've reproduced it in an out of rpmbuild build at least. I.e. in my normal debug build environment.

@martinrotter Not ATM. Test RPMs I have now are quite hard to install (requires manual intervention). Please wait for a few days, there will be a new set available in netlabs-exp.

[dmik]

All builds fine now — I first built 9.2.0 using the 4.9.2 RPMs then built it again using the newly built 9.2.0. Test 9.2.0 RPMs are also built and should be installable. I will be cooking the final RPMs now.

In between I have to also cook a new set of libtool RPMs because it has a strict dependency on the GCC version (due to version number in private headers, like /usr/include/c++/x.y.z etc). Prior to that, the new GCC won't be installable.

[martinrotter]

Good news.

[dmik]

Just for the record, there is a new problem when downloading the source ZIP from GitHub (part of our RPM build pipe line). For some reason both wget and curl download a truncated file which is much smaller than the original (155MB). Here's the output of curl (as it's more informative):

D:>curl https://github.com/bitwiseworks/gcc-os2/archive/gcc-9_2_0-release-os2-b1.zip -OL
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   143    0   143    0     0    320      0 --:--:-- --:--:-- --:--:--   345
  0     0    0 93.8M    0     0   148k      0 --:--:--  0:10:48 --:--:--  170k
curl: (18) transfer closed with outstanding read data remaining

The above error indicates that according to the header, there should be more data but the transfer has been closed for some reason. It's a total mystery and none of my colleagues can reproduce it so it's not related to DLL versions or such. Seems to be my hardware somehow. I'm very confused.

So far, I downloaded the ZIP from my macOS manually and fed it to the build pipeline. So we should see a new bunch of RPMs soon (in ~4h).

[dmik]

i686 and pentium4 RPMs of both libtool and GCC have been successfully built and are now being uploaded to the experimental repository. Should be installable in an hour or so. Feel free to test.

[martinrotter]

@dmik Can you give me a hint on how to upgrade to GCC 9.2? I have added experimental repository but package manager complains that there are some newly obsolete/conflicting packages and removing these shows me that many other basic packages would get removed too.

[SilvanScherrer]

@martinrotter it seems like some scripts are not running at the netlabs-exp repo. So stay tuned until this is fixed. As the rpm should just appear when they run ok.

[dmik]

Unfortunately, the repository server is still being fixed by the maintainer (ETA is tomorrow). For those who want to try it out before the server is fixed, it's enough to grab the following RPM files from http://rpm.netlabs.org/experimental/00/i386/pentium4/:

gcc-9.2.0-2.oc00.pentium4.rpm
libgcc-9.2.0-2.oc00.pentium4.rpm
libgcc-fwd-9.2.0-2.oc00.pentium4.rpm
libssp-9.2.0-2.oc00.pentium4.rpm
libssp-fwd-9.2.0-2.oc00.pentium4.rpm
gcc-c++-9.2.0-2.oc00.pentium4.rpm
libstdc++-9.2.0-2.oc00.pentium4.rpm
libstdc++-fwd-9.2.0-2.oc00.pentium4.rpm
libstdc++-devel-9.2.0-2.oc00.pentium4.rpm
cpp-9.2.0-2.oc00.pentium4.rpm
gcc-wlink-9.2.0-2.oc00.pentium4.rpm
gcc-wrc-9.2.0-2.oc00.pentium4.rpm
libtool-2.4.6-4.oc00.pentium4.rpm

Then something like rpm -F *.rpm from a local directory with these RPMs should work.

Please also note that if you want to roll back to the previous set of RPMs of GCC 4.9.2 (e.g. to test a normal yum install), then you will have to run this script (as neither yum nor rpm itself provide a downgrade procedure smart enough to do it with an one-liner):

# Remove GCC 9.x and install GCC 4.9.2 back
VER=4.9.2.1-3.oc00
yum --setopt=obsoletes=0 shell << EOF
remove gcc gcc-w* libgcc libgcc-fwd cpp gcc-c++ libstdc++ libssp libtool
install gcc-$VER gcc-w*-$VER libgcc1-$VER libgcc-fwd-$VER libstdc++6-$VER libssp-$VER libstdc++-4.4.6.17-1.oc00 libtool-2.4.6-3.oc00
run
y
EOF