<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 18, 2017, at 9:13 AM, Geordie J via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello,<div class=""><br class=""></div><div class="">I’m trying to get the latest version of Foundation working on Android. Just looking to see if anyone has seen similar issues on other (esp. 32bit) platforms or on Android itself.</div><div class=""><br class=""></div><div class="">I made some minor changes: </div><div class="">– CoreFoundation/Base.subproj/CFSortFunctions.c to get e.g. __checkint_int32_mul working – the 32bit versions of those macros seem to be undefined (or incorrectly), so I renamed e.g. <b class="">__check_int32_mul</b> to <b class="">__checkint_int32_mul</b> etc.</div><div class="">– Added an <b class="">#if !defined(__ANDROID__)</b> check around the import of <b class="">#include <unicode/unumsys.h></b>.</div><div class="">– Added <b class="">#if defined(__ANDROID__) typedef unsigned short __swift_mode_t;</b> to LibcShims.h in the Swift repo. This is the change I’m least sure about – I have no idea why this is suddenly necessary, or even whether I’m defining the type correctly.</div><div class=""><br class=""></div><div class="">Other than that everything seems to build fine.</div><div class=""><br class=""></div><div class="">The issue is I’m getting a <span style="orphans: 2; widows: 2;" class="">signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)</span> in memmove/memcpy if I try something simple like this:</div><div class=""><br class=""></div><div class=""><div class=""><b class="">let nsDate = NSDate()</b></div><div class=""><b class="">print(nsDate)</b></div></div><div class=""><br class=""></div><div class="">/system/lib/libc.so (memcpy+140)</div><div class=""><div class="">.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:653</div><div class="">.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:442</div><div class="">.../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:449</div><div class="">.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1301</div><div class="">.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1326</div><div class="">.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:816</div><div class="">.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:824</div><div class="">.../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:860</div><div class="">.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:878</div><div class="">.../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:1052</div><div class="">.../swift-corelibs-foundation/Foundation/NSDate.swift:116</div></div><div class=""><br class=""></div><div style="orphans: 2; widows: 2;" class="">Apparently it crashes on a memmove trying to run CFDateFormatterCreate. Has anyone else seen this? Is it possible that memmove isn’t being linked correctly? I’d be grateful for any tips along these lines.</div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>My guess is that the memcpy is getting passed NULL or a bad pointer, can you attach gdb to the process? (One trick I have used in the past is to add a small C function called as the very first thing after loading the library that hot loops until a global is set and then once gdb is attached set the global to the value that will let the loop exit).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: 2; widows: 2;" class=""><br class=""></div><div style="orphans: 2; widows: 2;" class=""><br class=""></div><div style="orphans: 2; widows: 2;" class="">libDispatch seems broken too, but this is probably another issue. Running CFRunLoopRun() produces a <b class="">__HALT</b> trap with no further stack trace. This one is a signal 4 (SIGILL), code 1 (ILL_ILLOPC), which is normally an overflow or unwrapping a nil value. I guess I’ll try to compile a debug version of libdispatch to track this one further.</div></div></div></blockquote><div><br class=""></div>Again getting gdb in the mix here would be really helpful to understand what is going on.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: 2; widows: 2;" class=""><br class=""></div><div style="orphans: 2; widows: 2;" class=""><br class=""></div><div style="orphans: 2; widows: 2;" class="">I’d be grateful for any further info or tips! Thanks :)</div><div style="orphans: 2; widows: 2;" class="">– Geordie</div><div style="orphans: 2; widows: 2;" class=""><br class=""></div></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>