Move details about C extension copying to IMPLEMENTATION_DETAILS

Author: timfel

docs/contributor/IMPLEMENTATION_DETAILS.md

@@ -302,3 +302,16 @@ checking the same `MANAGED_REFCNT` limit for all objects, the subsequent `Py_Dec
 call for this object will not detect that the reference should be made weak again!
 However, this is OK, it only prolongs the collection: we will make it weak again in
 the next run of the cycle GC on the native side.
+
+## C extension copying
+
+On Linux, Python native extensions expect to lookup Python C API functions in the global namespace and specify no explicit dependency on any libpython.
+To isolate them, we copy them with a new name, change their `SONAME`, add a `DT_NEEDED` dependency on a copy of our libpython shared object, and finally load them with `RTLD_LOCAL`.
+
+On Windows there is no global namespace so native extensions already have a dependency on our libpython DLL.
+We copy them and just change the dependency to point to the context-local copy of libpython rather than the global one.
+
+On macOS, while two-level namespaces exist, Python extensions historically use `-undefined dynamic_lookup` where they (just like in Linux) expect to find C API functions in any loaded image.
+We have to apply a similar workaround as on Linux, copy to a new name, change the `LC_ID_DYLIB` to that name, and add a `LC_LOAD_DYLIB` section to make the linker load the symbols from our libpython.
+
+Note that any code signatures are invalidated by this process.

docs/user/Native-Extensions.md

@@ -53,13 +53,4 @@ To support creating multiple GraalPy contexts that access native modules within
 The current strategy for this is to copy the libraries and modify them such that the dynamic library loader of the operating system will isolate them for us.
 To do this, all GraalPy contexts in the same process (not just those in the same engine!) must set the `python.IsolateNativeModules` option to `true`.
 
-On Linux, Python native extensions expect to lookup Python C API functions in the global namespace and specify no explicit dependency on any libpython.
-To isolate them, we copy them with a new name, change their `SONAME`, add a `DT_NEEDED` dependency on a copy of our libpython shared object, and finally load them with `RTLD_LOCAL`.
-
-On Windows there is no global namespace so native extensions already have a dependency on our libpython DLL.
-We copy them and just change the dependency to point to the context-local copy of libpython rather than the global one.
-
-On macOS, while two-level namespaces exist, Python extensions historically use `-undefined dynamic_lookup` where they (just like in Linux) expect to find C API functions in any loaded image.
-We have to apply a similar workaround as on Linux, copy to a new name, change the `LC_ID_DYLIB` to that name, and add a `LC_LOAD_DYLIB` section to make the linker load the symbols from our libpython.
-
-Note that any code signatures are invalidated by this process.
+For more details on this, see [our implementation details](https://github.com/oracle/graalpython/blob/master/docs/contributor/IMPLEMENTATION_DETAILS.md#c-extension-copying).