Re: Problem with configure when trying to build gcc 5.3

>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







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