Building the .NET Core SDK on FreeBSD #1139
Comments
|
even source-build needs working SDK and that is problematic since lost build servers. I was planning to revisit the effort but closing on 3.0 prevented me from spending any reasonable time on it. Aside from that, more cleanup may be needed to deal with OS differences. |
|
I've already tried to use the old (December 2018) but working .NET Core SDK for FreeBSD as bootstrap CLI as described here. But when running ./init-tools.sh it produces the same output as above and doesn't finish even after several hours. I could spend some time trying to re-enable .NET Core for FreeBSD, but I need to know where to start because the current documentations don't help me much if they don't work. For example, it would be helpful to know why the build servers were lost and how the .NET Core SDK for FreeBSD that I mentioned was created at that time. |
|
That is something source-build gurus should comment on. Published SDK was built by bootstrapping each needed repo separately and by publishing and consuming intermediate packages. As more repos moved to Arcade, lot of the build process was in flux. I would not be surprised in documentation or code is out of sync. |
|
We've changed our process so that repos are cloned as part of the build process to |
|
Yes, init-tools is indeed failing. The first error was a problem with the SSL certificate while restoring NuGet packages. I could fix it by setting the |
|
It looks like dotnet has problems with the linux-c7-openssl-libs package. I installed it on my FreeBSD machine to ensure full Linux binary compatibility, because the first time I ran ./build.sh I got After removing this package, reinstalling the default OpenSSL package for FreeBSD, and creating the required symbolic links, running ./init-tools.sh using the .NET Core SDK for FreeBSD as bootstrap CLI succeeded. |
|
Ah, that looks like Darc (the tool we use to clone the source) doesn't build for BSD. I wonder if we can build that portable, I will take a look. Otherwise this is probably a fix in dotnet/arcade-services. |
|
I was able to build Darc on FreeBSD using target framework netcoreapp3.0 instead of netcoreapp2.1. Cloning the repos now seems to work, but building them still fails. I have run I also ran So in both cases I get the error |
|
I've seen similar errors with missing syscalls on ARM. At this point it's probably less of a source-build problem and more getting into bootstrapping the actual SDK on BSD - there's a couple related issues: https://github.com/dotnet/core-setup/issues/5083, dotnet/installer#248, #724. |
|
Looks like it is a bootstrapping problem, but probably not as you expected @crummel: Although I specified to use the .NET Core SDK for FreeBSD as bootstrap CLI, the build scripts also downloaded the .NET Core SDK 3.0.100-preview5-011568 for Linux and placed it in the |
|
Replacing I've already taken a look at the |
|
AFAIK If everything (including the cli) built succefully, the result should be a |
|
That is great progress @joperator. Do you have any outstanding changes or just something you need to set? |
|
@omajid: Then it looks like I have to build @wfurt: There are outstanding changes as well as some things you need to set to successfully run |
|
Very good @joperator. I'm hoping to get newer version of the SDK published (closer to 3.0 final content) but I could not build some components again. If you get build working it would help me with that effort. As far as the Linux SDK: I made changes in several components to recognize FreeBSD properly. I was on Linux path for a while until I realized that is dead-end path. Even if the binaries work under emulation it still uses many files from /proc and that will not work on FreeBSD. Getting source build working is best long-term option for FreeBSD. I would still like to build components using published sdk to avoid regressions. |
|
I agree with you @wfurt:
Therefore, here is a complete list of the necessary settings and changes to build the Install and configure required packagesInstall git
Install libunwind
Install and configure bash (Building-.NET-Core-3.x-on-FreeBSD)Install and configure OpenSSL (dotnet/coreclr#22124)Clone the source-build repo
Set your environment variablesPrevent the dotnet CLI from freezing with no output (dotnet/coreclr#22124)
Set the path of the bootstrap CLI (Use the bootstrap CLI to build source-build). I have used dotnet-sdk-latest-freebsd-x64.tar.gz as bootstrap CLI.
Build the source-build repoFix dotnet CLI versionReplace Replace the downloaded dotnet CLI for Linux with the bootstrap CLI for FreeBSDChange target framework
|
|
Known-good will fail if anything before it does, so that's probably what's happening. Could I get your whole |
|
Yes, of course. Here are the logs from the I had to split the And here are the attached |
|
It looks like Roslyn is failing, possibly silently if you're not seeing it: |
|
We did not build Roslyn in official builds as that is same on all platforms and comes in from NuGet package. We will probably need to submit fixes there to recognize FreeBSD as platform. BTW is there option @crummel to build just runtime instead of whole SDK? I know we want SDK eventually but getting at least runtime would be good milestone. |
|
I can build
|
|
that would make sense. Why don't you create PR @joperator and mention me as well. Master branches should be now open for 5.0 work. |
We can add |
Yeah, our process here isn't great and it's why we're working to drive down the number of patches. Currently I go into the |
|
It's more complicated than I thought @wfurt: |
|
That make sense. I bump to something similar while back with coreclr. I can ask around what the plan is. As 3.0 is almost done, I would expect we would use it for building at some point. |
|
Hello! I can get init-tools.sh work on FreeBSD 12 p9 Azure with DotNet3CLIVersion 3.0.100-preview7-012821 and BuildTools 3.0.0-preview7-27912-14 |
|
Hello! I've stuck on step
|
|
running Linux runtime under emulation may work for simple app but I think it is dead end. It is not only about binaries but also some managed code is built from different sources. For example process management depends and some other functions do depend on Linux proc and that is incomplete under emulation. Also note, that you cannot load FreeBSD libraries to Linux process. Using libgit2 from ports will not work wIth Linux SDK. You would need to get copy from Linux. After all the long threads I'm wondering if we need to assemble new bootstrap cli. We may be able to keep runtime as it but drop new skd on top of it. |
|
In parallel to the present approach we are pursuing, does anyone know top off the mind what is the first .NET Core release that could be built without an SDK and where build instructions can be found? Maybe this rabbit hole will turn out to be somehow easier and more sustainable than setting up and maintaining these cross-build pipelines (maybe I will regret even asking 😄). For example, if it turns out that any SDK can be built by bootstrapping using .NET Core 1.0, maybe it will turn out to be quite a viable path. However, early versions are likely to have plenty of linuxism so whether this is a viable path needs to be seen. Anyway, clarifying the minimal SDK version we need to target for bootstrapping will be helpful even for setting up the cross-build pipelines (in an ideal world we do not want to have to update the bootstrapping SDK). |
|
,NET of given version needs .NET SDK of the same version to bootstrap, bootstrapping on anything lower is not realistically possible. |
|
Using Microsoft's feeds you can start at 3.1. This will be an ONLINE build however: so 3.1 (with patches) -> 5.0 (with patches) -> 6.0 (with patches) -> HEAD/7.0 (no patching needed) EDIT: @jkotas beat me to it |
|
I've added a new scripting interface for building with the cross-build repository all in docker. The scripting still needs some edits, however. Before integrating it fully with a patch set for a contrib fork of the cross-build repository, I'm trying to test it out with Docker on Debian 10. Ideally, this would be pursuant to testing it in Docker under GitHub Workflows/GitHub actions. In a partial test for the Docker image, the build was failing in the runtime repository. This may have been due to a version mismatch? namely for the SDK installed under runtime/.dotnet and the SDK version specified in runtime/global.json. External to the .NET build scripting, the top-level scripting for this build-it-all-in-docker approach would cache and install an SDK of the version in each repository's global.json under each repository's .dotnet for each repository before the build. That was skipped for the initial test here. The build under Docker may have drawn in some artifacts from when I was trying to test the same scripting outside of Docker. Those builds outside of Docker were not successfull. Reviewing that this morning, it seems that the build ID must have a specific syntax. Referring to the original build.sh in the cross-build repository form Thefrank, I'll update the scripting for that part and retry the added build scripting outside of Docker. |
|
While testing the patch for adding a Docker-focused build scripting in the cross-build repository, I've tested the patched code on a Debian 11 bare metal install and with a chroot environment on FreeBSD, the later installed with the sysutils/debootstrap port. The patch would be an adaptation of the original build.sh at the dotnet-freebsd-crossbuild repository. I was hoping that it could all be run within a single docker image (or independent of docker). I've been testing it outside of Docker, before testing any new Docker images for it. In a couple of .NET runtime releases for .NET runtime and AspNetCore version tags in the 6.100 series, the build fails persistently with errors similar to the following: I'm not certain if a workaround can be patched on to that. Those version strings, I think, are hard-coded into the runtime repository - it might be kind of etched into the chrome, for all of the cross-repository version dependencies? The build has presumably not failed as so, on any Windows runtime environments? Such an error about version strings was occuring when beginning with dotnet-sdk-5.0 or dotnet-sdk-6.0 under Debian 11 on a bare metal install and Debian 11 under chroot on FreeBSD. Maybe there's something in the Microsoft docker images that somehow prevents such an error from occuring (??) Seaching for a file presenting that version string to the build, nothing actually shows up with an exact match. There are version strings with a similar syntax, throughout the Maybe it could work out under some earlier release tag. The message above was from a build for the dotnet-runtime repository under the v6.0.3 release |
|
Starting with a new openSUSE Tumbleweed installation under Bhyve (EFI/GPT in the vm-bhyve configuration, accessing via ssh for build) I'm seeing some more success with the local adaptations on the cross build scripting. Using the .NET Core runtime and AspNetCore repositories each at release tag v6.0.3, with the installer repository at tag v6.0.103, with patches from dotnet-freebsd-crossbuild for the dotnet upstream repositories, then in running the adapted build directly on openSUSE, it at least reaches the cmake part of the cross-build. At eng/native/tryrun.cmake the build seems to expect a file After some tooling with FreeBSD /usr/src/release/Makefile under a local FreeBSD 12.3 build on the stable/12 branch, I have a base.txz available. I'll try installing that under the CROSS_ROOTFS dest then running the build again. iirc the docker scripting that has been available for the cross-build was using Ubuntu 18.04 in the docker instance. Maybe there'll be some more progress starting with openSUSE and Bhyve? For community review, I'll add my adapted build scripting to my own contrib fork on dotnet-freebsd-crossbuild then add a back link here For automating the build, If using GitHub for the build automation, GitHub may not have any GitHub Actions support for Bhyve as yet. They do support Docker. I'm sure there must be a Docker image available for openSUSE, as a starting point. If automating the build with Bhyve, there's vagrant (ruby)? Alternately, for automating the build with openSUSE for the cross build, if developing something like an intermediate distribution channel in RPM form for the cross-built parts, there's openSUSE OBS. If I can get the build worked out locally, it should be fairly straightforward to port it to an RPM spec file for the OBS build. Theoretically, this distribution approach could be applied as to produce multiple versions of the cross-built parts under one RPM repository, using openSUSE' distribution services. Those could then be used from any single port build for FreeBSD, obviating any theoretical virtualization tooling in the port build. So, hopefully it works out past this cmake part, on openSUSE. I'll work on publishing the added cross-build scripting, then back to the build in the cmake part. |
|
An entry point for the docker-oriented cross-build scripting, but for running the cross-build on some Linux outside of docker : entrypoint_local.sh. This script calls actions/entrypoint.sh with a build environment configured for building outside of Docker. This repository is a contrib fork on dotnet-freebsd-crossbuild Tools needed in the build environment: jq; git; patch; sed; tar; gzip; wget; dotnet; bash Working on an update that installs a FreeBSD base.txz (--no-fflags) for a cross-root dir before the build (done), now to figure out the cmake parts in the scripting for the dotnet/runtime cross. |
|
Here is how the crossrootfs is generated for the docker images: It has been more than a year but the environment setup from that allowed for crossbuilding the FreeBSD runtime from inside Ubuntu (18.xx??) I might have some time over the weekend to tinker with this but no promises |
This file as a script that works like |
|
It seems that it will need some packages from ports installed under the cross-rootfs, i.e under the FreeBSD base system that will be installed temporarily under some Linux environment. For this, of course it might need a look at the FreeBSD ports tree. So far, I've discovered that these pkgs from FreeBSD will need to have been installed under the FreeBSD base system in the cross-rootfs dir:
For ensuring lttng-ust would be available at least for testing, I've sent a tenative patch for sysutils/lttng-ust to FreeBSD bugzilla. This would update the port to the latest upstream release, 2.13.2. Candidly, I understand that I may not be well enough familiar with the C language and that project's source API enough to really test the patch or to provide any substantial quality assurance about it. At least the headers and library from the pkg might be available now, for local testing at least. Hopefully, the cmake part of the cross-build can now complete that part of the build. Of course, I haven't tried building the FreeBSD pkg tools on Linux. I've used bsdtar to extract the pkg files under the crosrootfs dir. It seems that the cmake scripting was able to find the headers and library files from there. For scripting the FreeBSD pkg files-installation for an automated build, it looks like the FreeBSD packagesite.txz file contains some JSON data. Like in the original build.sh and the added scripting in contrib, and once all of the deps in FreeBSD packages are available from some package repository, of course the JSON can probalby be parsed with jq, towards automating the pkg retrieval in the cross-build under Linux. For the testing insofar as for the cmake part of the buiild, I've been using pkg builds from my local Poudriere package tree, with manual scp and tar/bsdtar. I've updated the scripting locally for the part, "Install a FreeBSD base system under a Linux environment". It might serve to link the build to some major/minor version pair under FreeBSD - I'm testing it with FreeBSD 12.3 locally. I'm not all sure of how to approach the pkg part for scripting. I'm sure it will use jq. I'l need to put a web server together for the pkg repository at site, though - might try Ruby on Rails for this ... After some more cleaning in the dotnet source trees I was working with locally, then adding a 'clean' action to the entrypoint.sh script, a lot of the build errors I was seeing with the version-mismatches have cleared up. Building under openSUSE, the dotnet/runtime cross-build has reached a part of the cmake build where it needed those pkg libraries and headers available in the cross-rootfs, before generating the makefiles or the ninja.build file. Hopefully the patch for lttng-ust may work out. I'll try to update the scripting for fetch from some local kernel and pkgs distribution for testing the cross-build |
FWIW, there's a bundled copy of libunwind in dotnet/runtime. Perhaps you can use that instead (at least initially)?
Please note that 2.13 is actually incompatible with .NET runtime: dotnet/runtime#57784. It might crash or just not work. |
Oh these side effects. TY for mentioning. If the build is building dotnet/runtime from source, maybe the soname linkage may not be an issue for the FreeBSD cross-build? I can only hope. Will see how it goes, hopefully, once the build-deps are worked out. Good to know if lttng-ust 2.13 may not be ABI-compatible with 2.12, I'll add a note to the port update ticket. TY! fwiw with dotnet testing under openSUSE at least, openSUSE publishes liblttng-ust1 at 2.13.0. Reviewing the RPM dependencies for the dotnet-sdk-6.0 components installed on the openSUSE machine, liblttng is not listed there. It doesn't look like they've bundled the library in the RPM dist. Of course, the dependencies may be diferent for other SDK versions. I've not yet used the dotnet tooling extensively under openSUSE, I was trying it out for building the omnisharp-roslyn C# language server with its cake build tool (old source code, newer is probably here). I don't know if any of the build errors I was seeing may have been due to lttng-ust. I'll try to find a clean test case for this, lol. In the cross-rootfs fwiw it also needs a Kerberos impl (heimdal or mit krb5) for the gssapi support. I'll try to publish an update for the build script, it may not yet include any support for selecting and installing pkgs under the cross-rootfs. The build is building locally - it's in the cmake part of the dotnet/runtime build, compiling with clang. So, Yay! The cmake scripting for the dotnet/runtime cross build was trying to locate the libraries and header files under the FreeBSD cross-rootfs. Assuming all of the build deps can build under ports, I've been trying to install from a local ports tree at least for testing the build-scripting. Albeit, with some patches applied to the local ports tree, perhaps it's not a clean build per se. The defaults will all be configured for a FreeBSD base system and FreeBSD pkgs, assuming all the deps are available w/ FreeBSD core Published the latest updates for the contribution in build scripting under the contrib branch for the cross-build For the build deps, I'll try setting up a new bhyve VM using an official FreeBSD 12.3 release, then building the cross-build deps from the local ports tree under that VM, without any local make.conf additions and with only the patches for the liblttng-port under the portsdir. The resulting pkg files could then be published separately - unofficial pkg files. These might at least serve to facilitate a build for a FreeBSD 12.3 cross, with all the build-deps available. With root on ZFS under the VM, it should be easy enough to roll it back to the baseline installation, for each build. Sure, it's no Poudriere though lol. If anyone may be interested in taking a look at the contributed build scripting, while a liblttng-ust built for FreeBSD might be required for the cross build, I'll publish a link to some project here at GitHub once the pkg dependencies would be available for the build. fwiw the build failed at a point that may be beyond my own range of experience with programming languages. I will try to take a look at the source code though, and maybe running this under Build EAR (Bear, FreeBSD port devel/bear) to record what the compilers are doing. This was with a dotnet/runtime source tree at v6.0.3. Compiler is clang-13 from OpenSUSE Tumbleweed |
|
I noticed the Also, as a heads up for net7.0+, |
fwiw in tracing it across the build files, with dotnet/runtime version v6.0.3 there is the following in dotnet/runtime source file in This adds whitespaace to the head of the value interpolated from input to the script, which is then produced vertabim in To pad with leading zeros and encode as hex, perhaps it could have used: fwiw the value is used conditionally, in the definition of The imo with as well organized as the patches are for this cross-build, this update would be trivial, to simply remove the whitespace formatting spec from the initial printf in that script
Good to know. I wonder if there may be any options for provider selection in earlier releases? fwiw I'd noticed the .NET 7 release tags in git ls-remote. If it was not for the original crossbuild repository, tbt I would not even be able to guess my way through this build, lol. (still catching up) I've been focusing on .NET 6 mainly due to it being after (??) .NET Core and that it's referenced in at least one project I was trying to build. If I can work out the additional build tooling for a .NET 6 build, then after some tooling for a distribution channel and for independent verification of the build, I'll try to focus on producing a .NET Core build and something in the .NET 7 sources. Of course, there may be a few options available for automating the base-system build and the cross-build. After a successful cross-build with any single service mix, I think it should be possible to produce a port that would assemble the installer parts for a port installation on FreeBSD. If there's a docker image for FreeBSD that could be used with the GitHub Workflow/Actions scripting, it might even be possible to produce a pkg build for the port, for installation to any system using a FreeBSD base system and kernel corresponding with that used in the cross-build.
fwiw for the local build testing, in the machine that is running the Bhyve system, which is running the openSUSE system that I'm testing this with, the FreeBSD host was built with If that build option may not have been used in the base system installed under the cross-rootfs, perhaps the dotnet/runtime cross-build may not produce any support for dtrace in the built objects. If it was available in the original base.txz for the cross-rootfs, maybe that option would be available under the dotnet/runtime cross build? (assuming dtrace support is available on the installation machine) After taking a look with grep for the coreclr sources, it seems that a DTrace option may be available under some build configurations. If this can be worked into the cross-build for FreeBSD, it would probably not be difficult to add an additional feature to the distribution channel - to enable dtrace in the base system for the cross-build and then in the cross-built objects. tbt while I've been focusing on eventually trying to script the build with GitHub actions and Docker, I'd like to be sure that this can be built without GitHub actions scrpiting. If it can be produced with bhyve, ideally the whole build could be produced with one machine. This might make it easier to add and test different build options across the cross-build distribution channel. Furthermore, it could serve to ensure that the cross-build would use the base.txz and build-deps from ports, using any local FreeBSD base system build and e.g a pkg tree built with Poudriere. Poudriere itself might provide some support for automating a kernel build, such as in producing a builder system for port builds. Maybe it could be used in more of the automation here. Of course it might also need bhyve, if building for a target release outside of some version range for the FreeBSD release on the host machine. For the dtrace option, if there may not be an official FreeBSD build with dtrace enabled, then an unofficial build + corresponding build-deps might be required for that feature. I think it can be worked out, with some scripting for Bhyve and poudriere. |
|
I was able to build a working dotnet SDK using openSUSE Tumbleweed in Bhyve, an official FreeBSD 12.3 release, and some local port builds, starting with the dotnet-freebsd-crossbuild tree. For addressing the initial build failure in the dotnet/runtime section, and for addressing some issues I was seeing under the tests in the aspnetcore section, I've added a couple of trivial updates on the the original patch set from dotnet-freebsd-crossbuild. For the patch additions for the cross-build with dotnet/runtime, and for a certain node.js part under the testing for aspnetcore, I've sent the patch sets to upstream with separate pull requests. I was using the entrypoint_local.sh script, which I've been working on in a contrib branch. This calls actions/entrypoint.sh such that could ostensibly be used for automating the build with Docker under a GitHub Workflow definition. The scripts can be used independent of Docker. The most of the documentation is in entrypoint.sh. There are build dependencies listed there, including those for the build host and those for the cross-rootfs. The cross-rootfs itself and the build dependencies would have to be manually installed. For the cross-rootfs, I'd used a base.txz from 12.3-RELEASE/ unpacked with The build dependencies are listed in the script. For the GSS-API option, I'd used an mit krb5 build from the local ports tree. In order to build the lttng-ust build dependency for the cross-rootfs in the build, I'd made a patch on the local ports tree. The diff has been submitted to the ports section at FreeBSD bugzilla. After some fixes for the scripting I've been tooling with, then notwithstanding the quality of the local network, but it went pretty straightforwardly. To my best estimate with the tree I'm working with locally, the build needs up to 16 GiB of filesystem space. I'm going to take a look at running openSUSE in Docker ... lol under openSUSE in bhyve. If it may serve to provide a way to test out the entrypoint.sh script in a docker environment, hopefully it will be possible to automate the build and to put together some way to build the build dependencies independent of my local FreeBSD installation. Assuming that there would be a suitable range of SDK versions available from the cross-build approach, I think it may be possible to start building the runtime and SDK parts natively on FreeBSD. I'll try to test out the scripting under Docker and put something together for automating a build with GitHub Workflow Actions. I've tested out the SDK on FreeBSD for building a local VS project and for building the OmniSharp LSP support. Some network issues have prevented the later from completing in any resonable time tonight, but it looks like the cross-built SDK holds together, lol |
|
@spchamp I am both excited and intrigued by your progress because there is one thing that isn't totally clear to me: what is the goal? I tend to think that your end goal is to 1) create a FreeBSD port using bhyve behind the scenes to build the SDK, and 2) enable the .NET team to build for FreeBSD more easily upstream by providing them a docker image that they can automate using Github Actions. If this understanding is correct, for 1) are we sure that the build system of the official FreeBSD package repository will allow us to run bhyve to build the port? There are all sort of limitations there such as the fact that it is not possible to fetch anything after the fetch stage of the build progress. For 2) my (limited) understanding is that the .NET team uses Azure Pipelines to build .NET so I struggle to understand how the Github Action integration will help them. At the same time since docker is not supported on FreeBSD I assume that this is not intended to be used by FreeBSD users, so the goal of the Docker part of your effort is obscure to me. Could you please help me clarify the goal that you have in mind |
|
@nkosi23 although I've been looking at a couple of ideas for how to automate the build outside of my own own VM configuration, I don't believe anything is really concrete about it as yet. Presently, I'm simply trying to test the build under a certain VM configuration using openSUSE. I was pretty glad that the build actually worked out, though. After some further reading about some ostensible options for server-side automatation in some cloud network, I understand that it may not be possible to build the FreeBSD build dependencies under Docker here at GitHub. With regards to any ostensible Docker-based orchestration for build automation at GitHub: Although I have an openSUSE installation under Bhyve available for some initial testing, but it seems that the GitHub Workflow documentation favors Debian-based distributions for Docker automation. I'm assuming that that's what they're running on the servers - maybe they're using an Ubuntu release of some version. So, I'm going to test the build under a Debian-based distribution locally, before putting together anything in Docker with GitHub. That would not serve to address the concern of the missing build-dependency for lttng-ust. Without some kind of a patch for the ports tree, that port might not build for amd64. At last check, it seemed that there is not any pkg available for that port, on amd64, in official FreeBSD port builds at this time. If it may be possible to build a patched port tree for purpose of the build dependencies, of course that would have to be conducted outside of Docker - unless there would be some way to build a FreeBSD base system and a small number of ports for a FreeBSD system, within a Linux compiler environment, lol. If automating the build-dependencies part in some FreeBSD system, perhaps it could also serve to provide any build options for different GSS-API implementations within the cross-build environment and thus within any installation environment (e.g MIT krb5, heimdal, or krb5 in the base system) and for DTrace support in the build. Coordinating this with some Linux-based system for the cross build may not be posible singularly at GitHub. I'll try to take a look at what I may be able to put together for an independent build server with Azure DevOps or alternately, DigitalOcean, for automating that part of the build. Perhaps it might be too much of a hack to try to build a FreeBSD base system and any number of ports, if within qemu with Docker orchestration at GitHub. Assuming that the entire build process can be automated for any single set of .NET SDK and framework versions, perhaps it may be possible to automate some method of traversal across different SDK and runtime versions, for building any additional releases with a similar methodology. Subsequently, perhaps the cross-builds produced under Linux could be used to produce any builds independent of the cross-buld orchestration, on some FreeBSD system - ostensibly independent to anything related to any FreeBSD brand name, other than in the uname aspects, and source and distribution rights. Assuming then that this will have to be produced entirely independent of anything related to any official FreeBSD project, other than in the source code and legal aspects in the software distribution, then in order to make use of any such unofficial .NET SDK and runtime builds on a FreeBSD system - there are a few more bases to cross, before that final stage in the distribution concern. For local builds, of course there's Bhyve, or Linux Containers, or the ostensible "bare metal" Linux installation, or even Qemu, furthermore any analogous systems that may be available on other operating systems. Under one configuration, the buld has worked out with openSUSE under Bhyve. Candidly, that is about the limit of what I have in mind. Health, all. |
@spchamp, In case you are not already using it, there is a |
|
So, how is the progress? Did we come any closer to having modern .NET stack in FreeBSD ports? I've noticed that @sec is updating his repo more or less regularly (last commit being this year), are there any connections between his work and upstream? In FreeBSD ports, we currently rely on Mono to build C# projects, and recently some developers become more feared it's being phased out, sometimes dubbed as "dead upstream". While this is not quite true AFAICT, there's clearly an increasing demand for modern .NET implementation which FreeBSD is unfortunately lacking. Update: I've discovered a more actively maintained issue with very recent status update. Sorry if it was referenced earlier, I must have missed it in this case. |
|
@danfe very close. There are a few issues I noted in https://github.com/dotnet/runtime/issues/14537. There are two matching PRs open to fix the R2R issue. The others need to be opened/fixed here in source-build. After the above PR's, the build process would look like: Additional considerations when building:
|
|
@danfe we now have .net 8 port in FreeBSD ports tree, ready for use (x64 and arm64). |
|
With lang/dotnet in FreeBSD port I think think this is safe to close? The port uses the VMR with a prebuilt bootstrap and some script work to make sure it works under the constraints of FreeBSD's build and pkg servers. Those wanting a portable build can always use either a) cross-building from Linux or b) native non-VMR building. The patches from ports should be enough but there are a few PRs for future versions of dotNET that portable builders should either cherry-pick or wait for them to get merged (e.g. FreeBSD RID, OpenSSL3 support) |
This FreeBSD port is very good for installing a ready-to-use .NET SDK on FreeBSD (something I've wanted for years). However, maybe I'm a bit traditional, but I'd still like to have some kind of documentation on how to build the .NET SDK on or at least for FreeBSD using native build and/or cross-build on Linux. |
|
@joperator the port uses dotnet's VMR to generate a non-portable build. if you have a ports tree setup, you can just If you want portable native builds @sec has an excellent set of scripts setup for that and even publishes SDKs with a handful of NuGets If you want portable cross-builds from Linux I have a repo for that. I publish the SDK along with NuGets too. I do however need to spend some time improving the scripts as the default container switched from ubuntu to cbl-mariner and that breaks a number of things. Both of us maintain our own NuGet feeds if you just need NuGets. My general advice is to use the port as Finally, for official documentation? Well, FreeBSD is still a community supported platform so it only has instructions to build the runtime repo and nothing more. The FreeBSD wiki entry might be a better place but it needs some updates. The only major difference between natively building and cross building from Linux is that the native builds need a working SDK and a handful of NuGets setup before hand while the cross build can download just about anything it needs from Microsoft's feeds. The cross build requires docker unless you want to create your own crossrootfs. |
|
It's not an official documentation, but your comment is something I asked for: A quick overview where to find scripts and instructions to build the .NET SDK on/for FreeBSD. Thank you very much and it's great to see how far the community has come with this. 🎉 |
|
Maybe we should put some additional code to the port to ease cross-compiling? Like, some knobs or targets hidden in the Makefile that may be adjusted/ran by the end user. |
and others
I'm trying to build the .NET Core SDK on FreeBSD but I'm having trouble with the documentation.
The documentation says I just have to initialize the submodules in the source-build repo and run ./build.sh. But this produces only the following output:
Later in the documentation it says that
But after running this command, my src folder contains only the subfolders netcorecli-fsc and reference-assemblies, which are not all required repos I think. As the documentation says, I expected at least core-setup, standard, corefx and coreclr to be cloned into the src folder.
This would also explain why there is no bin folder in my source-build repo after running ./build.sh as described in the documentation.
If the scripts don't work under FreeBSD, I expect at least an error, otherwise I assume that everything has been built, which is not the case here.
So, am I doing something wrong or is the documentation incorrect or out of date?
The text was updated successfully, but these errors were encountered: