-
Notifications
You must be signed in to change notification settings - Fork 538
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
Distribute Linux Binaries for .NET Core on NuGet #312
Comments
For people looking for prebuilt binaries: there is a prebuilt nuget package maintained by AvaloniaUI team. Despite the name it only contains Regarding providing prebuilt binaries in official package: Please, link libstdc++ statically and use something with sufficiently old GLIBC as your build machine. This will allow to produce a single binary for almost every modern distro. Ubuntu 14.04 is a good candidate for that since it has GLIBC 2.19 and modern compiler toolchain available from official repositories |
@kekekeks, I am trying to use this package with .NET Core 2.0 in linux in a container based on https://hub.docker.com/r/microsoft/aspnetcore/ and get runtime exception
though I can see the file in the output folder |
Try to use self-contained deployment, something like:
It should properly pack all dependencies for you. You can also use |
@kekekeks thank you for your response! I have tried different docker packages and different runtime configurations like |
Check if you have all dependencies in your docker image. You can find them using You can also try |
@kekekeks I run |
I have done |
Isn't https://www.nuget.org/packages/Avalonia.Skia.Linux.Natives/ outdated? |
Do you need any particular feature of the recent SkiaSharp? It's kinda troublesome to build portable Linux binaries, so we avoid updating it unless it's really required. |
No, it was just a question. |
What about a native library for Raspberry Pi (Raspbian)? Any news on the Linux ARM front? |
You need to build it manually. I think @mterwoord had some success with ARM |
See https://github.com/terwoord/skiasharp-raspberry for my script. PR's are welcome! |
@mterwoord thanks for the information. So this is a cross-compilation, right? Would it be possible to compile skia/skiasharp on an actual Raspberry Pi? Did you try it? |
This is cross-compilation, correct. I think I tried it, but the google tooling isn't available on arm. |
@mterwoord nothing special, just out of curiosity. It is actually much easier and faster on an Ubuntu VM for me... |
That's my whole point.. ;) |
@mterwoord it seems I need something on the 'rpi' directory. Could you add instructions on your readme file on how to configure your 'skiasharp-raspberry' base directory? |
Edit build.sh, fix the BASE_DIR. |
Ok, this wont' work with an empty base directory. I think you need to describe what goes on your base directory. An empty one won't work, obviously:
|
Start off with installing qemu-debootstrap. |
I've already installed all the prerequisites as per your README file. |
Well, my readme may be out of date. qemu-debootstrap isn't installed as it seems. |
Ok, you need to add 'qemu-user-static' as a prerequisite, qemu-debootstrap is on it (ubuntu 16.04). I also had to install 'apt'. Couldn't you add the install commands of all prerequisites to the script itself? |
Could you make a PR for that please? :) |
When I run the chroot line
Don't know if this is relevant: the preceding qemu-debootstrap runs successfully, but at the beginning it shows the following message |
Got it working with ubuntu 17.10 on a separate VM (WSL didn't work). |
@mterwoord @toburger I was also able to compile the library successfully. I modified the script a little bit and will make a PR soon. I found it strange that the compiled library is a 32-bit one, I thought that Raspbian was a 64-bit OS... |
Any reason why you want 64-bit apps? They consume more memory...
2017-11-30 13:08 GMT+01:00 Daniel Medeiros <notifications@github.com>:
… @mterwoord <https://github.com/mterwoord> I was also able to compile the
library successfully. I modified the script a little bit and will make a PR
soon. I found it strange that the compiled library is a 32-bit one, I
thought that Raspbian was a 64-bit OS...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#312 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAG9301aQ14pTCYB8_1o5CLUf5xI-KK0ks5s7pqxgaJpZM4N0Mhv>
.
|
@mterwoord nothing special, I just thought that raspbian was 64-bit and was unconsciously expecting a 64-bit library. |
@mterwoord I've submitted a PR, please take a look. |
For Linux, I suggest that we package/distribute independently the unmanaged bits using the proper system packaging tool, and not try to solve the problem with NuGet. Details here: #365 |
I've tested the arm native library with my rasp 2, it worked on Ubuntu MATE normally. On Raspbian Stretch, it seems that the g++4.8-multilib library is missing from the default apt-get repository. I didn't try to find one and went back to Ubuntu. |
Curious, what behavior do you see on raspbian? |
@mterwoord nevermind, I was putting an unnecessary dependency on g++4.8-multilib, which doesn't exist on Raspbian. The library worked fine on it too once I removed the dependency. |
Just asking this question in multiple places: Right now I have a x64 build for Linux that was compiled on Ubuntu 14.04. I am thinking of adding a few more to help the average dev use SkiaSharp without having to build their own. What other distros or CPUs would be helpful? Leave a comment on this issue and track progress: #453 |
As long as you are linking libfreetype and libstdc++ statically, that x64 library should work across all modern glibc-based distros. |
To make life easier for everyone, I moved code around and added a new target to the GN files. Now, the native |
All right folks, I have been doing some work and I think I am able to meet you in the middle of "we don't really support Linux as it is not a priority" and "using Linux is a real pain because of X". Let me know what you think of this: I have created a new package The overall result of this is that you will do everything as usual, but in the "app" part of the solution, just add the package. You should not release a NuGet to nuget.org that depends on this directly as you will then force all your uses to use my binary. An example of a use case where a separate package is useful is this:
(Hope you folks like my story about Matthew and the Big Boss working to make life better for John, Janet, Joe and Jane. I had fun.) |
Closing this as it is going out. Although it just has a single debian-based binary, more can be added if there is a demand. Since .NET Core is on Alpine, that will be the next build most likely. To request a particular build of Linux to be included in the NuGet, just add a vote/comment to this issue and I will make sure to keep adding the most popular ones to the package: #453 If there are any issues with the new Linux bits, just open a new issue and let me know. |
For most users of the common linux distros (Ubuntu, Debian, Red Hat, OpenSUSE, etc) it may be possible to distribute a binary in the NuGet package.
There are some limitations and reason why this is not such a good idea, but this is just an issue to track this thought.
Just want to link the main, but old, linux issue: #90
To make life easier for everyone, I moved code around and added a new target to the GN files. Now, the native libSkiaSharp build is done with GN and ninja directly: https://github.com/mono/SkiaSharp/wiki/Building-on-Linux
The text was updated successfully, but these errors were encountered: