Closed jamsoft closed 2 years ago
I've just noticed the note in the docs ...
86, x86_64, ARM64 compilation supported. The Visual Studio package containing the desired compiler architecture must have been installed.
So in my main project I have explicitly referenced the various ILCompiler packages, i.e.:
<PackageReference Include="runtime.osx-x64.Microsoft.DotNet.ILCompiler" Version="7.0.0-preview.5.22301.12" />
But I'm not sure if these are relevant to DNNE. Any pointers would be great.
So I've just tidied up my installed SDKs so I only have 6x SDKs and Runtimes installed. Now when compiling I'm getting this error:
no such file or directory: '/usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-x64/6.0.5/runtimes/osx-x64/native/libnethost.a'
Hmm ...
Just discovered that this directory is actually missing ...
no such file or directory: '/usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-x64/6.0.5'
I'm not sure how to get this installed. Is this a missing 'targetting pack' install?
This is a cross-targeting issue that is going to need some investigation on my end. I'm not sure how or even if we pull down the x64 host assets on an M1.
@vitek-karas or @elinor-fung Any thoughts here?
I don't know how DNNE does this, but the host packages should be "download on demand". The package exists on NuGet: https://www.nuget.org/packages/Microsoft.NETCore.App.Host.osx-x64/6.0.5.
dotnet build
when building the apphost
uses this package. It will get it locally from the packs
directory if available, and download from NuGet if not.
On Windows the installer will populate the packs
folder with all Windows architectures (x86, x64, arm64), but it probably doesn't do that on Mac. For SDK it should not matter, it should just download it, but DNNE probably doesn't work that way.
I don't know how DNNE does this, but the host packages should be "download on demand". The package exists on NuGet: https://www.nuget.org/packages/Microsoft.NETCore.App.Host.osx-x64/6.0.5.
DNNE relies on the SDK to do everything, it does nothing special. I think I may have an idea now though.
@jamsoft As @vitek-karas mentioned, the SDK should be pulling this down for you. However, since you are cross targeting you may need to tell the SDK which platform you are targeting. Can you try defining the target RID for your library? This will let the SDK know what native components to pull down. This can also be an issue on Windows when trying to target x86 instead of x86_64. Some notes about this are found in the repo readme.md
under step (3) in the following section.
Hi, it's already setting osx-x64
in the pertinent places.
I did a massive clean up today on my mac. Uninstalled all the old SDKs and runtimes. So I only had 6.x installed. I re-ran both x64 and arm64 SDK installers, just to see what the effect would be.
Still no 6.0.5 contents in the pack directory.
BUT.
It started compiling ...
I hit the dreaded dotnet is not a valid command
situation and had to fix the symlink to repair it.
So that's some progress but my gitlab runner on the same box is having odd x64/arm64 issues. Even with arch -x86-64 ./stript
commands.
the REALLY odd thing is I can watch that build fail in the GitLab UI with missing arm64
log messages. Re-execute it, and it passes. Odd.
This x86/x64/arm business is a tad rocky!
@jamsoft Please let me know if you are still blocked. I don't think there is anything left on the DNNE side of things to address here.
I've picked up a project using this to produce a native dylib.
The windows version is all working perfectly. The issue starts when I try to compile it for x64 mac on an M1 machine.
The rest of my solution is cross compiling fine but I just can't seem to get this project compiling. The errors I'm getting are:
And
In my other builds a use scripts executed like
arch -x86_64 ./myscript
in order to execute as x64 not arm64. I also have switched my terminal app to always usei386
and even executing the commands this way fails.Also a bit confusing why
Microsoft.NETCore.App/5.0.11/
is mentioned in a .NET 6.0.3 application?Any ideas would be great.