It's not too hard to figure out (and there are a couple of other ObjC
implementations) but if Apple have any specs for the archive format, I would be
keen to take a look.
Also regarding interoperability - perhaps it might be reasonable, for
non-Foundation classes that have non-namespaced names
First we can't use HAVE_MACH which isn't namespaces in a system header. Second
we don't want to ship configure.h either anyway.
Last we discussed with Daniel about that already and we'll probably end up
having things based on __have_include() eventually. So for now __APPLE__ will
do in headers.
> Somewhat; the mangled symbols are technically searchable by dlsym but that
> seems like a hack. Perhaps one of the stdlib/compiler team might be able to
> speak more on this than myself and they may have suggestions for a better
> way. Foundation is at a special spot in which we can sometimes
+ swift-dev, Jordan
On Sun, Dec 20, 2015 at 2:21 AM, Dan Stenmark via swift-corelibs-dev
wrote:
> I'm trying to invoke Linux's unshare() system call from Swift, but without
> much success. From C, it requires _GNU_SOURCE to be #define'd before the
> #include . The Glibc module map does indeed
I'm trying to invoke Linux's unshare() system call from Swift, but without much
success. From C, it requires _GNU_SOURCE to be #define'd before the #include
. The Glibc module map does indeed include sched.h, so the lack of
_GNU_SOURCE appears to be the likely culprit. What's the appropriate
