Linux x86 builds (or documentation for it)

[weltkante]

It's been a longstanding issue that there are no x86 builds for linux, even though it technically is already (supposedly) possible, closed issues in corefx and coreclr exist with people reporting they have build it - they even have documents how to cross compile - unfortunately nobody ever bothered to document how this works on a big scale, how to produce a full build usable for creating x86 applications.

I've been pointed by @jkotas from dotnet/coreclr#9265 to this repo since it integrates the build of the individual repos, but haven't been able to sucessfully build anything yet.

What I have tried before source-build (this was pre-3.0, around half a year ago):

• I'm using Ubuntu 16.04 x86_64 in a VM
• I'm able to build corefx and coreclr individually following their documentation
• I can cross-compile coreclr for x86 following their documentation
• I fail to create a custom corefx build because there is no documentation how to feed it the custom coreclr build
• I didn't even attempt to build anything past corefx yet

What I've tried with source-build:

• the only document talking even remotely about the topic of creating a build for a non-official RID is the bootstrap documentation
• the bootstrap documentation is not easy to follow for the usecase of creating a Linux x86 build, in particular setting up a working seedcli took a lot of trial and error
  • the document says it expects the seedcli to use the same architecture as the target build, so I tried using a win-x86 one but that didn't work out
  • then I read the whole document and realized at the end it explained how to build for different architectures, so I tried using linux-x64 as seedcli; this failed as well when following the recommendation of picking the version from DotnetCLIVersion.txt - it complains about missing NuGetFallbackFolder, even after running dotnet new console with the seedcli (which fills the NuGetFallbackFolder) it has the same error
  • ignoring the recommendation and just picking a 3.0 preview7 sdk as seedcli allows to get a bit further, now it starts compiling things but fails with coreclr, missing the --cross flag

I could probably try to create a plain x86 VM instead of x86_64 but I think I have tried that before (but not with source-build) and was running out of memory in some build step. I'll definitely try it when I get time for it over the weekend, but I thought to report back earlier in case I'm missing something important. (it's been suggested to use rootfs instead)

Anyways, my request is, if there's not going to be official Linux x86 builds it would be great if it would be at least possible to do custom builds - or if its too complicated to integrate into the tooling, at least document how to do them. I guess someone must have tried it?

(Background: x64 builds of .NET Core require 2x the memory so they require paying for additional RAM when deploying .NET Core applications instead of Mono applications. This has been a blocker on fully migrating to .NET Core for years.)

[omajid]

Background: x64 builds of .NET Core require 2x the memory so they require paying for additional RAM when deploying .NET Core applications instead of Mono applications. This has been a blocker on fully migrating to .NET Core for years.

Is this something that compressed pointers might help with? They have been used with some degree of success in Java and v8. Is there something similar planned in .NET Core?

[weltkante]

@janvorli mentioned on the linked coreclr issue

you don't need a pure x86 Ubuntu to build. You can use cross compilation - first build rootfs using the eng/common/cross/build-rootfs.sh script for x86 (run it on x64) and then use it for cross compiling.

So I'll be trying that instead of setting up a x86 VM for building and see if the output happens to be an x86 build. I'll have to note though that how to cross compile via source-build isn't documented at all. I found someone dropping ./build.sh /p:Platform=arm in a comment so I'll try it for x86 after doing the rootfs and see if that produces anything, but again: this switch/property isn't documented either for the scripts

Regarding the comment from @omajid

Is this something that compressed pointers might help with? They have been used with some degree of success in Java and v8. Is there something similar planned in .NET Core?

Welll, it could probably reduce the pain, but considering that x86 builds are already supposed to work and just aren't documented, I'd prefer getting them working instead of waiting month to years for an implementation of compressed pointers in .NET Core ...

[dseefeld]

Thanks for filing this issue. x86 is not currently active within source-build. We need to improve our documentation regarding this and bootstrapping.

[weltkante]

x86 is not currently active within source-build

Well, it seemed some people worked on it, as I found #680 and #684 but it has no indication how far they got or whether it was working on some point.

Anyways, reporting back from my attempt of building with rootfs, I tried

• ./cross/build-rootfs.sh x86 xenial
• ./build.sh /p:Platform=x86

I'm getting apparently kinda far through the build to Writing package usage data... which takes very long and fails with out of memory, killing process dotnet due to needing around 17 GB memory. I currently don't have a machine with more RAM around so I'm giving up for now. (I don't even know if what I'm doing would result in a valid x86 build in the first place.)

If someone has further hints or knows how to do this I'll try again.

[ntindle]

I have a server that it can run on if you can Run what you need. I don’t know how to help but I need this downstream

[deinok]

@weltkante If your issue is not having enough RAM, I can build the code for you (with your instructions), I have 32GB of RAM.
I could try to give you SSH access to it. Contact me via email if you need it.

[weltkante]

No, the issue is that the scripts don't work. Cross compiling on an x64 machine against x86 works just fine for the dotnet runtime repo, but building the SDK fails because the scripts were not maintained. It's been a while so maybe things changed and the issue was not updated?

[edit] sorry, looking up in the history of this issue I see that I'm mixing up things. The scripts that weren't working were probably in a different repo. I don't know what doesn't work with this repo, I'll try it again later today. My guess would be lack of documentation and I was invoking the build incorrectly.

If you want to try yourself, I did post the commands I tried above.

[deinok]

I will try to generate a working corerun and see if it is able to execute something. The comands are for "runtime" repo or for "source-build"?