Make non-portable builds use system libunwind

[omajid]

Now that we have an optional way to use the system version of libunwind (#17164) we want to use it (by default) when we want to do non-portable builds - builds that are tied against the specific target system.

Portable builds will still use the bundled version of libunwind.

Does it make sense to tie the PortableBuild flag to system-libunwind? Are there any cases where we want to use the bundled copy of libunwind but have non-portable builds? If that's the case this patch is probably not a good idea and I will try and come up with an alternative.

cc @janvorli @jkotas @Petermarcu @tmds @danmosemsft

[omajid]

Ping. Anyone?

[janvorli]

I don't think that using the portable build option to determine this is what we want. For example, the RHEL.6 is a non-portable build and yet we don't build packages for the target OS and we just distribute a tarball. And we want to have the libunwind compiled in to reduce the number of dependencies the users have to install.
So I'd prefer keeping these two things separate.

[omajid]

Thanks. I am going to close this pull request.

Is there a separate term for what I want to do: use system libraries as much as possible?

[janvorli]

Is there a separate term for what I want to do: use system libraries as much as possible?

I was thinking if I can come up with some short term, but I have failed.

[ghost]

@janvorli, at run time, if the target system is the officially supported distro (e.g. CentOS) that has libunwind installed (distro provided and carefully configured for the system), would CoreCLR use that one even when the package has libunwind available? It would be nice if the native module loader prefers system-wide installation of libunwind first and fall back to the bundled .so in case of libunwind absence.

[danmoseley]

@kasper3 one concern woukd be supportability...it increases the possible configurations one might have to diagnose.

[ghost]

Right, depending on libunwind API, theoretically we can query that information after dlopen: if it has some threshold value > X and ... , then use(this), else use(bundled).

[janvorli]

@kasper3 I would prefer not doing this. Using the built in libunwind also has the benefit of us being able to fully test it. With using the platform one, we would loose this. Why would you see using the external installed libunwind as beneficial?

[omajid]

Why would you see using the external installed libunwind as beneficial?

Maybe .NET Core is a bit special because you are not diverging from upstream libunwind and keep up with changes there, but a lot of projects run into various issues when they bundle libraries. As a point of system design, Linux distributions try and avoid using bundled libraries:

• https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries
• https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies