Runtime: FreeBSD ports port

[josh-endries]

Is there any work underway to create a FreeBSD ports system port (and/or package) of CoreCLR/.NET? I haven't found much online, only that it's allegedly possible to build CoreCLR on FreeBSD (I haven't succeeded in that yet), but nothing about a port. The runtime page doesn't list FreeBSD. This would virtually eliminate any barrier to entry and make it much easier/standardized to administer.

Note that this isn't the same "port" as referenced by this issue.

[jkotas]

cc @josteink @ajensenwaud

[josteink]

As I'm not on the FreeBSD development team (and I don't think @ajensenwaud is either), I cannot really provide any more definitive answer than "I don't think so".

@emaste (responsible for among other things LLVM/LLDB for FreeBSD) has assisted this project in the past and is probably much more likely to be able to help in this matter, both in getting an answer, and in getting things moving, if they need to be.

[josteink]

@fzzzt you say you have tried building yourself, but that you failed. Did you follow the instructions outlined here?

If not, please try that first.

If you did, feel free to raise an issue where the documentation don't seem to match what you're experiencing.

[josteink]

My third and absolutely final comment for the day (as someone who didn't really have much to say...):

Back to the root of your question: Is there an effort to create a FreeBSD "ports" package for this?

As I understand it, a FreeBSD "ports" package actually represent a fork of the software in question. Ports' screen is not GNU Screen. It's FreeBSD's fork of GNU Screen with the patches required to make it play nice on FreeBSD and with the source hosted by FreeBSD too. Thus, a FreeBSD _port_.

The FreeBSD CoreCLR porting-team (Github & Coreclr/Corefx only, 100% independent of the official FreeBSD development team) always had as a goal to make CoreCLR compile cleanly on FreeBSD without the need for any additional patches.

So if someone is going to make a "port" of out the already ported codebase... What is that going to be? CoreCLR is now actually released and has a version 1.0 out there. Should the port (for now) be that version? Etc etc.

I guess there's no need to decide all those things now, but I just wanted to ensure that everyone is aware of those particular technicalities.

And with that said... Have a good evening, a stellar summer and happy porting :)

[josh-endries]

I did try to build it, and failed, and tried and failed, and gave up. It's not currently possible to build it on FreeBSD, period. One actually needs to build part of it on Windows currently, so a port just isn't possible at this time. I did point out in another issue that the dependencies weren't complete, before I moved on to other work.

Disclaimer: I'm not a FreeBSD port maintainer, just a FreeBSD user. This is all based on what I've seen and read over the years, and I believe it's accurate, but I didn't design any of this stuff so I might be wrong somewhere.

The terminology is a little confusing/overloaded, which is unfortunate. "FreeBSD ports" aren't forks; they aren't source code. The term "port" here doesn't really have anything to do with porting code in that sense, it's just the name of the artifact. Originally it may have meant significant source code changes. The "FreeBSD ports system" or "ports tree" is a set of metadata and scripts (mostly Makefile files, IIRC) that users use (via make) to manage software, similar to Choclatey or NuGet, but with source code. Those software instances (i.e., each individual program, like screen or mysql) are referred to as "a port"--but that doesn't mean any source code needs to be ported or duplicated or forked. These individual ports are organized into a tree based on category, like "database" or "devel", hence the collection is "the ports tree". Some ports don't even really deal with building and just download a shell script somewhere for use (after verifying its hash). Ultimately, it's just a set of 20,000-ish scripts for managing software. Ports include other metadata, such as dependencies, baked into the Makefile files. To install something (and its dependencies) a user would just run, e.g.:

cd /usr/ports/databases/mysql56-server
make install

or

pkg install mysql56-server

Other standard targets include uninstall, reinstall, clean and package.

The ports system doesn't store any application source code--there are no forks at that level, and usually no fork is required. It's possible that the best way to create a FreeBSD port involves forking the source, but I don't think that is common. Usually, I think, the original source is used, and patches are applied, if necessary. Those patches _are_ stored in the ports tree, so in that respect one might perhaps think of it as "porting" the original source to FreeBSD, but not via a fork, via a set of patches. The source code isn't hosted by FreeBSD, it's fetched from wherever it's stored, be it in GitHub (which might imply that git is a build dependency), an FTP, a .tar.gz file on organization's web site, etc., the scripts handle that.

It is sort of like maintaining a yum or apt-get package for Linux, only you maintain the script/patches needed to create that package, not the binary package itself. Those scripts are what gets distributed. FreeBSD's binary packages, which are managed using the pkg command are, as far as I know, essentially pre-built and zipped ports, for a particular release, to skip the build step. The FreeBSD foundation, I think, has build servers which will run those scripts (in other words, the port) in the ports tree and automatically build binary packages for use with pkg, so the pre-built package step (similar to Linux packages) is handled already, from what I understand.

If the CoreCLR team's goal is a clean build on FreeBSD, which really is the ideal situation, that simply means the ports tree would have no patches. The install target would probably just ensure that the dependencies are installed, then download the source from a certain label in the coreclr Git repository, build it and install it, just without applying any patches. I think it is also possible, if the team builds binaries for distribution, that the port downloads the binaries and copies them into /usr/local/bin or wherever. The tricky part there is ensuring that they work on all supported versions of FreeBSD (the ports tree is version-agnostic whereas pre-built packages are version-specific).

Anyone can submit a port to the ports tree, if they know how to build/install/configure the software, what to modify (if necessary) for FreeBSD, and how to set up the ports build stuff. I don't know how to do that, which is why I asked, I'm just a FreeBSD user, but I also didn't know at the time what was involved in building it on FreeBSD. I hope it gets to the point where a port will exist (which allows other things to automatically depend on it), and the port will simply be a fetch-and-make situation.

[josteink]

@ajensenwaud the interroute VMs we set up for initial development are not currently responding to incoming connections, so I cannot verify this issue. Can you have a look at that?

[josteink]

@fzzzt Thanks for all the technical details on the ports system. I'm not entirely up to speed on all its inner workings behind the cd /usr/ports/* ; make # it so so that's appreciated, but apart from that I've been a happy ports users in the past. I know the basics :)

If what you say is technically accurate, making a ports package for CoreCLR sounds fairly simple. At least given that everything else works. So let's get back to what you say are _not working_.

So in what way do you mean the build does not work? In what part of the process does it fail? How does it fail? With what errors? And what FreeBSD release are you testing this on?

Because clearly this thing _can_ be built on FreeBSD. The CI-status for the FreeBSD Debug-build is green after all. (And the release build is ok apart from a test failure on thread timings. Those tests are known to be a bit unstable on FreeBSD).

You say some parts of the build requires Windows (the managed components). That _was_ certainly true in the past, and definitely so when the FreeBSD build documentation was originally written. Currently though, these components should be buildable on non-Windows systems, as demonstrated in both the Linux and OS X build-instructions.

Is this where you've given up? If so, what happens if you just follow the Linux/OS X instructions at this point? Maybe the FreeBSD build-instructions just needs to be updated? And if this works, clearly we should be able to create a ports package based on that.

I really think this should be doable. Let us know how it works out. To try to keep this issue at point though (the ports thing), if you keep having build-issues, we should probably discuss that elsewhere, or maybe even create a new issue for it.

I'm on IRC (Freenode) as josteink. I can also occationally be reached on Gitter, and CoreCLR has its's own Gitter room here. Worst case scenario you can try contacting me there, although I can't make any guarantees about timeliness.

[josteink]

I've issued some small patches to make building coreclr on FreeBSD simpler, but from what I can building corefx still has issues.

These issues seems mostly related to corefx having dotnet cli as a build-dependency, and it not being built for FreeBSD (issue here),

Until that issue is solved, a FreeBSD ports package cannot be created.

[josteink]

Following this corefx issue about building managed components, it seems @jasonwilliams200OK has found a way to build corefx on FreeBSD, and @sec has found some additional dependencies which needs to be resolved.

So it seems it can be done, at least.

From what I can tell, the build process is certainly not as smooth as it should be, and all those things needs to be improved before we can have a ports package of any sort...

[josh-endries]

