search

msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.3k stars 1.22k forks source link

Upgrade to GCC8 for mingw32 #4818

Closed orgads closed 5 years ago

orgads commented 5 years ago

Hi,

I've noticed in addfba3f1e68a9d30398771069b92fb6e66e70d6 that gcc7 was added because:

gcc 8 can't be built for 32 bit

I just tried building it for mingw32 and it worked. Is this still relevant? Can it be upgraded for mingw32 too?

JPeterMugaas commented 5 years ago

I think it could be if it works.

stahta01 commented 5 years ago

It failed to build for me; failed in the Ada/Gnat section like it was said to fail.

Tim S.

orgads commented 5 years ago

Here is my log. Where does it fail for you?

stahta01 commented 5 years ago

`checking for i686-w64-mingw32-ranlib... (cached) /mingw32/i686-w64-mingw32/bin/ranlib checking command to parse /c/PKGBUILD/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/nm output from /c/PKGBUILD/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/c/PKGBUILD/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include object... /c/PKGBUILD/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/c/PKGBUILD/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include -c -g -O2 -W -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. xgcc.exe: internal compiler error: Aborted signal terminated program gnat1 Please submit a full bug report, with preprocessed source if appropriate. See https://sourceforge.net/projects/msys2 for instructions. make[6]: *** [../gcc-interface/Makefile:296: g-exptty.o] Error 4 make[6]: Leaving directory '/c/PKGBUILD/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc/ada/rts' `

orgads commented 5 years ago

Well, in my log it is fine. Are all your packages up-to-date? I ran it on a clean system with stock msys64 (mingw32 shell), after executing pacman -Syu.

checking for i686-w64-mingw32-ranlib... /mingw32/i686-w64-mingw32/bin/ranlib
checking command to parse /usr/src/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/nm output from /usr/src/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/usr/src/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include    object... /usr/src/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/usr/src/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include    -c -g -O2    -W -Wall -gnatpg -nostdinc   g-exptty.adb -o g-exptty.o
/usr/src/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/usr/src/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include    -c -g -O2    -W -Wall -gnatpg -nostdinc   g-flocon.ads -o g-flocon.o
Win32 ld.exe
checking how to hardcode library paths into programs... immediate
stahta01 commented 5 years ago

I ran pacman -Syuu twice; so, it is more likely your system was not up to date than mine. Or, it is a repo file path issue. Yours is under msys2; but, mine is not.

Tim S.

orgads commented 5 years ago

I also ran it twice.

Do you get these errors only for mingw32 but not for 64 on the same system?

Does anyone else get these errors?

Alexpux commented 5 years ago

@orgads this is only 32 bit build issue and many users get this error for a long time

lazka commented 5 years ago

8.3 is out: https://gcc.gnu.org/ml/gcc/2019-02/msg00121.html

lhmouse commented 5 years ago

It seems that nobody has been working on the Ada ICE.

oscarfv commented 5 years ago

@lhmouse : a few weeks ago an Ada maintainer looked at the problem but the conclusion was "this problem can't occur".

The interest of that Ada maintainer was prompted by some gcc users (including me) that cared about gcc being stalled at 7.x on mingw i686. AFAIR, no one expressed interest on Ada proper.

@Alexpux : Given that nobody really cares about Gcc/Ada on Windows, I propose releasing 8.3 for i686..

lhmouse commented 5 years ago

If Ada would be dropped it would be gone forever, because building Ada requires an Ada compiler.

oscarfv commented 5 years ago

@lhmouse : that's not quite true. We can archive the currently required binary packages to build Ada or we can cross-compile from GNU/Linux.

Since gcc 8 was released Ada is stuck on 7.x on i686 and completely missing on x86_64. I see no Ada users caring about that, I just see C/C++/Fortran i686 users who want to stay current with gcc releases.

Gcc 9 will be released on a few months and right now there is less hope than ever of fixing an arcane build problem which defeated the main Ada maintainer himself.

mingwandroid commented 5 years ago

There are many bits of gccs code base that handle 32 bit windows unique aspects such as the calling conventions.

Those bits will have rotted awfully I'm sorry to say!

lhmouse commented 5 years ago

@mingwandroid Ah nice to see you again. XD

oscarfv commented 5 years ago

@lhmouse : a few weeks ago an Ada maintainer looked at the problem but the conclusion was "this problem can't occur".

The interest of that Ada maintainer was prompted by some gcc users (including me) that cared about gcc being stalled at 7.x on mingw i686. AFAIR, no one expressed interest on Ada proper.

@Alexpux : Given that nobody really cares about Gcc/Ada on Windows, I propose releasing 8.3 for i686..

@Alexpux : ping

Gcc 9 will be released on a month and there is no sign of fixing this issue nor any interest from the Ada users, if they exist at all.

stahta01 commented 5 years ago

I am seeing if I can figure out this issue. But, the odds are against me. Tim S.

