Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x86/Linux progress #9265

Open
parjong opened this issue Feb 2, 2017 · 80 comments
Open

x86/Linux progress #9265

parjong opened this issue Feb 2, 2017 · 80 comments

Comments

@parjong
Copy link

@parjong parjong commented Feb 2, 2017

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 #9261.

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 2, 2017

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 3, 2017

63607d8 (with alignment workaround) shows the following result:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 5892
# Failed           : 856
# Skipped          : 279
=======================
53 minutes and 59 seconds taken to run CoreCLR tests.

#9121 seems to resolve GC and JIT related failures.

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 10, 2017

Here is the result from 2ecadf5 (without any additional patch):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 5874
# Failed           : 874
# Skipped          : 279
=======================
65 minutes and 29 seconds taken to run CoreCLR tests.

Recently merged #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

This comment has been minimized.

Copy link
Member

@janvorli janvorli commented 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

This comment has been minimized.

Copy link
Author

@parjong parjong commented 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

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 17, 2017

And, I am currently using a bit old Core FX (although I am not sure whether it is relevant).

@janvorli

This comment has been minimized.

Copy link
Member

@janvorli janvorli commented 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?

Assert failure(PID 59096 [0x0000e6d8], Thread: 59096 [0xe6d8]): Consistency check failed: Illegal null pointerFAILED: ok
         FAILED: CheckPointer(pMT)
                /home/janvorli/git/coreclr/src/vm/appdomain.cpp, line: 13816
    File: /home/janvorli/git/coreclr/src/inc/check.h Line: 373
    Image: /home/janvorli/dotnet/test/corerun

#0  DBG_DebugBreak () at debugbreak.S:114
#1  0xf7899a88 in DebugBreak () at /home/janvorli/git/coreclr/src/pal/src/debug/debug.cpp:404
#2  0xf6ce977c in CHECK::Setup (this=0xffffbfa4, message=0xf79daf30 "Illegal null pointer", condition=0xf7a6ba26 "ok",
    file=0xf79daf45 "/home/janvorli/git/coreclr/src/inc/check.h", line=373) at /home/janvorli/git/coreclr/src/utilcode/check.cpp:218
#3  0xf6e3e308 in CheckPointer<MethodTable> (o=0x0, ok=NULL_NOT_OK) at /home/janvorli/git/coreclr/src/inc/check.h:373
#4  0xf7226147 in BaseDomain::LookupType (this=0xf7c9f940 <g_pSharedDomainMemory>, id=60) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:13816
#5  0xf72260f3 in BaseDomain::LookupType (this=0x8077208, id=60) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:13813
#6  0xf6f4d993 in VSD_ResolveWorker (pTransitionBlock=0xffffc324, siteAddrForRegisterIndirect=354570792, token=3979264)
    at /home/janvorli/git/coreclr/src/vm/virtualcallstub.cpp:1579
#7  0xf71f349a in ResolveWorkerAsmStub () at asmhelpers.S:1041
#8  0xffffc324 in ?? ()
#9  0xf4fd0222 in ?? ()
#10 0xf633b14c in ?? ()
#11 0xf71f31ab in CallDescrWorkerInternal () at asmhelpers.S:442
#12 0xf6f85d08 in CallDescrWorker (pCallDescrData=0xffffcba8) at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:146
#13 0xf6f85ab9 in CallDescrWorkerWithHandler (pCallDescrData=0xffffcba8, fCriticalCall=0) at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:89
#14 0xf6f87a2b in MethodDescCallSite::CallTargetWorker (this=0xffffcdd8, pArguments=0xffffcf00, pReturnValue=0xffffcc18, cbReturnValue=8)
    at /home/janvorli/git/coreclr/src/vm/callhelpers.cpp:656
#15 0xf6d56064 in MethodDescCallSite::Call_RetOBJECTREF (this=0xffffcdd8, pArguments=0xffffcf00) at /home/janvorli/git/coreclr/src/vm/callhelpers.h:436
#16 0xf7205fd4 in AppDomain::DoSetup (this=0x8077208, setupInfo=0xffffd2f8) at /home/janvorli/git/coreclr/src/vm/appdomain.cpp:5735
#17 0xf6d4a3cc in CorHost2::_CreateAppDomain (this=0x805e8d8, wszFriendlyName=0x805e910 u"unixcorerun", dwFlags=336, wszAppDomainManagerAssemblyName=0x0,
    wszAppDomainManagerTypeName=0x0, nProperties=5, pPropertyNames=0x805e938, pPropertyValues=0x805e958, pAppDomainID=0xffffd650)
    at /home/janvorli/git/coreclr/src/vm/corhost.cpp:1717
#18 0xf6d4d9ac in CorHost2::CreateAppDomainWithManager (this=0x805e8d8, wszFriendlyName=0x805e910 u"unixcorerun", dwFlags=336,
    wszAppDomainManagerAssemblyName=0x0, wszAppDomainManagerTypeName=0x0, nProperties=5, pPropertyNames=0x805e938, pPropertyValues=0x805e958,
    pAppDomainID=0xffffd650) at /home/janvorli/git/coreclr/src/vm/corhost.cpp:1890
#19 0xf6cd1623 in coreclr_initialize (exePath=0x8052014 "/home/janvorli/dotnet/test/corerun", appDomainFriendlyName=0x804e529 "unixcorerun", propertyCount=5,
    propertyKeys=0xffffd694, propertyValues=0xffffd680, hostHandle=0xffffd654, domainId=0xffffd650)
    at /home/janvorli/git/coreclr/src/dlls/mscoree/unixinterface.cpp:219
#20 0x0804c51f in ExecuteManagedAssembly (currentExeAbsolutePath=0x8052014 "/home/janvorli/dotnet/test/corerun",
    clrFilesAbsolutePath=0x8052084 "/home/janvorli/dotnet/test", managedAssemblyAbsolutePath=0x805204c "/home/janvorli/dotnet/test/nullref.exe",
    managedAssemblyArgc=0, managedAssemblyArgv=0x0) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcoreruncommon/coreruncommon.cpp:404
#21 0x0804b228 in corerun (argc=2, argv=0xffffd864) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcorerun/corerun.cpp:149
#22 0x0804b35a in main (argc=2, argv=0xffffd864) at /home/janvorli/git/coreclr/src/coreclr/hosts/unixcorerun/corerun.cpp:161

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 17, 2017

I'll first check whether master works for me.

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 17, 2017

To collect Core FX managed dll(s), I used a bit old collecting script of the following form (OS is Linux):

MANAGED_TAGS=()
MANAGED_TAGS+=("AnyOS.AnyCPU")
MANAGED_TAGS+=("Unix.AnyCPU")
MANAGED_TAGS+=("${OS}.AnyCPU")

    for MANAGED_TAG in ${MANAGED_TAGS[@]}; do
      REPO="${SRC_DIR}/${MANAGED_TAG}.${PRESET}"

      for BASE in $(find "${REPO}"  -iname '*.dll' \! -iwholename '*test*' \! -iwholename '*/ToolRuntime/*' \! -iwholename '*/RemoteExecutorConsoleApp/*' \! -iwholename '*/net*' \! -iwholename '*aot*' -exec dirname {} \; | uniq | xargs -i basename {}); do
        PDB_FILE="${REPO}/${BASE}/${BASE}.pdb"
        DLL_FILE="${REPO}/${BASE}/${BASE}.dll"

        if [[ -f "${DLL_FILE}" ]]; then
          cp -t "${MANAGED_BIN_FILE_INTO}" "${DLL_FILE}"
        fi
      done
    done
@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 17, 2017

Here is the brief steps that I am currently using:

  • Cross-build Core CLR with the following command and copy the artifacts into output directory:
