mirror of
https://github.com/bitwiseworks/gcc-os2.git
synced 2026-04-23 22:40:07 +00:00
Build RPMs for version 9 #8
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dmik on GitHub (Dec 26, 2019).
Originally assigned to: @dmik on GitHub.
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 commented on GitHub (Dec 26, 2019):
There is a lot to check/consider but I expect to make it before the NY.
Some things will be certainly different. In particular,
-marchwill default to i686 now which enables some important things like GCC atomic builtins (__atomic_fetch_addand 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 commented on GitHub (Dec 30, 2019):
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 commented on GitHub (Jan 7, 2020):
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):
and
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 commented on GitHub (Jan 8, 2020):
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 commented on GitHub (Jan 9, 2020):
BTW, here is a screen shpt of the popup:
And the error message comes from
libiberty/xmalloc.cwhen 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 commented on GitHub (Jan 13, 2020):
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.zetc). Prior to that, the new GCC won't be installable.@martinrotter commented on GitHub (Jan 13, 2020):
Good news.
@dmik commented on GitHub (Jan 14, 2020):
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):
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 commented on GitHub (Jan 14, 2020):
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 commented on GitHub (Jan 15, 2020):
@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 commented on GitHub (Jan 15, 2020):
@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 commented on GitHub (Jan 15, 2020):
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/:
Then something like
rpm -F *.rpmfrom 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
yuminstall), 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):