Veldrid.StartupUtilities / Sdl2 do not add sdl2 binary

[geoeo]

Hi,

I just trying your tutorials with vs code on mac.
My .csproject file after part1 of your tutorial looks like this
... <ItemGroup> <PackageReference Include="Veldrid" Version="4.0.0" /> <PackageReference Include="Veldrid.StartupUtilities" Version="4.0.0" /> </ItemGroup> ...

However, running dotnet restore does not include the binary.
Headerfiles are loaded, because autocompletion works.
But the program will crash at runtime.
Sdl2Window window = VeldridStartup.CreateWindow(ref windowCI); // crash

I dont know if nuget should resolve binary dependencies, but from the tutorial it seems like it should just work with these commands.

Thanks you for this API.

Best,
Marc

[mellinoe]

It turns out that, for some reason, the osx-x64 binaries are not used if you run the program through nuget packages (e.g. if you just use dotnet run <project>).

I think this is a bug in the .NET Core SDK, because on Windows, the win-x64 binaries ARE used, and the situation should be exactly the same.

A couple of workarounds:

• Install SDL2 through homebrew. You can just run brew install sdl2
• Publis the app and then run it. dotnet publish -r osx-x64 and then dotnet <path-to-bin>

The first one is probably easier since it should just be a global install and will work with all programs you build.

I am going to try to figure out why the runtime isn't automatically locating the osx-x64 binary but IS finding the win-x64 binary.

[geoeo]

I copied .dylib into my bin folder and it works for now.

Thank you for the other 2 workarounds. I did not know about the publish functionality.

[mellinoe]

Glad to help. I will update the thread when I understand more about why it is not working as-is.

[mellinoe]

It turns out this was actually a bug in my NativeLibraryLoader project. It wasn't able to locate libsdl2.dylib in the nuget package if you're running on macOS 10.13 (High Sierra). The new 1.0.5 version of that package should fix this issue. If you manually add this to your project, it will upgrade that package and everything should work:

<PackageReference Include="NativeLibraryLoader" Version="1.0.5" />

The next patch for Veldrid will also update the dependency to 1.0.5.

Just to be sure: you are running on macOS 10.13, correct?

[geoeo]

Yes. 10.13.2.

I added the reference and it works without the binary.
Thank you for fixing this so fast!

Best,
Marc

[tzachshabtay]

Hi, is this fixed in 4.4.0?
I'm getting this error:

Could not find or load the native library from any name: [ libsdl2.dylib ]

When I call:

VeldridStartup.CreateWindowAndGraphicsDevice(wci, options, GraphicsBackend.OpenGL, out _window, out _graphicsDevice);

I don't get any error when I run TexturedCube sample or NeoDemo, though, not sure what I'm doing different.

[mellinoe]

Could you give more info about which versions of the packages you are referencing, which runtime you are using, and which OS (and version) you are on?

[tzachshabtay]

OS: macOS 10.13.2 (17C88)

Veldrid packages:

<PackageReference Include="Veldrid" Version="4.4.0" />
<PackageReference Include="Veldrid.SDL2" Version="4.4.0" />
<PackageReference Include="Veldrid.Utilities" Version="4.4.0" />
<PackageReference Include="Veldrid.StartupUtilities" Version="4.4.0" />

Runtime: Mono JIT compiler version 5.12.0.309 (2018-02/39d89a335c8 Thu Sep 27 06:54:53 EDT 2018)

[mellinoe]

I'll have to double check what mono does with binaries in nuget packages. It's possible that it is like .NET Framework in that you need to target a specific platform (e.g. x86 or x64) for the correct binary to be copied to your output directory. Could you try building for x64 specifically and see if that helps?

[tzachshabtay]

Same results (tried both x64 and x86, both debug and release).

[mellinoe]

What are you using to generate the project and build it with? With Visual Studio for Mac, I'm always getting an old-style project file, which doesn't support the new NuGet package convention for native binaries. In one of those kinds of projects, you can add something like this to the project:

<Content Include="..\packages\Veldrid.SDL2.4.4.0\runtimes\osx-x64\native\libsdl2.dylib">
  <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>

I'm not sure how you are supposed to be able to target mono using the new .NET SDK, although I managed to get it working with some hacks. It only wanted to deploy the native binary if I explicitly built for osx-x64: dotnet build -r osx-x64.

