Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

cc @uweigand in case you've seen this or have an idea here.

The .exports files get generated via a script:

And then added to the linker options:

Hi @elinor-fung , I just tried to reproduce the issue (at current release/8.0 commit 98d641585d21c6b7a89f4aa39c6d9f8a3586f5f3), and it seems to work fine for me. The hostpolicy.exports file generated during this build looks like this:

V1.0 {
    global:
        corehost_initialize;
        corehost_load;
        corehost_main;
        corehost_main_with_output_buffer;
        corehost_resolve_component_dependencies;
        corehost_set_error_writer;
        corehost_unload;
    local: *;
};

which does look fine to me.

I'm wondering: can you get the copy of that file from the failed build? This failure happened during the cross-compile on x86, so these should be all Microsoft machines. Would be interesting to see whether the problem is that the file was incorrectly generated somehow, or else the problem is that the cross-linker installed on those machines somehow does not accept a valid file.

Thanks for taking a look.

Would be interesting to see whether the problem is that the file was incorrectly generated somehow, or else the problem is that the cross-linker installed on those machines somehow does not accept a valid file.

@akoeplinger indicated that this may be related to an update to the images being used #112381 (comment)

can you get the copy of that file from the failed build?

@akoeplinger / @carlossanlop Do you know if we have those intermediates stored somewhere or would we need to make the pipelines upload them? I didn't see anything in the artifacts. Or, what would be the best way to try to repro this, since it seems specific to how the CI builds are set up?

@elinor-fung @uweigand the hostpolicy.exports file looks identical to the one you posted.

The easiest way to reproduce the failure locally is via docker:

$ docker run -it mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-net8.0-cross-s390x bash

git clone --branch release/8.0 --depth 1 https://github.com/dotnet/runtime runtime-repo
cd runtime-repo
export ROOTFS_DIR=/crossrootfs/s390x
./build.sh -arch s390x -os linux -cross -s host

ah, just found that we already solved this: #94355 😄

ok that fixed it:

Build succeeded.
    0 Warning(s)
    0 Error(s)

will backport the arcade fix

Excellent, thanks! I notice that this refers to the problem that LLD is not available for s390x - that is actually no longer the case. As of LLVM 18, we do have LLD support now as well. So whenever you've upgraded your build environment to at least that release, any special-casing of LLD s390x support should no longer be necessary.

Yep I think we already have that handled in https://github.com/dotnet/arcade/blob/ecdb2f499cb5f5c99b58fba1a14fdf977c56e1ac/eng/common/native/init-compiler.sh#L136-L140

I'll close this issue now that the fix is in arcade, it'll flow to runtime with #112504