RSB build failed.

[Chris Johns]

On 10/2/20 10:19 am, Joel Sherrill wrote:
> 
> 
> On Sun, Feb 9, 2020, 5:07 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 10/2/20 9:40 am, Chris Johns wrote:
>     > On 10/2/20 8:25 am, Chris Johns wrote:
>     >> On 9/2/20 2:18 pm, jameszxj wrote:
>     >>> Hi,
>     >>>    RSB failed when build gdb on MINGW64.
>     >>>
>     >>> error messages:
>     >>>
>     >>>
>     D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>     >>> ada-tasks.o: in function `memcpy':
>     >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined
>     reference
>     >>> to `__memcpy_chk'
>     >>>
>     D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>     >>> arm-tdep.o: in function `memcpy':
>     >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined
>     reference
>     >>> to `__memcpy_chk'
>     >>>
>     D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>     >>> breakpoint.o: in function `strcpy':
>     >>> D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined
>     reference
>     >>> to `__strcpy_chk'
>     >>
>     >> I see this as well. I do not know what the cause it. It is documented in
>     the LSB
>     >> code specification so am wondering if something has changed to trigger this.
>     >
>     > Building gdb-9.1 works for ARM. I will post a patch to move RTEMS 5 to gdb-9.1
>     > once I have built arm, powerpc and sparc tool sets.
> 
>     It looks like mingw is broken ....
> 
>     x lrwxrwxrwx  0 root   root        0 Nov 08 20:34
>     sourceware-mirror-newlib-cygwin-d14714c69/newlib/libm/machine/x86_64/feclearexcept.c
>     -> ../../fenv/fenv_stub.c: Can't create
>     '\\\\?\\D:\\opt\\rtems\\rsb.git\\rtems\\build\\arg7ndxwm1\\sourceware-mirror-newlib-cygwin-d14714c69\\newlib\\libm\\machine\\x86_64\\feclearexcept.c'
> 
>     This is due to this change from Joel in newlib around 4 months ago...
> 
>     https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/blob/master/newlib/libm/machine/x86_64/fesetenv.c
> 
>     I though I added logic to the RSB to handle these cases but it looks like we
>     have another case that needs handling.
> 
> 
> Weird that a link from a tar isn't working.

This is Windows and there is no such thing. It is emulated as a copy.

>     The reason the failure happens is the destination directory for the link does
>     not exist and so the file copy fails. On Unix system the link is a path attached
>     to the node and so does not need to exist until you access it. The order in the
>     tar file means the link appears before the destination directory.
> 
> 
> Are there contents in the directory besides links? It no, adding a readme may help.

There are generated files and I was wrong before the source does not exist, ie
nothing to be copied.

> Otherwise, these may need to be created at configure time.
> 
> I honestly don't know the answer. We will have to discuss this on the newlib
> mailing list. There are multiple solutions and they have to buy one 

I think clang or gcc has some links that fail but I thought I had a fix for this
where bsdtar is run a second time on windows. I cannot seem to find it.

Chris