[tzachshabtay]

I'm using the new-style project file.
My project is here: https://github.com/tzachshabtay/MonoAGS/tree/veldrid
You can reproduce by running DemoQuest.Desktop from VS for Mac (which I assume is using msbuild and not dotnet cli?).

[tzachshabtay]

Hi @mellinoe, are you still looking at this? For now I've worked around it by copying the file directly to my bin folder.

The path from which I copied the file is: ~/.nuget/packages/veldrid.sdl2/4.4.0/runtimes/osx-x64/native
And I noticed that in the veldrid.sdl2 project the path is defined like this: https://github.com/mellinoe/veldrid/blob/d60e5a036add2123a15f0da02f1da65a80503d54/src/Veldrid.SDL2/Veldrid.SDL2.csproj#L21
I don't know what MSBuildThisFileDirectory means, but the native and osx-x4 look to be the opposite order than the structure I actually have?

Also seeing that in NeoDemo the path is defined differently:
https://github.com/mellinoe/veldrid/blob/d60e5a036add2123a15f0da02f1da65a80503d54/src/NeoDemo/NeoDemo.csproj#L36

Which looks a little suspicious as well?

[mellinoe]

@tzachshabtay I will try to improve the situation in the next release, but I'm not sure I will be able to get the experience as good as it is with .NET Core. I highly recommend targeting .NET Core if you are able -- there are many benefits aside from this one.

[mellinoe]

@tzachshabtay And as for the confusion regarding file paths:

• Inside a nuget package, native binaries have to be in a folder like runtimes/<rid>/native (rid being a "runtime identifier").
• In a deployed application, NativeLibraryLoader will find native binaries if they are deployed to the same folder as the executable. This line will cause the file to be copied next to the executable and thus loadable:
  <Content Include="$(MSBuildThisFileDirectory)..\Veldrid.SDL2\native\osx-x64\libsdl2.dylib">
• In the git repository here, they aren't necessarily in a path that's consistent with how they appear in the NuGet package. That's just me not fully paying attention to that little detail.

I don't know what MSBuildThisFileDirectory means

That's just an MSBuild variable that stores the full path to the directory containing the current script.

[tzachshabtay]

@mellinoe I hope to target both .net core and mono eventually. Targeting just .net core is just not an option, though, as it doesn't support Windows 7 (and Android & IOS as well), also Mono supports more linux distros from what I can gather.

Not sure I understand your explanation regarding the file paths.
NativeLibraryLoader needs the file to be deployed to the same folder, but it wasn't, right? That's the problem. So where's the script that is supposed to be deploying the dylib at?

[mellinoe]

Targeting just .net core is just not an option, though, as it doesn't support Windows 7 (and Android & IOS as well), also Mono supports more linux distros from what I can gather.

That's true regarding Linux and Android/iOS, but .NET Core does support Windows 7.

NativeLibraryLoader needs the file to be deployed to the same folder, but it wasn't, right? That's the problem. So where's the script that is supposed to be deploying the dylib at?

Yes, that's the main problem here for mono. In .NET Core, no script is needed because it pulls them automatically out of the NuGet package. For mono, I need to add something like this, using NuGet's "old-style" build hooks.

[tzachshabtay]

Ah, thanks, not sure why I was under the impression that it doesn't support windows 7.

In .NET Core, no script is needed because it pulls them automatically out of the NuGet package.

Interesting, how does it work exactly? Any binary file in the package get copied? Or do you mark to be copied in the nuspec or something?

[mellinoe]

Interesting, how does it work exactly? Any binary file in the package get copied? Or do you mark to be copied in the nuspec or something?

It's convention-based. You put the binaries under a specific folder structure that determines which "runtimes" the binary applies to. runtimes/win-x64/native is the folder for native binaries that apply to 64-bit Windows. runtimes/linux-x64/native is the folder for 64-bit Linux binaries. And so on.

[tzachshabtay]

Hi @mellinoe so while this problem is definitely fixed on mac, I just got around to testing on Windows 10 and I'm getting "SDL2.dll not found" on startup (using DNF 4.6.1 and Veldrid 4.6.1).

[mellinoe]

@tzachshabtay Are you targeting a specific architecture (x64 or x86)?

[tzachshabtay]

@mellinoe no, I'm using Any CPU.