Created attachment 39621 [details] Log file as specified in "please report a bug" This failure appears to be Windows version dependent, but it provokes "please report a bug." It's possible to cd into libgfortran and configure and build, but the gfortran build is faulty as the script reports. Attaching config.log as requested.
Error message (from the logfile): configure:15660: checking whether the GNU Fortran compiler is working configure:15673: /cygdrive/c/Users/tim/gnu/gcc/cyg64/./gcc/gfortran -B/cygdrive/c/Users/tim/gnu/gcc/cyg64/./gcc/ -B/usr/local/gcc7/x86_64-unknown-cygwin/bin/ -B/usr/local/gcc7/x86_64-unknown-cygwin/lib/ -isystem /usr/local/gcc7/x86_64-unknown-cygwin/include -isystem /usr/local/gcc7/x86_64-unknown-cygwin/sys-include -c conftest.f >&5 Cygwin runtime failure: /cygdrive/c/Users/tim/gnu/gcc/cyg64/gcc/f951.exe: Invalid relocation. Offset 0x2feaf09a3 at address 0x1004b8179 doesn't fit into 32 bits configure:15673: $? = 1 configure: failed program was: | | program foo | real, parameter :: bar = sin (12.34 / 2.5) | end program foo configure:15677: result: no configure:15679: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /cygdrive/c/Users/tim/gnu/gcc/cyg64/x86_64-unknown-cygwin/libgfortran/config.log
I suspect the Windows 10 provided svn may be partly at fault (although it works for bootstrapping on the Microsoft provided gcc in linux subsystem). I grabbed trunk using cygwin svn and have seen the bootstrap go as far as the stage3 libstdc++ build (without intervention) before jumping back to stage1 and failing on permissions to move into stage1-gcc.
Not a GCC bug.
Same failure of f951 after checking alternate svn apps.
Tim, can you grab a clean copy of trunk (from a Linux box or from whereever), cooy that to your Windows machine and try again?
(In reply to Thomas Koenig from comment #5) > Tim, can you grab a clean copy of trunk (from a Linux box or from > whereever), cooy that to your Windows machine and try again? Thomas, do you have bootstrap working? I have it building without bootstrap, but I am totally unclear about some of the configure parameters, when I tried some of the odd ones used by the Cygwin released 5.4 I could not get through stage 1
The bootstrap was working for me on Windows 8.1 the last few days although it had been broken for a month or 2. The symptom was that file edits made during build were being dropped or the files from various stages were mixed (although ok after build stopped). Not the same as this corrupt f951. I am away from my win10 and linux machines and have insufficient internet access but I think I ruled out any difference between the Linux and cygwin svn drops. By the way I haven't seen any internet installer vans this trip. Sent via the ASUS PadFone X mini, an AT&T 4G LTE smartphone -------- Original Message -------- From:"jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> Sent:Fri, 16 Sep 2016 16:41:45 -0400 To:tprince@computer.org Subject:[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 > >Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |jvdelisle at gcc dot gnu.org > >--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- >(In reply to Thomas Koenig from comment #5) >> Tim, can you grab a clean copy of trunk (from a Linux box or from >> whereever), cooy that to your Windows machine and try again? > >Thomas, do you have bootstrap working? > >I have it building without bootstrap, but I am totally unclear about some of >the configure parameters, when I tried some of the odd ones used by the Cygwin >released 5.4 I could not get through stage 1 > >-- >You are receiving this mail because: >You reported the bug.
I show my configure parameters in my test results posts. At some time in the past, each of them has been important. I don't know if the parameters quoted by cygwin release pertain to cross compiling. As the parameters I use have been successful again last week on win8.1 I don't see how they might pertain to the f951 bootstrap failure on win10. When I get back to the win10 box I will compare with disable bootstrap.
(In reply to tprince from comment #8) > I show my configure parameters in my test results posts. At some time in > the past, each of them has been important. I don't know if the parameters > quoted by cygwin release pertain to cross compiling. As the parameters I > use have been successful again last week on win8.1 I don't see how they > might pertain to the f951 bootstrap failure on win10. When I get back to > the win10 box I will compare with disable bootstrap. Tim, using your parameters I was able to build. I proceeded to do a regression hunt and confirmed that it was at the DTIO patch on 8/31/2016. In this patch we added two new functions to libgfortran and set the symbol versioning. I modified the library by inserting a printf("ping\n") in the code path for a simple program. print *, "hello" end The ping does not show which means the wrong library is being used at run time. I am trying various config and bath settings to see if I can sort it out. No luck so far.
Jerry , Thanks for the efforts and apparent progress. I will return to wired internet territory and the win10 box next weekend. I have the win8.1 laptop here. Sent via the ASUS PadFone X mini, an AT&T 4G LTE smartphone -------- Original Message -------- From:"jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> Sent:Sun, 25 Sep 2016 15:03:55 -0400 To:tprince@computer.org Subject:[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 > >--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- >(In reply to tprince from comment #8) >> I show my configure parameters in my test results posts. At some time in >> the past, each of them has been important. I don't know if the parameters >> quoted by cygwin release pertain to cross compiling. As the parameters I >> use have been successful again last week on win8.1 I don't see how they >> might pertain to the f951 bootstrap failure on win10. When I get back to >> the win10 box I will compare with disable bootstrap. > >Tim, using your parameters I was able to build. I proceeded to do a regression >hunt and confirmed that it was at the DTIO patch on 8/31/2016. > >In this patch we added two new functions to libgfortran and set the symbol >versioning. I modified the library by inserting a printf("ping\n") in the code >path for a simple program. > >print *, "hello" >end > >The ping does not show which means the wrong library is being used at run time. > >I am trying various config and bath settings to see if I can sort it out. No >luck so far. > >-- >You are receiving this mail because: >You reported the bug.
I returned to attempts to build trunk on win8.1. Initial bootstrap of c++ is failing, attempting (unsuccessfully!) to build eh_arm. I filed pr 77814 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77814> On 9/25/2016 3:03 PM, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 > > --- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- > (In reply to tprince from comment #8) >> I show my configure parameters in my test results posts. At some time in >> the past, each of them has been important. I don't know if the parameters >> quoted by cygwin release pertain to cross compiling. As the parameters I >> use have been successful again last week on win8.1 I don't see how they >> might pertain to the f951 bootstrap failure on win10. When I get back to >> the win10 box I will compare with disable bootstrap. > Tim, using your parameters I was able to build. I proceeded to do a regression > hunt and confirmed that it was at the DTIO patch on 8/31/2016. > > In this patch we added two new functions to libgfortran and set the symbol > versioning. I modified the library by inserting a printf("ping\n") in the code > path for a simple program. > > print *, "hello" > end > > The ping does not show which means the wrong library is being used at run time. > > I am trying various config and bath settings to see if I can sort it out. No > luck so far. >
On 9/25/2016 3:03 PM, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 > > --- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- > (In reply to tprince from comment #8) >> I show my configure parameters in my test results posts. At some time in >> the past, each of them has been important. I don't know if the parameters >> quoted by cygwin release pertain to cross compiling. As the parameters I >> use have been successful again last week on win8.1 I don't see how they >> might pertain to the f951 bootstrap failure on win10. When I get back to >> the win10 box I will compare with disable bootstrap. > Tim, using your parameters I was able to build. I proceeded to do a regression > hunt and confirmed that it was at the DTIO patch on 8/31/2016. > > In this patch we added two new functions to libgfortran and set the symbol > versioning. I modified the library by inserting a printf("ping\n") in the code > path for a simple program. > > print *, "hello" > end > > The ping does not show which means the wrong library is being used at run time. > > I am trying various config and bath settings to see if I can sort it out. No > luck so far. > Jerry, They fixed the blocking update in trunk libstdc++ yesterday. In order to build libgfortran, I #if'd out the __MINGW64_VERSION_MAJOR section in intrinsics/random.c (not having received any advice about this). gfortran testsuite for cygwin/win8.1 is hanging on some of the arrayio tests which I am having to kill by Task Manager. If I try to use any parallel method for testsuite, there are pipe failures, so I guess the cygwin implementation of pipes remains non thread-safe. I had no trouble completing gfortran testsuite in Windows 10 Ubuntu subsystem (it skipped many tests), but it remains relatively easy to hang the entire linux subsystem, requiring a full Windows reboot.