Imported Upstream version 5.2.0.175

Former-commit-id: bb0468d0f257ff100aa895eb5fe583fb5dfbf900

external/corefx/Documentation/building/cross-building.md

@@ -103,3 +103,24 @@ prajwal@ubuntu ~/corefx $ ./scripts/arm32_ci_script.sh \
 ```
 
 The Linux ARM Emulator is based on the soft floating point and thus the native binaries are generated for the armel architecture. The corefx binaries generated by the above command can be found at `~/corefx/bin/Linux.armel.Release`, `~/corefx/bin/Linux.AnyCPU.Release`, `~/corefx/bin/Unix.AnyCPU.Release`, and `~/corefx/bin/AnyOS.AnyCPU.Release`.
+
+
+Build corefx for a new architecture
+===================================
+
+When building for a new architecture you will need to build the native pieces separate from the managed pieces in order to correctly boot strap the native runtime. Instead of calling build.sh directly you should instead split the calls like such:
+
+Example building for armel
+```
+build-native.sh -buildArch=armel
+--> Output goes to bin/runtime/netcoreapp-Linux-Debug-armel
+
+build-managed.sh -buildArch=x64
+--> Output goes to bin/runtime/netcoreapp-Linux-Debug-x64
+```
+
+The reason you need to build the managed portion for x64 is because it depends on runtime packages for the new architecture which don't exist yet so we use another existing architecture such as x64 as a proxy for building the managed binaries.
+
+Similar if you want to try and run tests you will have to copy the managed assemblies from the proxy directory (i.e. `netcoreapp-Linux-Debug-x64`) to the new architecture directory (i.e `netcoreapp-Linux-Debug-armel`) and run code via another host such as corerun because dotnet is at a higher level and most likely doesn't exist for the new architecture yet.
+
+Once all the necessary builds are setup and packages are published the spliting of the build and manual creation of the runtime should no longer be necessary.