Thanks for continuing to look into this. I eventually got the coreclr piece to build (though lots of tests failed as it was going, but maybe that's expected), my notes are in this issue, but corefx didn't get very far:

# ./build.sh native
[ ... ]
[  6%] Linking CXX shared library System.IO.Compression.Native.so
/root/corefx/src/Native/System.Native/pal_errno.cpp:173:14: error: use of undeclared identifier 'ENODATA'
        case ENODATA:
             ^
/root/corefx/src/Native/System.Native/pal_errno.cpp:352:20: error: use of undeclared identifier 'ENODATA'
            return ENODATA;
                   ^
2 errors generated.

I gave up at this point. I didn't want to go on a hacking expedition in corefx, and the instructions currently say you need to build the managed parts on Windows, which was more work than I wanted to invest. My vacation time is rapidly disappearing. :)

I looked at the FreeBSD Porters Handbook and, allegedly, a minimal FreeBSD port is just a 10 or so line Makefile file. For local testing, you can just create a port folder for it, e.g. /usr/ports/devel/coreclr, and create Makefile with this content (keep in mind I've never done this before):

# $FreeBSD$
MAKE_ENV=PATH=/usr/local/llvm37/bin:${PATH}
PORTNAME=coreclr
PORTVERSION=1.0.0 # ?
DISTVERSIONPREFIX=v
CATEGORIES=devel # ?
BUILD_DEPENDS=bash:shells/bash cmake:devel/cmake clang37:lang/clang37 gettext:devel/gettext make:devel/gmake autoconf:devel/autoconf libtool:devel/libtool automake:devel
LIB_DEPENDS=libunwind.so:devel/libunwind libicuio.so:devel/icu # build only?
#RUN_DEPENDS=
USE_GITHUB=yes
#USES=cmake
MAKE_CMD=${WRKSRC}/build.sh
GH_ACCOUNT=dotnet
GH_PROJECT=coreclr
[email protected]

It also wants a checksum so this would go in /usr/ports/devel/coreclr/distinfo:

SHA256 (dotnet-coreclr-v1.0.0_GH0.tar.gz) = fad7bb05f78d90dfea6e8fec59f79ff12648fe95c0965cda5bc11beafabd0f27
SIZE (dotnet-coreclr-v1.0.0_GH0.tar.gz) = 34303728

This almost works. Mine started building and got to 42% before the VM disk was full, oops. Of course there are some problems/concerns:

• I installed the dependencies via pkg already, so building/installing them wasn't tested, but it correctly detects that they're installed.
• I'm not 100% sure if the distinfo checksum stuff is right for a GitHub port. I made that manually based on another port's file. I'm not sure if the auto-retrieved file name will ever change (that GH0 makes me wonder).
• The MAKE_CMD may not be the correct way to tell it to run build.sh instead of just "make", which is the default. USES=cmake almost worked. Alternatives are include a Makefile in the code, or maybe use a patch in the ports tree to invent one that just calls build.sh.
• I'm not sure if this overriding of PATH is the best or correct way to make it use clang 3.7, but I found no way to specify the path in the handbook. Changing the path in the user's shell before running make in /usr/ports/devel/coreclr does work, but I feel that should be baked into the port itself.

For posterity, the GitHub port Makefile details are documented in the porter's handbook here.

[josteink]

FYI: The ENODATA thing is a regression introduced by some recent code-changes. I've prepared a PR to fix it. Hopefully we can get this sorted out.

[ghost]

@fzzzt, I normally love to get involved in any kind of port project or build system stuff as there is always cool stuff to learn there.. FreeBSD got us quite far and the last couple of blockers are highlighted here: https://github.com/dotnet/corefx/issues/1626. Very few assemblies were left which needed work on CoreFX native side and it wasn't the build blocker as we were just getting PlatformNotSupportedException when accessing those code paths at runtime.

I am setting up a FreeBSD VM to fix the CoreFX native build.

[ghost]

Applied patches from dotnet/corefx#9899 and dotnet/corefx#9903 on a fresh clone and ran:

pkg install clang38 cmake bash krb5
corefx/build.sh native clang3.8

successfully built CoreFX native on FreeBSD 10.3.

[josteink]

OK. Right now it seems the main blockers for having a 100% native FreeBSD ports package to happen is:

• Dotnet CLI is currently not built for FreeBSD (and cannot be built for FreeBSD?) (https://github.com/dotnet/cli/issues/3815)
• CoreFX depends on Dotnet CLI to run build of managed components. There may also be other issues we'll discover once that dependency is fixed.

This definitely seems achievable, but right now the FreeBSD porting team seems a bit absent. Maybe we should make some calls once people are back from their summer vacations? :)

[ghost]

@josteink, the current approach is described in this thread: https://github.com/dotnet/coreclr/issues/917#issuecomment-229637510. This is not straight-forward to build stage0 dotnet (aka muxer) on any OS (Unix-y or even otherwise), but it is possible.

I will spend some time and make it build for Alpine Linux (aports packaging system). If I get succeeded, I will try to do the same for FreeBSD ports and pkgsrc, or at least make notes on howtos/gotchas for inference.

[josteink]

@sec: you seem to be working on general FreeBSD issues. Any chance you could help out documenting what's needed to get things running. It would probably be helpful towards the eventual goal of having a ports package.

[josteink]

Other recently fixed FreeBSD issues across repos:

• https://github.com/dotnet/core-setup/pull/213
• https://github.com/dotnet/cli/pull/3812

[ghost]

Thanks @josteink! It would be really great to have dotnet/core-setup and dotnet/cli running on FreeBSD and NetBSD! :star:

/cc @krytarowski

[josteink]

This one is also in need of fixing for FreeBSD, although it seems NetBSD support is already landed: https://github.com/dotnet/coreclr/issues/6184

[krytarowski]

The NetBSD team has released CoreCLR-1.0.0 in pkgsrc-2016Q2

http://mail-index.netbsd.org/tech-pkg/2016/07/12/msg017108.html

Feel free to use it on FreeBSD too.

[sec]

@josteink I tried to build it on FreeBSD basen on story from dotnet/runtime#4210 - I didn't get past 'dotnet restore' stage yet (errors about DLL in wrong format from ubuntu sdk, I guess I have to compile them myself to be cross-platform) - coreclr/corefx shoud compile now without aby problems, only mscorlib must be compiled under diffrent os for fbsd.

Anyway, HelloWorld is working - I'm trying to run ASP.NET Core application under fbsd, if I get SDK working, there's still one blocker - https://github.com/dotnet/corefx/issues/2046

[brunolauze]

@fzzzt I was tired of waiting for this kind of thing to happen, i made a tentative to write ports at https://github.com/brunolauze/freebsd-dotnet-ports and use a copy of latest roslyn.linux.8 .dlls minus mscorlib.dll which is fbsd. still would like to make mscorlib built on fbsd directly. but at least i have Kestrel running with those ports. glad if it can help out...

[josteink]

@brunolauze I'm not sure if you are aware if this, but there's a related issue (with an assigned milestone!) getting FreeBSD building and Dotnet CLI for FreeBSD published.

It also contains some hints, tips and leads, not to mention references to a new, not yet official bootstrap repo:

https://github.com/dotnet/corefx/issues/10610

Maybe that can help out getting a proper ports definition created? If not now, maybe later if (when?) we get a real CLI published by Microsoft?

Either way, I must just say that it's some great work you've put in so far. Pretty thorough for a first go!

I certainly hope we can find some way to land it and make it official in the end :)

[josteink]

@brunolauze I also see that you have patched some of the source files in your ports definition. If there are more FreeBSD specific changes which needs to be done in coreclr and corefx, I really recommend issuing those as PRs upstream (with the proper #ifdef's), rather than maintaining your own patches.

It's a quick process, and you tend to get response reasonably quickly. Most importantly, it alleviates you and/or FreeBSD from needless future maintenance of these patches to keep the port working.

If you decide to do so, and I really think that's the way forward, feel free to cc me for code-review.

[brunolauze]

@josteink I will review the patches to see if any would really fit a PR but if you look closely at the patches there are only "patching" what the regular build tools would do like the SR.cs and AssemblyInfo.cs mainly. Other patches are really hiccup occurring in Mono stable which supports inline nullable "?" really badly, in the stable version at least. Another issue with mono is the inside if condition out variable assignation which is a mono bug. I would consider those patches of no interest. So i didn't encounter any "real" issue building anything except with roslyn but it's only because I'm tracking master across the board...
Another goal of the ports are to test things out changing branch/repo easily and have at any level which appears hard within the normal build process.

[josteink]

To be honest, I was mostly referring to the changes to the CPP files in coreclr.

Patching the managed build tools to get the build working while we lack and official CLI/SDK build is fair game IMO.

[brunolauze]

@josteink those will be removed as it was only to debug as they are useless sorry for the mess... should have been there in the first place...

[josteink]

No problem, sir. Just trying to facilitate such that as many FreeBSD-specific things as possible get included upstream, as separate patches usually means things will fall behind and stop working eventually.

And that's no good ;)

[DragonSA]

Hi, to introduce myself: I am a FreeBSD Ports committer (handle: dbn) and a member for the FreeBSD/Mono team. I have been working on a port (aka package) of dotnet however I have encountered an problem that I have not been able to resolve or overcome. Please see dotnet/coreclr#8316 for details.

Some more details on my efforts:

1. I decided to take a different approach than @brunolauze. I'm trying to stick as close as possible to the upstream build approach.
2. FreeBSD 11.0 does support running CentOS 7-amd64 and can thus run the centos SDK, however dotnet restore gets stuck with 100% CPU usage at some point.
3. My efforts are at DragonSA/dotnet

[nkosi23]

Has any progress been done with this ? Is there a FreeBSD port available ?

[DragonSA]

No, unfortunately little progress has been made. It has proven very difficult to bootstrap the build process (even with building msbuild for mono).

[karelz]

We are resurrecting the FreeBSD port effort in https://github.com/dotnet/corefx/issues/1626.

Closing this issue as duplicate of https://github.com/dotnet/corefx/issues/1626 (the main driving issue).