m2005 untar error on msys2 (tar01 directory)

[Sebastian Huber]

On 05/05/2020 12:38, Chris Johns wrote:

>> On 5 May 2020, at 6:25 pm, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 05/05/2020 09:48, Chris Johns wrote:
>>
>>>>>> It is currently busy building the 5/rtems-sparc build set (without GDB) in a mingw64 shell. Is a build in the msys shell something useful/supported?
>>>>> Yes, we have valid users. Plus building on Windows is valid for the same reasons we build from source on all hosts maybe more so.
>>>> If I install msys/mingw I get an msys, mingw32 and mingw64 shell. They are all somewhat different. Are all of them supposed to be supported?
>>> They are different in a subtle way, they set different paths so you get a different set of native executables and DLLs in your path. Run:
>>>
>>>   `set | grep ^PATH`
>>>
>>> in each instance and compare. On top of that the mingw native tools are specifically named, something I completely agree with.
>>>
>>> MSYS2 is well thought out, the pacmac tools is great. Like cygwin a rolling release makes baselining for deployment or a product hard.
>> Yes, but should RTEMS build on all three shells? Which one is recommended?
> Ah ok, sorry I did not understand. We want the best executables we can get so this is MINGW64. The 64bit build should have the bests  performance. And we want native executables as the API interface is direct. If you want MSYS then use Cygwin. It is the fully featured parent project.

Ok, so I will focus my testing on the mingw64 shell only.

With the GDB build disabled I was able to build the tools for sparc. I 
wanted to test if the tar01 test works on mingw64, however, it is 
disabled by configure:

AM_CONDITIONAL(TARTESTS,test "$as_ln_s" = "ln -s" && test -n "$PAX" && 
test -n "$GZIP")

We had several discussions in this area. My point is still that the 
RTEMS tests should not depend on host computer capabilities. I would 
simply check in the archives which require extraordinary and super 
sophisticated features like symbolic links.