Re: [Msys2-users] MSYS2 build of sparc-rtems4.11

[Chris J. <ch...@rt...>]

On 12/02/2015 1:17 am, David Macek wrote:
> On 11. 2. 2015 6:55, Chris Johns wrote:
>> The issue is not repeatable so I
>> have builds that do not fail here and then builds that do. I am using
>> '-j 2' on the build.
>
> I definitely suggest trying with `-j 1`. I remember seeing some problems with parallel builds, that may or may not have been resolved.
>

The first test run seems to have passed so 1 from 1. I will keep and eye 
on this.

Moving on to something else. I have hit a new or actually old issue. 
Using MSYS2's mingw64/python2 package to run the RSB I see the win32api 
path length hack of fails:

   shutil.copy2("\\\\?\\" + srcname, dstname)

while this works with the python.org's MSI installed python. GCC has 
long paths in the C++ (and Java) source and headers. Using python.org 
works with this workaround however it fails building gdb with 
--with-python because mingw64 does not like the .lib files it supplies. 
I see hacks to convert the .lib file and I may look at that but I wanted 
to try an all MSYS2 solution first. The idea of a pacman install all 
used to build the tools is attractive. Any hints on this one ?

>> unable to rename '.libs/libsupc++.a'; reason: Permission denied
>
> This looks like another process is keeping the file open, mostly likely an anti-virus. Try disabling any anti-virus, anti-malware and disk indexing software.
>

Hmm interesting. The code in binutils to handle this is very simple 
maybe too simple. It is Windows specific. I may patch ar to add some 
more error diag messages to see if I can isolate the source of the 
problem a little more. One thought is the source of the new archive file 
name in ar and how unique it is. It would resolve the perm and corrupt 
file issue and I have seen both in the same part of the gcc build with 
the same tool.

Chris