Re: Problem with configure when trying to build gcc 5.3

On 1/5/2017 12:07 PM, David Gressett wrote:
> 
>> From: Keith Marshall <[email protected]>
>> Sent: Wednesday, January 4, 2017 4:36 PM
>> To: [email protected]
>> Subject: Re: [MinGW-dvlpr] Problem with configure when trying to build gcc      5.3
> 
>> On 03/01/17 23:35, Keith Marshall wrote:
>>> I'm seeing evidence of an MSYS shell bug, which prevents mingw-pkg
>>> from even locating the package specification file:
>>>
>>> ... snip ...
>>>
>>> it has failed to match the 'case [0-9]*)' pattern, as it
>>> should have, and consequently, has set 'PACKAGE=gcc-5.3.0', where it
>>> should have been just 'PACKAGE=gcc'
> 
>> This issue appears to arise as a consequence of leaving the '-' in
>> $IFS;
> --- snip ...
> 
>> Today, I've pushed changes to circumvent this issue, and to correct
>> the previously identified 'mingw-pkg patch' defect, to my SF user
>> repository, so mingw-pkg should now work as originally suggested,
>> regardless of any host shell deficiencies.
> 
> I tried it and it worked perfectly for the patch; 
> however, I still have the problem with the ghost of .mingw-pkgrc
> that continues to haunt my build attempts by inserting
> --build=x86_64-pc-linux-gnu
> into my configure options. I have seen some evidence that this is
> part of a larger problem: some msys components are having
> problems with the Windows 10 file system. I found one
> problem when I was trying to build gcc 5.3.0 without
> mingw-pkg. Instead of doing a completely manual build,
> I modified Earnie's 4.8.1 build system. I set this up on
> my Windows C drive in C:/Build_gcc, which was
> /c/Build_gcc in msys. I found that when I used tee
> to copy stdout to ../make-patch.log that the resulting
> log file was invisible on the Windows side. A dir command in
> a cmd window could not list it and it was not visible
> in a Windows explorer window, but the msys ls could
> list it and rm could make it disappear. I moved everything
> down one level into a subdirectory of Build_gcc and
> the problem disappeared.
> 
> I suspect that my use of rm .mingw-pkgrc was not 
> completely successful and that it may have corrupted 
> the file system rather than removing the file, leaving
> a file that could be read but not listed.
> 
> I saw another possibly related problem with my
> build using Earnie's build system. I found that
> make prep, make patch, and make configure all
> apparently worked, but make stage did not work .
> 
> I saw errors like
> /bin/cp: cannot stat  stg/include/*': No such file or directory
> 
> make quit shortly after that, leaving an empty stg/include
> directory.
> 
> I saw that this build did create the Ada dll files but it
> did not give them the same names that I had
> set up in the makefile. I tweaked Earnie's makefile by
> replacing all instances of the string "4.8.1" with "5.3.0"
> and likewise changing "4.8" to "5.3". This gave me
> 
> ada_DLL_FILES = libgnat-5.3.dll libgnarl-5.3.dll
> 
> at line 66 in the makefile, but the build produced
> 
> libgnarl-5.dll and libgnat-5.dll

Sounds to me like you have what Cygwin calls "BLODA" going on.  Have you
tried with AV off or ignoring your work environment?

The one thing about ADA that I remember is that it required a previous
build of ADA to build the new one.  I'm sure there must be a bootstrap
process other than building via cross but it was beyond what I had time
to consider.

-- 
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot