Sdk: Self-contained linux app missing libhostfxr.so

Created on 17 Jan 2019  路  10Comments  路  Source: dotnet/sdk

Using https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-linux-x64.tar.gz

RUN dotnet restore --runtime linux-x64 --configfile /app/Nuget.Config
RUN dotnet publish -c Release -f netcoreapp3.0 --self-contained --runtime linux-x64 --no-restore -o /out

csproj is roughly

  <PropertyGroup>
    <TargetFrameworks>netcoreapp3.0</TargetFrameworks>
    <OutputType>Exe</OutputType>
    <RuntimeIdentifiers>win10-x64;linux-x64</RuntimeIdentifiers>
  </PropertyGroup>

    <ItemGroup>
      <FrameworkReference Include="Microsoft.AspNetCore.App" />
    </ItemGroup>
# ./Watchdogs
A fatal error occurred, the required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/app/Watchdogs/].
If this is a framework-dependent application, install the runtime in the default location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.

# ldd ./Watchdogs
        linux-vdso.so.1 (0x00007fff783f2000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff3e590a000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff3e56ed000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff3e536b000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff3e5067000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff3e4e50000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff3e4ab1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff3e5b0e000)

I think this is a recent development. The previous sdk nightly worked fine. There are no *.so files in the output directory

release blocking

All 10 comments

I think I know what happened here and just coincidentally theorized that we're broken in this runtimeidentifiers plural + no restore on an email thread.

If right, Daniel's recent change that isn't in core-sdk yet is a piece of the puzzle. The other piece is that we need to add a runtime pack download for each runtime identifier.

@nguerrera since it sounds like you have a working theory, feel free to assign to you as I simply self-assigned so I could poke it with a stick tomorrow.

ok this might be partially my fault. Just realized I removed the <Platforms>AnyCPU;x64</Platforms> section from the csproj (thought maybe runtimeidentifiers had enough info, but I guess not). Would be nice if there was a warning or error somewhere rather than producing a broken self-contained build.

Also, is there a best practice for dotnet restore blah.sln && dotnet publish --no-restore each.csproj vs dotnet publish? dotnet restore has the --configfile option but publish doesn't. Looking at the code it looks like that flag just sets RestoreConfigFile?

ok, maybe i spoke too soon. Adding back <Platforms>AnyCPU;x64</Platforms> did not have any effect. Same error

interesting that the runtime environment from the linux-x64 tarball shows debian.9-x64.

# /usr/share/dotnet/dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010114
 Commit:    7e223b04f5

Runtime Environment:
 OS Name:     debian
 OS Version:  9
 OS Platform: Linux
 RID:         debian.9-x64
 Base Path:   /usr/share/dotnet/sdk/3.0.100-preview-010114/

Host (useful for support):
  Version: 3.0.0-preview-27315-8
  Commit:  2664188b4a

.NET Core SDKs installed:
  3.0.100-preview-010114 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0-preview-19066-0374 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0-preview-27315-8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

If i restore and build with debian.9-x64, the libhostfxr issue goes away, but libhostpolicy.so is not found.

# rm -rf /out/Watchdogs/
root@3c5142e6d67c:/app# dotnet restore Rewards.sln --runtime debian.9-x64 --configfile /app/Nuget.Config > /dev/null
root@3c5142e6d67c:/app# dotnet publish Watchdogs/Watchdogs.csproj -c Release -f netcoreapp3.0 --self-contained --runtime debian.9-x64 --no-restore -o /out/Watch
dogs > /dev/null
root@3c5142e6d67c:/app# /out/Watchdogs/Watchdogs
A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/usr/share/dotnet'.

Singular RuntimeIdentifiers gets us past libhostpolicy.so:

root@3c5142e6d67c:/app# sed -i 's/win10-x64;linux-x64/linux-x64/g' exe.props
root@3c5142e6d67c:/app# sed -i 's/win10-x64;linux-x64/linux-x64/g' lib.props
root@3c5142e6d67c:/app# cat exe.props
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <TargetFrameworks>netcoreapp3.0</TargetFrameworks>
    <OutputType>Exe</OutputType>
    <RuntimeIdentifiers>linux-x64</RuntimeIdentifiers>
    <Platforms>AnyCPU;x64</Platforms>
  </PropertyGroup>

    <ItemGroup>
      <FrameworkReference Include="Microsoft.AspNetCore.App" />
    </ItemGroup>

root@3c5142e6d67c:/app# dotnet restore Rewards.sln --runtime debian.9-x64 --configfile /app/Nuget.Config > /dev/null
root@3c5142e6d67c:/app# dotnet publish Watchdogs/Watchdogs.csproj -c Release -f netcoreapp3.0 --self-contained --runtime debian.9-x64 --no-restore -o /out/Watch
dogs > /dev/null
root@3c5142e6d67c:/app# /out/Watchdogs/Watchdogs
Could not resolve CoreCLR path. For more details, enable tracing by setting COREHOST_TRACE environment variable to 1

this might be fixed when i use:
https://dotnetcli.blob.core.windows.net/dotnet/Sdk/3.0.100-preview-010124/dotnet-sdk-3.0.100-preview-010124-linux-x64.tar.gz instead of https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/dotnet-sdk-latest-linux-x64.tar.gz.

dotnet --info:

# dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010124
 Commit:    41a73b60f2

Runtime Environment:
 OS Name:     debian
 OS Version:  9
 OS Platform: Linux
 RID:         debian.9-x64
 Base Path:   /usr/share/dotnet/sdk/3.0.100-preview-010124/

Host (useful for support):
  Version: 3.0.0-preview-27316-4
  Commit:  bc9c41141c

.NET Core SDKs installed:
  3.0.100-preview-010124 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0-preview-19067-0383 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0-preview-27316-4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

will update the thread after i test some more

Using that other build seemed to fix it. Thanks.

Great. I did some digging and looks like what I thought was just the first piece of the puzzle was actually the whole puzzle for now. At present, when we have a PackageReference with excluded assets on Microsoft.NETCore.App, and we are getting the rid-specific dependencies for free. However, when we switch to PackageDownload we will need to add some more code to handle this. I will file a separate issue with the details.

Filed #2839

Was this page helpful?
0 / 5 - 0 ratings