RSB build failed.

[Joel Sherrill]

On Sun, Feb 9, 2020, 5:07 PM Chris Johns <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.

>
> 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.

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

>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200209/10b52726/attachment.html>