Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build an apphost with hostfxr and hostpolicy linked in #35368

Merged
23 commits merged into from
May 6, 2020

Conversation

VSadov
Copy link
Member

@VSadov VSadov commented Apr 23, 2020

This is a continuation of #35087

======

This PR introduces a few changes:

  • It builds most of hostfxr as a static library, with the shared library being linked with this static library and some shared-specific code
  • It builds hostpolicy as a static library
  • It abstracts how the host looks for hostfxr functions, either by loading a DLL and finding symbols there, or referencing symbols from the executable directly
  • Provides a minimal hostpolicy_resolver that merely references some needed hostpolicy functions

One of the concerns with this was about the size of the executable. This table summarizes it:

Executable name Size in bytes
apphost-linux-x64 181472
static_apphost-linux-x64 570312

@ghost
Copy link

ghost commented Apr 23, 2020

Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar
Notify danmosemsft if you want to be subscribed.

Copy link
Contributor

@swaroop-sridhar swaroop-sridhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I second @vitek-karas's comment on here on #35087 that it is best to leave the implementation and header files in their existing directories, and only create separate CMakeLists files

@VSadov
Copy link
Member Author

VSadov commented Apr 24, 2020

@swaroop-sridhar - I will look at the file moves.
A few files must be in static/shared to avoid conflicts (CMakeLists.txt, hostpolicy_resolver.cpp, ..), but most could be used from ../

@davidfowl
Copy link
Member

@jkotalik on how this may affect IIS

@VSadov
Copy link
Member Author

VSadov commented Apr 24, 2020

Scanning dependencies of target hostfxr_exports
  make[2]: *** No rule to make target `/Users/runner/runners/2.166.3/work/1/s/src/installer/corehost/generateexportedsymbols.awk', needed by `cli/fxr/shared/hostfxr.exports'.  Stop.

@janvorli - any idea what is missing for this to work? Why is it looking in corehost?

@jkotalik
Copy link
Contributor

Yeah, I'm a bit confused on how this will interact with IIS as well.

In our IIS interop, we rely on calling into hostfxr via pinvoking to call host_fxr_main. By statically linking hostfxr as a lib, will the hostfxr dll now not be present?

@janvorli
Copy link
Member

@janvorli - any idea what is missing for this to work? Why is it looking in corehost?

Let me take a peek.

@janvorli
Copy link
Member

Ah, I see. The move of the functions.cmake to eng/native that happened some time ago should have moved the awk script there too. The generate_exports_file function now looks for the script at ${CMAKE_SOURCE_DIR}/${AWK_SCRIPT}. So for coreclr, it is in src/coreclr as the root CMakeLists.txt is there. For corehost, the ${CMAKE_SOURCE_DIR} is src/installer/corehost.

Can you please move the awk script to eng/native and modify the path to the script in functions.cmake by removing the ${CMAKE_SOURCE_DIR}/ ?

@vitek-karas
Copy link
Member

@jkotalik @davidfowl Just to clarify - currently IIS hosting doesn't support single-file apps (even those in 3.1). Single-file in 5.0 is different from 3.1, but in terms of hosting support it's actually very similar - we still don't support hosting it via native host (IIS being one such native host). If this is something we think we should have, than we need to figure out what it means.

@VSadov VSadov force-pushed the staticHost branch 2 times, most recently from 3676d5c to e88b262 Compare April 24, 2020 21:12
Copy link
Contributor

@swaroop-sridhar swaroop-sridhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall the change looks good.
Can you please make sure that existing apphost, liobhost, comhost, are not affected and build exactly the same (when compared to building without these changes)? Thanks.

#include "pal.h"
#include "error_codes.h"

class hostfxr
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The class name must match the file name. So, the class should be called hostfxr_iface_t.
However, in keeping with the hostpolicy_resolver naming, this class (and file) should probably be called hostfxr_resolver_t.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot about this. Why the "_t" part?
Could the type and file be both just hostfxr_resolver ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Every type in the host ends with _t. While I don't particularly like it, we should follow the convention.

# The .NET Foundation licenses this file to you under the MIT license.
# See the LICENSE file in the project root for more information.

project(static_apphost)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@richlander @samsp-msft
Wanted to ask again if we want a better name for the static host, instead of static_apphost.exe?

We build two types of hosts:

  • Apphost linked with other host components code-named "static apphost" (this PR) -- this will ship in the Microsoft.netcoreapp.host package for Windows (and Mac).
  • Apphost linked with host and runtime components code-named "super apphost" (TBD) -- this will ship in the Microsoft.netcoreapp.host package for Linux.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@VSadov please see @jkotas comments here: #32823 (comment).
This static_apphost should be renamed to netcoreapphost or singlefilehost

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file is a template to be linked with app parts and renamed, so naming is not extremely important IMO.
singleapphost feels a bit better as it hints at the purpose of the file.
I assume the standalone apphost will not be used (or will not be recommended) for single-file scenarios once this is shipped.

I will change to singleapphost.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The feature is called SingleFile (e.g. -p:PublishSingleFile=true) so the name should be singlefile* for consistency.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

