Repository navigation
Build Generic linux-x64 rpm and deb packages #3961
Description
Background: See #3721 (comment)
tl;dr: This should build the assemblies in a way that they are portable to all the supported Linux x64 platforms for .NET, but requires that we package native binaries which dotnet publish will publish.
- Update build so it can build and publish for the runtime
linux-x64 - Update packaging script to package native binaries published and remove unneeded dependencies
- Work with Microsoft Repo owners to develop a package publishing story. Raghu Shantha (@raghushantha) and Travis Plunk (@TravisEz13) can get you started here.
- Update documentation
- Create
.tar.gzpackage for Linux - Add documentation about Linux package dependencies
- Update docker files
- Update from
2.0.0-preview1-002106-00to2.0.0-preview2-25303-04that includes Fix SSL on Debian 9 dotnet/corefx#19070 to support Ubuntu 17 and Debian 9 (update: powershell has moved to official .NET Core 2.0 release)
Activity
janvorli commentedon Jun 7, 2017
Travis Plunk (@TravisEz13) I've located the very first version that supports Ubuntu 17 and Debian 9. It is
2.0.0-preview2-25303-04.borgdylan commentedon Jun 22, 2017
Has .NET Core 2.0 fixed
SystemNative_SysConf?TravisEz13 commentedon Jun 23, 2017
Dylan Borg (@borgdylan) I see you just filed this issue, https://github.com/dotnet/corefx/issues/21386, about the same time you made this comment. It would be more appropriate to ask on that issue if it has been fixed. If you find something out from the .Net Core team that changes our decision to use portable Linux build, that would be a good time to cross-post back to PowerShell, with a link to the issue. Thanks
borgdylan commentedon Jun 24, 2017
Please keep tracking https://github.com/dotnet/corefx/issues/21386 . Using 2.0 will keep powershell broken for now until corefx gets fixed. A workaround would be to not use Environment.ProcessorCount et al in the Linux build until this gets fixed.
borgdylan commentedon Jun 28, 2017
The issues arose from a stale copy of System.Native installed system wide. After removing it, powershell starts normally. (tested against beta3)
iSazonov commentedon Jun 28, 2017
Dylan Borg (@borgdylan) Can you repo this? If so please open new Issue for discussion and maybe fix if system-wide assemblies overlap local ones..
borgdylan commentedon Jun 28, 2017
The non starting issues are solved for power shell
daxian-dbw commentedon Sep 20, 2017
Travis Plunk (@TravisEz13) I built powershell using
Linux-x64RID andUbuntu.16.04-x64respectively, and then compared the generated files in\publishfolder. It turned out the files are exactly the same. So it looks like there are no additional native binaries published by usinglinux-x64when building on Ubuntu.16.04.Do you happen to know any docs about
"many native libs will be included when you publish"when usinglinux-x64?janvorli commentedon Sep 20, 2017
.NET core starting from 2.0.0 is built in a portable way so that build for Linux-x64 RID works on most Linux distros that are based on glibc C library 2.14 or newer (so e.g. not Alpine which is based on MUSL C library). That's why the published components are equal.
iSazonov commentedon Sep 20, 2017
Jan Vorlicek (@janvorli) I guess tha same true for Windows RIDs too?
daxian-dbw commentedon Sep 20, 2017
Jan Vorlicek (@janvorli) In my case, I built PowerShell on a Ubuntu.16.04 machine with RID's
Linux-x64andUbuntu.16.04-x64respectively, and got the same number of published components. Does this mean that even when theUbuntu.16.04-x64RID is used, .NET CLI still builds it the same way as if theLinux-x64RID is in use?I was assuming that when
Linux-x64is in use, more components would be published comparing to using a more specific RID, because that seemed to be the way for being portable -- you bundle more dependencies with you so as to be less dependent on the individual distro. Is this not correct? Can you please point me to some docs/articles about how theLinux-x64RID works for building portable apps?janvorli commentedon Sep 20, 2017
chuanjiao10 .NET core now has initial support for redhat 6.x, but it is not supported by the portable build. The specific RID rhel.6-x64 needs to be used. See https://github.com/dotnet/core/blob/master/Documentation/build-and-install-rhel6-prerequisites.md for details. If you are publishing self-contained, you will need a nuget.config with an entry for our myget feed, just like: https://github.com/dotnet/core/blob/master/samples/nuget.config
janvorli commentedon Sep 20, 2017
Dongbo Wang (@daxian-dbw) Linux-x64 isn't any different from Ubuntu.16.04-x64. The change we've made to enable the portable Linux-x64 rid was that we dynamically load OpenSSL and ICU libraries at runtime and we can also handle few missing APIs in various versions of CURL, so we can handle subtle differences between the distros. We don't build any distro specific binaries, so the publish publishes the same files.
janvorli commentedon Sep 20, 2017
chuanjiao10 from 2.0
daxian-dbw commentedon Sep 20, 2017
Jan Vorlicek (@janvorli) Thank you very much for the explanation!
I built on Ubuntu.16.04 and then played with the generated artifacts on CentOS7. It looks to me that our only obstacle is the native component
libpsl-native.so(powershell owns it). We need to figure out a way to compile it in a distro-independent way (possible??) or bundle the native binaries that it depends on.janvorli commentedon Sep 20, 2017
Dongbo Wang (@daxian-dbw) if you build the libpsl-native.so on CentOS 7, then it should be as portable as the dotnet stuff (we build it on CentOS 7 to ensure that it doesn't depend on newer glibc).
daxian-dbw commentedon Sep 20, 2017
Jan Vorlicek (@janvorli) Many thanks! Yes, powershell works fine on
Ubuntu.16.04with thelibpsl-native.sobuilt fromCentOS7. Maybe the way to go is to buildlibpsl-native.soon CentOS and then publish it as a nuget package which powershell build can depend on. I will try it out.