On 10/2/20 10:19 am, Joel Sherrill wrote: > > > On Sun, Feb 9, 2020, 5:07 PM Chris Johns <chr...@rtems.org > <mailto:chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