singlefilehost ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I meant singlefilehost in the first place.

singleapphost was a mistype.

@@ -0,0 +1,45 @@
# Licensed to the .NET Foundation under one or more agreements.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the upcoming change: #1154 (comment)
We could consider not building hostfxr_shared.lib etc, but simply building static_apphost.exe directly.
Again: This is just for consideration ... may simplify the build logic, not sure it is a good idea.

Copy link
Contributor

@swaroop-sridhar swaroop-sridhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The static_apphost should be published in Microsoft.NETCore.App.Host package, along with
apphost, comhost, ijwhost, nethost.

This is part of the work to create an apphost that bundles both hostfxr
and hostpolicy.  The main distinction between the static and shared
versions of hostfxr is that the static version contains a hostpolicy
resolver that references the hostpolicy symbols directly rather than
loading them from a DLL.
This change is part of the work to enable an apphost that bundles both
hostfxr and hostpolicy.  There's no distinction between hostpolicy
that's built as a shared library and as a static library: the shared
library is built by linking an empty object file with the static
library.
Provide a hostfxr_iface class, that abstracts how the hostfxr functions called
by the early stage in the hosting layer is resolved.
This provides two implementations of hostfxr_iface: one for the static
apphost, which bundles hostfxr and hostpolicy, and another for the
conventional apphost, which loads them dynamically on startup.
Copy link
Contributor

@swaroop-sridhar swaroop-sridhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@swaroop-sridhar swaroop-sridhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The static_apphost needs to be packaged into microsoft.netcore.app.* but I think this change can be done in a separate PR.

if (CLR_CMAKE_TARGET_WIN32 AND (CLR_CMAKE_TARGET_ARCH_ARM OR CLR_CMAKE_TARGET_ARCH_ARM64))
target_link_libraries(apphost Advapi32.lib shell32.lib)
endif()
add_subdirectory(static)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure "static" and "shared" are the best names here.
I think Leandro chose these because of static and shared libraries.
But "shared" is a bit confusing because (a) it seems to represent code shared between different kinds of builds, and (b) apphost is not a shared library.
Please consider renaming them to more representative names.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not like 'shared', but did not have a lot of good alternatives. It is an opposite of "static" and "super" - could it be "standalone"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I think "standalone" is a good option. "linked vs standalone" or "static vs standalone" are good I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will make it static vs. standalone. (static seems good enough)

Copy link
Contributor

@swaroop-sridhar swaroop-sridhar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looks good to me, except for a few issues noted above.
Thanks.

@VSadov
Copy link
Member Author

VSadov commented May 5, 2020

I think I have added the publishing steps in 433db23

Are there other packages it needs to be included in?

@swaroop-sridhar
Copy link
Contributor

I think I have added the publishing steps in 433db23

Are there other packages it needs to be included in?

Thanks I overlooked that change.

@swaroop-sridhar
Copy link
Contributor

@wli3 @dsplaisted FYI

This change introduces the "superhost" as discussed in #32823.
This host will be a part of the Microsoft.NETCore.app.Host.* packages, and should be consumed by the SDK when publishing for single-file self-contained scenario.
Currently it statically links the apphost with hostpolicy and hostfxr, but subsequently the runtime will be linked with the host (for Linux).

@swaroop-sridhar
Copy link
Contributor

/azp runtime

@azure-pipelines
Copy link

Command 'runtime' is not supported by Azure Pipelines.

Supported commands
  • help:
    • Get descriptions, examples and documentation about supported commands
    • Example: help "command_name"
  • list:
    • List all pipelines for this repository using a comment.
    • Example: "list"
  • run:
    • Run all pipelines or specific pipelines for this repository using a comment. Use this command by itself to trigger all related pipelines, or specify specific pipelines to run.
    • Example: "run" or "run pipeline_name, pipeline_name, pipeline_name"
  • where:
    • Report back the Azure DevOps orgs that are related to this repository and org
    • Example: "where"

See additional documentation.

@swaroop-sridhar
Copy link
Contributor

/azp run runtime

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ghost
Copy link

ghost commented May 5, 2020

Hello @VSadov!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit f6e5219 into dotnet:master May 6, 2020
@safern
Copy link
Member

safern commented May 6, 2020

@swaroop-sridhar @VSadov maybe this is the reason for the test failures on rolling builds on CI for the installer linux_musl_x64 leg?

https://dev.azure.com/dnceng/public/_build/results?buildId=632734&view=results

@VSadov
Copy link
Member Author

VSadov commented May 6, 2020

what could be special abut linux_musl_x64 ?

@safern
Copy link
Member

safern commented May 6, 2020

I don't know but also note that the PR leg is Debug and rolling build is Release... There was another break similar to this in the installer tests also only in linux_musl_x64 which is alpine.

#35755

Maybe we should add a Release leg to PRs as well as it seems like these scenarios behave differently in Debug and Release.

safern added a commit to safern/runtime that referenced this pull request May 8, 2020
safern added a commit that referenced this pull request May 8, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 9, 2020
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants