dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.82k stars 4.61k forks source link

Failed to cross build for ARM32 #19325

Closed aviviadi closed 4 years ago

aviviadi commented 7 years ago

Problem updated to https://github.com/dotnet/corefx/issues/13550#issuecomment-261781800

OLD problem (solved)

Successfully built coreclr. Failed with corefx.

Specific problem with :

info : OK https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/system.threading.tasks.parallel/index.json 393ms info : GET https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/system.threading.tasks.parallel/4.0.1-rc3-24128-00/system.threading.tasks.parallel.4.0.1-rc3-24128-00.nup kg info : An error was encountered when fetching 'GET https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.runtime/index.json'. The request will now be retried. info : An error occurred while sending the request. info : SSL connect error log : Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.threading.threadpool/index.json'. log : An error occurred while sending the request. log : SSL connect error info : GET https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.threading.threadpool/index.json error: Failed to retrieve information from remote source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/system.threading/index.json'. error: An error occurred while sending the request. error: SSL connect error error: Failed to retrieve information from remote source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/system.threading/index.json'. error: An error occurred while sending the request. error: SSL connect error log : Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.reflection.extensions/index.json'. log : An error occurred while sending the request. log : SSL connect error info : GET https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.reflection.extensions/index.json

On ubuntu 16.04 x64. cross build for arm32.

aviviadi commented 7 years ago

i.e. trying to get https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.threading.threadpool/index.json is not found, and probably should be.

mellinoe commented 7 years ago

is not found, and probably should be.

Not necessarily. Nuget queries all of the package sources for packages, and that one shouldn't be contained on the buildtools feed, as far as I can tell. It should be on the "dotnet-core" feed.

My initial guess is that you may be behind some firewall or proxy that is not playing nicely with myget or some other part of our build.

aviviadi commented 7 years ago

i.e. this one : https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.threading.threadpool/index.json

also from home network without firewall gives:

BlobNotFound The specified blob does not exist. RequestId:026f6e5a-0001-0135-710d-3d8e85000000 Time:2016-11-12T17:48:39.2204867Z

Obviously the specific package is not there. Does latest clone of corefx can be cross compiled at all?

aviviadi commented 7 years ago

ok. I found the missing packages in dotnet-core feed. I will add this feed to the build script locally. Thanks @mellinoe

aviviadi commented 7 years ago

Problem updated to https://github.com/dotnet/corefx/issues/13550#issuecomment-261781800

Old (solved) problem

So, after successfully cross compiled coreclr & corefx on ubuntu 16.04 x64, and publishing my app on the same machine, I headed to https://github.com/dotnet/coreclr/issues/6321#issuecomment-245770180

On the Pi3 - after compiling libuv, and following the script for copying the relevant libraries, I was ready to run, however got :

./corerun myapp.dll coreclr_initialize failed - status: 0x80004005

Although I read this error related to mismatch of mscorlib with the current arch, I got the file from the cross build process.

EDIT: 'Hello World' is working fine (dotnet new program) on the rpi3. So mscorlib is fine.

So it is something with my app that doesn't get along with coreclr

mellinoe commented 7 years ago

I haven't tried this exact scenario, so I can only really give general advice about things to check:

'Hello World' is working fine (dotnet new program) on the rpi3.

Do you mean that a helloworld.dll application produced by the CLI works on the runtime you've produced, or something else?

mellinoe commented 7 years ago

Another thing to check: Are you using any native images in your framework? System.Private.CoreLib.ni.dll, for example. Try removing those and leaving the "regular" .dll files, if you can.

ayende commented 7 years ago

Okay, we managed to progress quite a bit. The current blocking issue can be reproduced with minimal work:

Console.WriteLine("Hello World!");
System.Net.IPAddress a;    
System.Net.IPAddress.TryParse("0.0.0.0", out a);
Console.WriteLine("Hello World!");

We build it with dotnet publish -r ubuntu.14.04-x64 -c release

And then deploy to Raspberry PI, there, we get:

raven@raven-pc:/mnt/d/overlay4$ ./corerun Logs.dll
Hello World!

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Win32.Primitives, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040 (FUSION_E_REF_DEF_MISMATCH))
   at System.Net.IPAddressParser.Parse(String ipString, Boolean tryParse)
   at System.Net.IPAddress.TryParse(String ipString, IPAddress& address)
   at Bears.Program.Main(String[] args) in C:\Work\ravendb-4.0\Logs\Program.cs:line 25
Aborted (core dumped)

I'm pretty sure that I'm using the wrong System.Net.Primitives.dll (MD5: 8cb76133c5863a5dab35bee20076e412 )

But I'm not sure how to check that, and how to verify that I'm actually getting the right file (and from where to get it).

ayende commented 7 years ago

Okay, looks like it is something else, I recompiled on Ubuntu and pushed the whole thing over, and now it seems to be work fine.

ayende commented 7 years ago

I managed to get it working to the point where it is opening the Kesterl server, but then it just dies. Not sure why.

The code is:

                    if (_logger.IsInfoEnabled)
                        _logger.Info("Server is shutting down");
                   return 0;
                }
                catch (Exception e)
                {
                    if (_logger.IsOperationsEnabled)
                        _logger.Operations("Failed to initialize the server", e);
                    Console.WriteLine(e);
                    return -1;
                }
                finally
                {
                    Console.WriteLine("Bye, bye...");
                }

Based on console output, I know it is getting to this code, but then it just dies. No errrors, nothing. The finally isn't executed, and the return code is 66. I put a while loop there that just printed a line per second, and it looks like it dies after 9 - 10 seconds.

Nothing in dmesg or anything in the logs that I can see. Any ideas?

aviviadi commented 7 years ago

And beside the above problem mentioned by ayende, I can demonstrate the following difference between x64 ubuntu machine and RPI for the following code (from empty new project):

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Http.Extensions;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseUrls("http://0.0.0.0:8080")
                .UseKestrel()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }

        public class Startup
        {
            public void ConfigureServices(IServiceCollection services)
            { }

            public void Configure(IApplicationBuilder app)
            {
                app.Run(Handler);
            }

            public async Task Handler(HttpContext ctx)
            {
                ctx.Response.StatusCode = 200;
                Console.WriteLine("Got the request " + ctx.Request.Method + ", " + ctx.Request.Path.Value);
                await ctx.Response.WriteAsync("Hi from the Pi");
            }
        }
    }
}

In ubuntu 14.04 x64 it works fine. In rpi3 response code is 504. However the "Got the request" string is printed.

mellinoe commented 7 years ago

@aviviadi Could you clarify what OS / configuration you're trying this out on? If you're trying to run arm32 on Linux, then you're mostly heading into uncharted territory. Some folks have gone there, but you're most likely going to run into some unusual things that nobody has seen or fixed yet. win10-arm is a new scenario and perhaps @gkhanna79 would know more about potential issues.

aviviadi commented 7 years ago

Ubuntu mate 16.04 on rpi3. We've already ran into strange things and we overcome them. After running with a great success on linux x64, running kestrel on linux-arm32 can be a nice milestone. We want to cross this uncharted terrotory:)

mellinoe commented 7 years ago

@karelz I'm going to move this into area-Meta, since this isn't directly infrastructure-related.

@aviviadi Unfortunately I'm not sure I have the expertise here, especially with Kestrel. It sounds like you have gotten some basic programs to run, but it's unclear how stable or robust everything else is. You might get some better insights if you tried running some other small programs to test the capabilities out. For example, running a small socket server, or doing some Http requests, etc. Without running the full set of corefx functional tests, it's really hard to say what could be going wrong. Unfortunately, ARM on Linux is not something we are in a position to test or support right now, so I can't say for sure what the problem is.

karelz commented 7 years ago

@dotnet/samsung folks might be able to help. I think you will need to get it under debugger / get dump and find out what is happening. coreclr repo might be better place to track problems like these - corefx repo is useful for specific APIs problems, not for runtime issues.

gkhanna79 commented 7 years ago

@aviviadi How are you building for Linux Arm32? Are you cross compiling it on Ubuntu x64 or building on Ubuntu mate on RPI3 itself?

aviviadi commented 7 years ago

@gkhanna79 cross build on ubuntu x64 plus few things from here : https://github.com/dotnet/coreclr/issues/6321#issuecomment-245770180

@karelz - I had few corefx build problems but they are solved now (I think local proxy issues) so I will close this thread.

@mellinoe - A LOT of things are working on the pi. We have more then a basic program already running fine on dotnet core / Linux-x64. We want to make it work (even partially) on the Pi. The web hosting is a major part. We will continue this discussion in coreclr.

aviviadi commented 7 years ago

P.S. - The above sample program now works on the Pi (I overran arm's dll by mistake).