oscarfv commented 5 years ago

@stahta01 : apparently someone is building gcc 8 & 9 with Ada on a routine basis, at least for x86_64. I asked him about his special sauce here: https://gcc.gnu.org/ml/gcc/2019-03/msg00267.html

stahta01 commented 5 years ago

@stahta01 : apparently someone is building gcc 8 & 9 with Ada on a routine basis, at least for x86_64. I asked him about his special sauce here: https://gcc.gnu.org/ml/gcc/2019-03/msg00267.html

Building it with/for x86_64 is easy. Will read the link to see if it helps.

No information found at link!

Tim S.

oscarfv commented 5 years ago

Nevermind. I forgot that this affects i686 only.

stahta01 commented 5 years ago

I have decided that finding an MSys2 build issue is beyond me; now looking for an Ada code fix.

Edit: I am making progress. Edit2: About 150 git commits to test before I find the one that caused the error. About 5 hours to test each commit; testing by divide method.

Tim S.

revelator commented 5 years ago

noticed some differences in how libgcc is linked to the other libraries, might this be the problem ?.

lhmouse commented 5 years ago

You may try downgrading mingw-w64-{headers,crt}-git if you would like to.

oscarfv commented 5 years ago

@lhmouse : tried that time ago, no luck.

@revelator : can you describe those differences?

stahta01 commented 5 years ago

I am down to testing about a dozen git commits; I have tested 4 of them. Results one builds without error. And, the other 3 has three different errors. I am now working on fixing one of the errors; so, I can see when the error that is stopping 32 bit starts happening. The third error happens after the 32 bit build error. I hope to find the git commit causing the 32 bit build error this week. No idea, if I can fix the error till I find it.

Tim S.

oscarfv commented 5 years ago

Thank you. What do you mean with "Results one builds without error." ?

stahta01 commented 5 years ago

I am building using an edited gcc-git package to build selected commits. SVN 247295 builds with no error SVN 247301 builds with the 32 bit ADA error to be fixed after I patch it using part of SVN 247309. I am almost sure the bad code was added in SVN 247301; but, it is a very big commit. SVN 247309 builds without any new patch with the 32 bit ADA build error.

Tim S.

oscarfv commented 5 years ago

Wow, 247301 and 247309 are omnibus commits from Adacore. It is a shame that this type of practices are allowed on a critical project such as gcc.

Both commits contain eh-related stuff. Is the part of 247309 that fixes the build this one:

* raise-gcc.c: Don't use unwind.h while compiling
    for the frontend, but mimic host behavior.

?

stahta01 commented 5 years ago

The error is that it can not find the header tconfig.h And, that is fixed by part of 247309; it adds guards around the include and it changes the include path. After fixing the include error it then stops at the 32 bit Ada build error.

I am guessing the 32 bit Ada problem is in the SJLJ / Dwarf code; now the fact I have not seen any Dwarf changes is part of the reason I think it might be in that area.

Tim S.

oscarfv commented 5 years ago

Then 247301 fails to build because it can't find tconfig.h and 247309 fixes that problem and lets the build go forward until it crashes. Got it.

So you now are bisecting the changes on 247301 + 247309. That's a lot of time-consuming work indeed.

stahta01 commented 5 years ago

Correct, I am now trying to get SVN 247300 to build all the way; if I do, I will slowly adds parts of 247301 to it till I find the part that breaks it. If I fail to get 247300 to build, I will have to try earlier versions till I get one to build. I know 247295 builds and 247299 does not; so, I will have to try between those to find the most recent one that builds. Which could take several days. Both 247299 and 247300 have problems that happen after the 32 bit Ada problem happens, fails to find/make s-excmac.ads. The file s-excmac.ads is created from different files based on the Exception Handling type. I am starting to think that the file for 32 bit dwarf is wrong or does not exist.

SVN 247297 builds without error; Trying 247298 next. Could not get SVN 247300 to build without error. SVN 247298 with parts of SVN 247300 builds without error. Now going to tests SVN 247298 with parts of SVN 247299 and SVN 247301 added to it. I am almost done trying to locate the error; not that I found the error just that I am about ready to give up looking.

Tim S.

stahta01 commented 5 years ago

I am now trying to build using SJLJ instead of DWARF2. The errors and problems are different using SJLJ; when GCC builds it refuses to build using that build.

Tim S.

oscarfv commented 5 years ago

@stahta01 : a meta note: if you edit a previous message, no notifications are sent to those subscribed to the thread. Please create new messages instead to document your progress. Thanks.

stahta01 commented 5 years ago

I have given up. At this time I do not know enough to proceed. Tim S.

oscarfv commented 5 years ago

@stahta01 : thanks for trying. You identified the problematic commits, so your effort was not a waste of time.

orgads commented 5 years ago

Fixed in 0c60660b0cbb485fa29ea09a229cb368e2d01bae. Thanks.