There are two platform functions that aren't accessible with the Linux targets; clone ( <https://man...

# kotlin-native

[napperley]

There are two platform functions that aren't accessible with the Linux targets; clone ( https://man7.org/linux/man-pages/man2/clone.2.html ) and unshare ( https://man7.org/linux/man-pages/man2/unshare.2.html ). Together these functions provide the basis for utilising Linux Namespaces ( https://man7.org/linux/man-pages/man7/namespaces.7.html ).

[ephemient]

setns() is also an important part of the Linux namespaces API

[ephemient]

if there's additional no runtime support needed, it'll just be a matter of adding defs to kotlin-native/platformLibs/src/platform/linux or your own project, right?

[napperley]

In the case of the two functions mentioned above ☝️ there is a macro that need to be defined:

#define _GNU_SOURCE

Defining the macro in the def file has no effect, therefore no mapping files are generated (aka no access to the clone, unshare and other functions that are part of the Linux Namespaces API - defined in sched.h).

[napperley]

Looks like any platform function that requires the _GNU_SOURCE macro to be defined isn't usable from a Kotlin Native program 😦.

[ephemient]

compilerOpts = -D_GNU_SOURCE

in the cdef?

[napperley]

Was referring to this in the def file:

headers = sched.h

---
#define _GNU_SOURCE
#include <sched.h>

[napperley]

Here is some context on the weird __GNU_SOURCE macro:_ https://stackoverflow.com/questions/5582211/what-does-define-gnu-source-imply

[napperley]

I'm wondering if the macro has something to do with swapping the POSIX implementation for the GNU (glibc?) implementation 🤔.

[ephemient]

I know what it means, but compilerOptions is the right way to set CPP macros for Kotlin

[napperley]

Macros also apply to C as well. All the Linux platform APIs are C based.

[ephemient]

they do, but Kotlin parses the headers itself and that's how to set macros for that stage

[napperley]

For some reason the GNU functions aren't being pulled in as part of the cinterop process when the _GNU_SOURCE macro is defined. The generated gnm file is barren 💫.

[napperley]

With a search in the .konan directory there are multiple matches for the sched.h file. Which of these files should be used?

[napperley]

Here is the matching header file for the linuxX64 target.

sched.h

[napperley]

Here is another header file (with the same name), which contains the definitions for the unshare, and clone functions. @Pavel Kunyavskiy [JB] Looks like the __USE_GNU macro needs to be defined first to access these functions; can it be done without the use of a def file?

sched.h

[ephemient]

actually as far as I can tell, konan is already setting _GNU_SOURCE by default

[ephemient]

this makes platform.sched.getcpu() available even though sched_getcpu() is only defined when _GNU_SOURCE, for example

sched.def.txt

[ephemient]

the question is why the parser isn't picking up the original declaration, not whether the define works

[ephemient]

overlap with the built-in posix.def maybe?

[napperley]

It is surprising that sched_getcpu is accessible in the C code (within the def file) without having to include the header file.

[napperley]

The depends option doesn't seem to be documented anywhere. What does it do exactly?

[ephemient]

headers = sched.h is including the header file

[ephemient]

depends does exactly what it sounds like, so that posix types can be used