coreclr $ ./build.sh cross x86  skipnuget debug cmakeargs "-DSKIP_LLDBPLUGIN=true" clang3.8
...
$ cp bin/Product/Linux.x86.Debug/* [OUTPUT DIR]
  • Collect Core FX native so(s)
corefx $  cp bin/Linux.x86.Debug/* [OUTPUT DIR]
  • Collect Core FX managed dll(s) using the above script
@janvorli

This comment has been minimized.

Copy link
Member

@janvorli janvorli commented 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

This comment has been minimized.

Copy link
Author

@parjong parjong commented 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

This comment has been minimized.

Copy link
Member

@janvorli janvorli commented 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

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 17, 2017

@janvorli Thanks you for check 👍

FYI, -DSKIP_LLDBPLUGIN=true was just a workaround during bring up, but remains unchanged as lldb-plugin is not used currently.

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 20, 2017

Here is the result (XML) from b957f8c:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 7027
# Passed           : 5913
# Failed           : 833
# Skipped          : 281
=======================
@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 20, 2017

#9601 (although it is under review) seems to make huge progress.

Here is the result XML from b957f8c with #9601:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6526
# Failed           : 220
# Skipped          : 281
=======================
@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Feb 27, 2017

Here is the result from 6092f90 (log and XML):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6614
# Failed           : 131
# Skipped          : 282
=======================

#9601 seems to make huge progress (more than expected)!!!

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Mar 1, 2017

dc3626d finally achieves < 100 failures:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6657
# Failed           : 88
# Skipped          : 282
=======================

Here are log and XML.

@janvorli

This comment has been minimized.

Copy link
Member

@janvorli janvorli commented Mar 1, 2017

@parjong great! Thank you for the update.
CC: @gkhanna79

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Mar 9, 2017

Here is the recent result (XML) from cf7d6d9:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7027
# Passed           : 6707
# Failed           : 51
# Skipped          : 269
=======================
@BruceForstall

This comment has been minimized.

Copy link
Member

@BruceForstall BruceForstall commented Mar 29, 2017

@parjong How's it look now?

Should we create a Linux/x86 GitHub project (https://github.com/dotnet/coreclr/projects)? It's a relatively new GitHub feature -- not sure how useful it really is.

@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Mar 29, 2017

Here is the result from 2401b6e (full log):

=======================
     Test Results
=======================
# CoreCLR Bin Dir  : 
# Tests Discovered : 7061
# Passed           : 6319
# Failed           : 18
# Skipped          : 724
=======================

#10538 resolves this failure, but is not merged in 2401b6e :

  • Loader/classloader/generics/Instantiation/Recursion/genrecur/genrecur.sh

#10188 addresses the following two failures :

  • JIT/Methodical/eh/nested/nonlocalexit/throwinfinallyrecursive_20_d/throwinfinallyrecursive_20_d.sh
  • JIT/Methodical/eh/nested/nonlocalexit/throwinfinallyrecursive_20_r/throwinfinallyrecursive_20_r.sh

#10410 seems to address the following two failures:

  • JIT/Performance/CodeQuality/Serialization/Deserialize/Deserialize.sh
  • JIT/Performance/CodeQuality/Serialization/Serialize/Serialize.sh

The following failures seems to be related with incorrect stack unwinding on esp-frame #10025, or helper-frame #9272). I hope that #10012 addresses these failures:

  • JIT/IL_Conformance/Old/Conformance_Base/conv_ovf_r8_i/conv_ovf_r8_i.sh
  • JIT/IL_Conformance/Old/Conformance_Base/conv_ovf_r8_i4/conv_ovf_r8_i4.sh
  • JIT/Methodical/Arrays/misc/_il_relinitializearray/_il_relinitializearray.sh
  • JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b52578/b52578/b52578.sh
  • JIT/Regression/CLR-x86-JIT/V1-M12-Beta2/b52840/b52840/b52840.sh
  • JIT/Regression/CLR-x86-JIT/V1.1-M1-Beta1/b143840/b143840/b143840.sh
  • JIT/Regression/VS-ia64-JIT/V1.2-M01/b12390/b12390/b12390.sh
  • JIT/jit64/rtchecks/overflow/overflow01_div/overflow01_div.sh
  • JIT/jit64/rtchecks/overflow/overflow02_div/overflow02_div.sh
  • JIT/jit64/rtchecks/overflow/overflow04_div/overflow04_div.sh

#10139 is related with these two failures:

  • readytorun/mainv1/mainv1.sh
  • readytorun/mainv2/mainv2.sh

The following failure seems to be related with some GC issue, but not sure yet:

  • JIT/Performance/CodeQuality/Span/SpanBench/SpanBench.sh
@parjong

This comment has been minimized.

Copy link
Author

@parjong parjong commented Mar 29, 2017

Here is the result from 1c2ee08:

=======================
     Test Results
=======================
# CoreCLR Bin Dir  :
# Tests Discovered : 7061
# Passed           : 6320
# Failed           : 17
# Skipped          : 724
=======================

As expected, Loader.classloader.generics.Instantiation.Recursion.genrecur.genrecur failure is gone:

Failed test:
  JIT.IL_Conformance.Old.Conformance_Base.conv_ovf_r8_i.conv_ovf_r8_i
  JIT.IL_Conformance.Old.Conformance_Base.conv_ovf_r8_i4.conv_ovf_r8_i4
  JIT.Methodical.Arrays.misc._il_relinitializearray._il_relinitializearray
  JIT.Methodical.eh.nested.nonlocalexit.throwinfinallyrecursive_20_d.throwinfinallyrecursive_20_d
  JIT.Methodical.eh.nested.nonlocalexit.throwinfinallyrecursive_20_r.throwinfinallyrecursive_20_r
  JIT.Performance.CodeQuality.Serialization.Deserialize.Deserialize
  JIT.Performance.CodeQuality.Serialization.Serialize.Serialize
  JIT.Performance.CodeQuality.Span.SpanBench.SpanBench
  JIT.Regression.CLR-x86-JIT.V1-M12-Beta2.b52578.b52578.b52578
  JIT.Regression.CLR-x86-JIT.V1-M12-Beta2.b52840.b52840.b52840
  JIT.Regression.CLR-x86-JIT.V1.1-M1-Beta1.b143840.b143840.b143840
  JIT.Regression.VS-ia64-JIT.V1.2-M01.b12390.b12390.b12390
  JIT.jit64.rtchecks.overflow.overflow01_div.overflow01_div
  JIT.jit64.rtchecks.overflow.overflow02_div.overflow02_div
  JIT.jit64.rtchecks.overflow.overflow04_div.overflow04_div
  readytorun.mainv1.mainv1
  readytorun.mainv2.mainv2
@liserdarts

This comment has been minimized.

Copy link

@liserdarts liserdarts commented May 28, 2018

I think we can build end to end i386 product by ourselves

If you're going to build it yourself you might be interested in the repository I made specifically for this situation.

In there is a bash script that will download the source, build, and create an output folder. It runs on x64 in Linux and builds .NET Core for x86 in Linux,

As far as what's left for x86 support, there is on thing I'm aware of. In an v2.1-preview1/Linux/x86 environment it's possible to crash the processes when using NamedPipeServerStream. I think this is an issue for corefx and there is an open issue for it.

Not sure if this has been fixed in v2.1-preview2 or v2.1-rc1. I you're interested in testing those branches yourself I have create a repo that reproduces the problem.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented May 29, 2018

I think what you have achieved is essentially a subset of https://github.com/dotnet/source-build, which is meant for distribution package managers and other source builders. It builds 20 submodule repositories, including dotnet, aspnet and microsoft orgs. I think it would be best to converge the effort into that repo for more platforms rather than reinventing it.

@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Mar 12, 2019

What is up with this? this doc says to check runtime.json for supported runtime identifiers. I see linux x86 variants in there, but can't get them to work on my ubuntu sandbox.

Missing x86 support has been holding me back from porting my servers from mono/desktop framework builds to .NET Core builds, because x64 memory usage is nearly doubling the runtime memory usage.

@sergei66666

This comment has been minimized.

Copy link

@sergei66666 sergei66666 commented Mar 26, 2019

Hello to all! I would also like to use x86. What problems stand in the way to the x86 future?

@danmosemsft

This comment has been minimized.

Copy link
Member

@danmosemsft danmosemsft commented Mar 26, 2019

@jkotas

This comment has been minimized.

Copy link
Member

@jkotas jkotas commented Mar 26, 2019

Linux x86 is community supported at this point. There are no officially supported prebuilt binaries available. You have to build your own as others commented above.

Thank you for your feedback. We will consider adding prebuilt .NET Core Linux x86 binaries in future if we see a lot of demand for them. Please leave comment on this issue if you would like to see .NET Core officially supported on Linux x86.

cc @richlander

@ikkentim

This comment has been minimized.

Copy link

@ikkentim ikkentim commented Mar 26, 2019

I would love to see prebuilt binaries :)

@TheLastRar

This comment has been minimized.

Copy link

@TheLastRar TheLastRar commented Mar 26, 2019

I would like to see prebuilt packages as well, preferably in a manor that supports multiarch.

@deinok

This comment has been minimized.

Copy link

@deinok deinok commented Mar 28, 2019

@jkotas Probably it could be cool to at least have the initial dotnet to start trying compile from a linux-x86 host

@bording

This comment has been minimized.

Copy link

@bording bording commented Apr 12, 2019

I'd actually prefer to not see official x86 linux binaries, primarily because then I'd feel obligated to build even more native binaries to make LibGit2Sharp work with them! 😄

@deinok

This comment has been minimized.

Copy link

@deinok deinok commented Apr 12, 2019

@bording And Mono? It runs in x86
Im not sure if this is a good reason for not having an unofficial x86 runtime / sdk.

An important point is that some industrial enviroments are move to have PLC with linux and most of them have a x86 arch. And industrial environments wont change its arch in a looooong time.
Ex: https://w3.siemens.com/mcms/pc-based-automation/en/industrial-iot/Pages/Default.aspx?tabcardname=simatic%20iot2000%20io-shield

@bording

This comment has been minimized.

Copy link

@bording bording commented Apr 12, 2019

@bording And Mono? It runs in x86
Im not sure if this is a good reason for not having an unofficial x86 runtime / sdk.

True, though at this point I'm considering .NET Core the primary platform for non-Windows support in LibGit2Sharp. Mono doesn't have a way to provide a single NuGet package that has all the binaries needed for different distros that works without some manual intervention.

But that's getting off-topic here, so I'l leave it at that!

@cocowalla

This comment has been minimized.

Copy link

@cocowalla cocowalla commented Aug 2, 2019

@jkotas another vote for a linux-x86 rid. I've been following this issue since it was opened back in 2017, and it's disappointing that Linux x86 still isn't officially supported. I get that most platforms are x64 nowadays, but x86 will be around for a long time before it goes away.

IIRC, even the guidance for Azure App Service recommends using 32-bit instead of 64-bit, because of the memory savings.

@ntindle

This comment has been minimized.

Copy link

@ntindle ntindle commented Sep 16, 2019

Another vote for it. Power shell requires it. @jkotas
dotnet/core#322

@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Sep 17, 2019

It would be great if we could at least have documented how to do custom builds. I've been trying repeatedly and not been able to setup custom 32 bit builds (custom builds of individual git repos work but I could never get the whole system run together).

@jkotas

This comment has been minimized.

Copy link
Member

@jkotas jkotas commented Sep 17, 2019

documented how to do custom builds.

https://github.com/dotnet/source-build has the script and documentation to build the whole system. Have you tried that?

This will get a lot easier with #26175

@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Sep 17, 2019

Thanks, I'll try that (and report back for anyone else interested), so far I only looked at individual repository readmes and various (outdated) blog posts, didn't see that yet. The last time I got stuck in figuring out how to get corefx build pick up the coreclr build output.

@deinok

This comment has been minimized.

Copy link

@deinok deinok commented Sep 17, 2019

@jkotas Can we know when will the plataform merge will start?

@jkotas

This comment has been minimized.

Copy link
Member

@jkotas jkotas commented Sep 17, 2019

It is best to ask on #26175 about the timelines. It started already: folks are figuring the execution details, the tools and techniques to use, etc.

@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Sep 17, 2019

@jkotas doesn't look like source-build supports cross compiling, bootstrap looks promising but seems to need a pure x86 Ubuntu instead of using x86_64 and is more complex than it needs to be for the special case of a Linux x86 build. I'll continue experimenting over the weekend, but its far from being a useable documentation/tool for creating x86 builds on Linux. I've created dotnet/source-build#1235 for further discussion on how to do custom builds, perhaps the documentation (or scripts) can be improved as a result of that.

@janvorli

This comment has been minimized.

Copy link
Member

@janvorli janvorli commented Sep 17, 2019

@weltkante 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.

@janvorli

This comment has been minimized.

Copy link
Member

@janvorli janvorli commented Sep 17, 2019

If you wanted to try to use the bootstrap script though, you'd need to patch it a bit so that it can do cross build. You'd need to add -cross option to the coreclr build.sh and the corefx build-native.sh and --cross to the core-setup build.sh and before running the script, set ROOTFS_DIR env var to point to the location of the rootfs you've built for x86.

@ikkentim

This comment has been minimized.

Copy link

@ikkentim ikkentim commented Jan 9, 2020

@jkotas any news on the prebuilt .NET Core Linux x86?

Also, is there an issue on dotnet/runtime for this topic (Linux x86), or does discussion continue here?

@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Jan 9, 2020

@ikkentim I think dotnet/source-build#1235 I created above may be the appropriate place for discussing how to get it working (unless its also merged into dotnet/runtime? I'm not entirely sure). The repository already contains build scripts for x86 but they are underdocumented and unfortunately I couldn't get them completing successfully by trial-and-error. Before any prebuilt packages can be made the build scripts need to be put into working order.

For what its worth coreclr itself is easy to compile for x86 (you can do this with the existing build scripts in the coreclr build tree), but getting a build for the rest of the dotnet infrastructure is the problem.

@jkotas

This comment has been minimized.

Copy link
Member

@jkotas jkotas commented Jan 9, 2020

is there an issue on dotnet/runtime for this topic (Linux x86)

We have not bulk migrated the issues from the coreclr/corefx repos to dotnet/runtime yet. It should happen any day now. Just use the the existing Linux x86 issue in coreclr for any discussion on this.

dotnet/runtime is the place to focus on. Can dotnet/runtime be cross-compiled for Linux x86 right now?

If you just need the runtime (without the full SDK), dotnet/runtime is all that needs to be build. source-build should not be necessary for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.