Closed rockcavera closed 3 days ago
Another question: how necessary is it to update the toolchain?
The little I know would be the last thing to update in a script like this, which intends to build several versions of gcc.
@rockcavera
hello! im sorry for the delay.
thank you for your attention!
for the first post: you are right, that is a known trouble with mingw-builds projects. but I have no idea how to solve such troubles conveniently... maybe you have some ideas?
Another question: how necessary is it to update the toolchain?
are you talking about a toolchain used as host compiler?
I don't have a suggestion. What could be done, at least for those who use it and want to investigate why a previous version broke, is to create a file in the repository, lastcommitbuilt.md
for example, pointing to gcc vx.x.x and the hash of the last one commit which compiled correctly. It can be a starting point for a contribution with corrections in the model that the current script is, considering that script debugging can be very time consuming.
are you talking about a toolchain used as host compiler?
Yes, I'm talking about the host compiler, which is in "config-win.sh".
I needed to build gcc 5.5.0. I have used your excellent script before with success in the past.
So, I cloned the repository and tried to do the build process and an error occurred, the same one reported here. I decided to investigate and created a patch for it. The problem passed, but new errors appeared, from possible incompatibilities of the previous gcc code with the toolchain using 12.2.0. I decided to use gcc 4.9.4 for construction and OK. The error was now building Python 3 with the old gcc. At this point I gave up on that approach in trying to fix bugs in devel.
I then looked for something that would indicate the last known successful build of gcc 5.5.0. I found commit f649dac583022531a8b6327ca3808aa722006e81. I regressed to it and built gcc 5.5.0 after correcting the links to expat and isl.
Well, I have proven with tests that changing the toolchain causes regressions in the build. Another regression that I assume has to do with this error was introduced in this commit 90a668365177f54a801964dfea26cf3405c0410a, but I didn't get to test it.
After saying all that, I believe the best way to control regressions would be to keep a file indicating the commit that each version was built correctly to facilitate the correction.
I verified that there is a choice of dependency versions according to the built version. This could be done with the toolchain as well.