Repository navigation
x86/Linux progress #7335
Description
This issue for tracking x86/Linux progress with respect to the regression tests.
Here is the current status on Ubuntu 14.04 Docker Container (on Ubuntu 16.04 x64) and full result:
=======================
Test Results
=======================
# CoreCLR Bin Dir :
# Tests Discovered : 7027
# Passed : 5592
# Failed : 1156
# Skipped : 279
=======================
The above result comes from 63607d8 with https://github.com/parjong/coreclr/tree/fix/x86_4byte_alignment and dotnet/coreclr#9261.
Reacted by Hanjoung Lee, Shahid Khan, Hugh Bellamy, SaeHie Park, Sung-Jae Lee, Evgeny Pavlov, Evgeny Gavrin, Bruce Forstall, KSE, Unknown6656 and 28 more
Reacted by Jan Kotas, Shahid Khan, Sergey Khabibullin, cocowalla, Daniel, Sergey Pechenik and Guy L
Activity
parjong commentedon Feb 2, 2017
\CC @seanshpark @wateret
parjong commentedon Feb 3, 2017
63607d8 (with alignment workaround) shows the following result:
dotnet/coreclr#9121 seems to resolve GC and JIT related failures.
parjong commentedon Feb 10, 2017
Here is the result from 2ecadf5 (without any additional patch):
Recently merged dotnet/coreclr#8849 eliminates the need for alignment workaround. There is a small increase in the number of failed tests, and most of them are caused by stack smashing. Incorrect funclet prolog/epilog may cause this stack smashing issue.
janvorli commentedon Feb 17, 2017
@parjong, @seanshpark, @wateret - I was trying to build and run dotnet for x86 Linux today, using the current state of the master branch, but I was unable to make it work. So I was wondering if you could share a list of steps to successfuly build and gather all parts of the dotnet core the way you do it.
I have tried to build the coreclr and corefx native binaries both using the cross build and a build inside of a docker container with x86 ubuntu 14.04 (running the container on x64 Ubuntu 14.04). I have built the corefx managed assemblies on my x64 ubuntu.
When I try to run a simple hello world like app inside of the docker container, I get a strange assertion in the native runtime even before the coreclr_initialize completes.
parjong commentedon Feb 17, 2017
@janvorli It is a bit strange. I have used the same environment (docker container from docker image imported from x86/rootfs in Core CLR). Could you let me know the assert failure that you got?
parjong commentedon Feb 17, 2017
And, I am currently using a bit old Core FX (although I am not sure whether it is relevant).
janvorli commentedon Feb 17, 2017
The assert and call stack is below. I guess it has to do something with how I've collected all the files. I have created the docker image myself from vanilla Ubuntu 14.04 x86 image and installed all the dependencies, clang, etc.
Could you please write down a step by step list of how to get a working environment from scratch?
parjong commentedon Feb 17, 2017
I'll first check whether master works for me.
parjong commentedon Feb 17, 2017
To collect Core FX managed dll(s), I used a bit old collecting script of the following form (
OSisLinux):parjong commentedon Feb 17, 2017
Here is the brief steps that I am currently using:
janvorli commentedon Feb 17, 2017
@parjong thank you. These match the steps I have done. I guess I'll try to create the docker image from the rootfs as you've said you did to see if it makes any difference.
parjong commentedon Feb 17, 2017
@janvorli Please let me know if there is any problem. I checked the current tip (7f3a87a) and it works for me.
janvorli commentedon Feb 17, 2017
@parjong it is weird. I have just deleted the whole bin folder in coreclr, rebuilt the sources one more time and now it works. I am sorry for wasting your time.
Btw, I have not specified the "-DSKIP_LLDBPLUGIN=true" and the libsosplugin.so was also built fine.
parjong commentedon Feb 17, 2017
@janvorli Thanks you for check 👍
FYI,
-DSKIP_LLDBPLUGIN=truewas just a workaround during bring up, but remains unchanged as lldb-plugin is not used currently.parjong commentedon Feb 20, 2017
Here is the result (XML) from b957f8c:
87 remaining items
ikkentim commentedon Mar 21, 2022
What is the current status of this?
I've tried to cross build
release/6.0andmainfor x86 but I couldn't get it to run a simple hello world.Has anyone managed to build a usable .net 6/7 for linux-x86?
weltkante commentedon Mar 21, 2022
I don't think it was .NET 6, the last working cross compile has been a long time ago, as reported earlier on this thread, and only the runtime not the full SDK. The above regression is still present as of a few months ago when I last tried.
gbalykov commentedon Mar 22, 2022
.net6 (at least
v6.0.0) and .net7 (main) runtime cross builds for linux x86 successfully right now. Build command for .net7:sudo ./eng/common/cross/build-rootfs.sh x86 bionic ROOTFS_DIR=`pwd`/.tools/rootfs/x86 ./build.sh --cross --clang9 --arch x86 --runtimeConfiguration Release --librariesConfiguration Release --subset clr.hosts+clr.runtime+clr.jit+clr.corelib+clr.iltools+libs.native+libs.sfx+libs.oob+libs.packagesTo pack artifacts:
mkdir runtime_x86 cp artifacts/bin/coreclr/Linux.x86.Release/{corerun,ilasm,ildasm,*.so} runtime_x86 cp artifacts/bin/coreclr/Linux.x86.Release/IL/System.Private.CoreLib.dll runtime_x86 cp artifacts/bin/native/net7.0-Linux-Release-x86/*.so runtime_x86 cp artifacts/bin/microsoft.netcore.app.runtime.linux-x86/Release/runtimes/linux-x86/lib/net7.0/*.dll runtime_x86I've not tested .net7, but .net6 runs simple helloworld successfully.
ikkentim commentedon Mar 23, 2022
@gbalykov I'm on branch release/6.0. Subsets
clr.hosts libs.sfx libs.oobare not available here so I've builtclr.runtime+clr.jit+clr.corelib+clr.iltools+libs.native+libs+libs.packagesinstead. But I'm getting segmentation faults when running a helloworld. Do you have any suggestions for how I can try to fix this?gbalykov commentedon Mar 24, 2022
I've checked current main (7d1191e) and it segfaults on xubuntu 18.04 i386 on simple helloworld.
However,
v6.0.0tag works, but I forgot to mention that you'll also need next patches for.net6to fix some linux x86 related issues:Just for reference, to build runtime I use:
ikkentim commentedon Mar 24, 2022
Thanks! With those patches tag
v6.0.3also works.ta264 commentedon Apr 14, 2022
With the above 3 patches, and this one also:
#68046
I can build a complete SDK for linux-x86 which seems to be functional.
The build pipeline, SDKs for .NET 6 and .NET 7 preview 3, and a Nuget feed with the AppHosts etc are here:
https://github.com/Servarr/dotnet-linux-x86
Adinihal commentedon Jan 31, 2024
Hi @ta264,
actually I am completely new to linux , but I got a requirement for running a 32bit console app in linux as this we can run can you please tell me the steps for this how can I create a build of this Linux-x86 in my ubantu and run a simple .net 32 bit console application,
thanks
weltkante commentedon Jan 31, 2024
@Adinihal just to make sure you didn't miss the main point of the thread, 32bit Linux is (intentionally) not supported by Microsoft but put together by the community, so if your "requirement" implies having support when things break then its better to reject the 32bit requirement as "not supported by Microsoft" rather than putting yourself into a bad spot where you'll have to learn the hard way how to do things yourself. Making an unsupported runtime work on a new (for you) system is not exactly an easy project to get started with Linux. (Just a friendly advice if you didn't read the thread and weren't aware.)
josephmoresena commentedon Aug 20, 2024
Is there any progress on this? @ta264 Does NativeAOT work with this?
nsobiratel commentedon Aug 28, 2025
Hi. Can u help? i try use release build, but cannot install nupkg with error "NETSDK1082 There was no runtime pack for Microsoft.NETCore.App available for the specified RuntimeIdentifier 'linux-x86'. VS 2022. Or required only linux host with installed sdk from release? Can u write all requirements (or steps) to use it?
package manager output contain lines:
Delete linux-x86 code and infra (dotnet#137008)