Building from source

[acesnik]

Hi there,

I'm running into issues with the __glibc >= 2.17 requirement (https://github.com/conda-forge/dotnet-feedstock/blob/master/recipe/meta.yaml#L56) when using dotnet for other builds. You got it to work within conda-forge, so I'm wondering if you have any feedback on how to get it working elsewhere. Specifically, it is a dependency of software I help develop named metamorpheus, and we're running into issues trying to get it to build for linux environments: bioconda/bioconda-recipes#27130.

Thanks!

[dhirschfeld]

This is just a binary repackage of the pre-built Microsoft dotnet binaries. As such it requires the more recent glib version so won't be compatible with metamorpheus which seems to require an older glib:
bioconda/bioconda-recipes#27130 (comment)

It seems you're only option might be to compile dotnet yourself against the older glib, but I'm not sure if that is even possible - it might be, I just haven't looked into it.

[acesnik]

Okay, thanks for sharing your thoughts on this!

[bernt-matthias]

Could https://anaconda.org/conda-forge/glib help?

[acesnik]

I tried using the glib package to no avail. I ended up making a request to conda-forge instead of bioconda for various reasons, and that's in the works! conda-forge/staged-recipes#14252

[acesnik]

I changed the question here. Is there any interest in switching this package over to building from source, rather than repackaging the binaries built against CentOS 7? I believe that would allow other channels, such as bioconda, to use dotnet as a dependency, as long as dotnet can in fact be built against CentOS 6. Would it be worth the effort?

[dhirschfeld]

Absolutely. I just haven't had time myself to look into that and realistically won't for a long time. Would be happy to review/merge a PR though!

[mbargull]

FYI, as of late we now use CentOS 7-based build containers over at Bioconda, i.e., conda-forge::dotnet can be used as a dependency in recipes.
I expect conda-forge and Bioconda to move the minimum system requirements to CentOS 7 some time later this year (we held off on that because of the CentOS 8 Linux -> CentOS 8 Stream change and wanted to give people some time to figure out how they proceed with their updates, be it Stream, RHEL, Rocky, Alma, Oracle, or non-RHEL-based).
But building from source would be appreciated in any case, even if CentOS 6 -> 7 might not be the main driver anymore ;).

[ppenguin]

Was a solution for a custom dotnet build found? I'm targetting old glibc systems and find that even bootstrapping dotnet in a container (arm-glibc-2.17) fails with:

root@a808750a2788:/build/source-build# .dotnet/dotnet 
.dotnet/dotnet: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by .dotnet/dotnet)
.dotnet/dotnet: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by .dotnet/dotnet)

The corresponding (max) libstdc++ is:

root@a808750a2788:/build/source-build# strings /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep GLIBCXX
...
GLIBCXX_3.4.19

So it seems I'm stuck, because even if I would update libstdc++ in the container to build it, this dependency would remain for the resulting runtime?

[acesnik]

I've tried building from source (https://github.com/dotnet/source-build) for .NET 5 and 6, but it's still not straightforward, and I haven't made it through the build successfully, despite it seeming like the source build has improved in ease of use.

The older glibc issues have plagued me before, so I understand the frustration!

[acesnik]

I've tried building from source (https://github.com/dotnet/source-build) for .NET 5 and 6, but it's still not straightforward, and I haven't made it through the build successfully, despite it seeming like the source build has improved in ease of use.

The older glibc issues have plagued me before, so I understand the frustration!

[dhirschfeld]

I'm hitting an ICU error over in dotnet-interactive:

Couldn't find a valid ICU package installed on the system. Please install libicu using your package manager and try again.

Since icu is installed as a run dep I think it's an issue with not being compatible with the version used to build the .NET SDK which should be resolved by building from source.

[acesnik]

This issue with bumping versions might also be fixed with building from source: #55

[acesnik]

Some success

I did finally get this to work on an Ubuntu docker container, which required a few more dependencies than the build noted on the dotnet/installer repository.

Some thoughts

• I'm not sure how this translates to macOS or Windows builds
• It uses dotnet within the build with the --online flag to pull some packages from NuGet and do some MSBuild stuff, which seems a bit circular but probably fine...
• The resulting tarball does look familiar, basically what's downloaded from their download site for linux

Commands for building from source in an ubuntu docker container

apt update
apt upgrade
apt install -y cmake llvm lld clang build-essential python-is-python3 curl git lldb libicu-dev liblttng-ust-dev libssl-dev libnuma-dev libkrb5-dev zlib1g-dev ninja-build liblttng-ust-dev git wget curl vim locales-all libz-dev libssl-dev
git clone https://github.com/dotnet/installer.git
cd installer/
mkdir -p /home/dotnet/source
./build.sh /p:ArcadeBuildTarball=true /p:TarballDir=/home/dotnet/source
cd /home/dotnet/source/
./prep.sh 
./build.sh --clean-while-building --online

Output from build

dotnetbuild-report.txt

Screenshot of the installer using dotnet to build dotnet