Skip to content

coreclr build fails when specifying cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE #2014

Closed
Closed
coreclr build fails when specifying cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE#2014
Assignees
mikem8361
Labels
area-Diagnostics-coreclr
Milestone
5.0.0

Description

@dseefeld
dseefeld
opened on Jan 22, 2020

When trying to build coreclr using the system version of libunwind, the build fails with the following error:

$ ./build.sh cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE
...
../../dlls/mscordac/libmscordaccore.so: undefined reference to `_OOP_find_proc_info'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [src/debug/createdump/createdump] Error 1
gmake[1]: *** [src/debug/createdump/CMakeFiles/createdump.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[100%] Built target mscordbi
gmake: *** [all] Error 2
Failed to build CoreCLR component.

Activity

  1. Dotnet-GitSync-Bot
    added
    area-Infrastructure-coreclrOnly use for closed issues
    untriagedNew issue has not been triaged by the area owner
    on Jan 22, 2020

  2. hoyosjs commented on Jan 22, 2020

    @hoyosjs
    hoyosjs
    on Jan 22, 2020
    Member

    What system/OS is this?

  3. hoyosjs commented on Jan 22, 2020

    @hoyosjs
    hoyosjs
    on Jan 22, 2020
    Member

    @mikem8361 looks like this comes from our work in ARM unwinding (b61cc2f). Looks like _OOP_find_proc_info was added directly to libunwind. However this function only gets build then:

    runtime/src/coreclr/src/pal/src/CMakeLists.txt

    Line 16 in 696e72b

    add_subdirectory(libunwind)
    The easiest solution would be to hoist such logic into another statically linkable asset, but if memory serves he right we use types that are not available in the public libunwind surface area.

    @dseefeld is this for sourcebuild? What's the impact if so? Or is this more around serviceability or the ability to build like that?

  4. dseefeld commented on Jan 22, 2020

    @dseefeld
    dseefeld
    on Jan 22, 2020
    ContributorAuthor

    @hoyosjs Yes. This is for sourcebuild. The impact is that RedHat has requested that we use the local system's libunwind for portable builds. See dotnet/source-build#391 The OS that I'm using to build this is CentOS.

  5. mikem8361
    self-assigned this
    on Jan 22, 2020
  6. mikem8361
    added this to the 5.0 milestone on Jan 22, 2020
  7. mikem8361
    added
    area-Diagnostics-coreclr
    and removed
    untriagedNew issue has not been triaged by the area owner
    on Jan 22, 2020
  8. jkotas
    removed
    area-Infrastructure-coreclrOnly use for closed issues
    on Jan 23, 2020
  9. mikem8361
    added
    p1
    on Mar 24, 2020

  10. sdmaclea commented on Jun 18, 2020

    @sdmaclea
    sdmaclea
    on Jun 18, 2020
    Contributor

    libunwind/libunwind#187 is starting the process of adding _OOP_find_proc_info to libunwind, but it is unlikely to make it into system version of libunwind for a while. It would need to wait at least to the 1.6 release. (1.5 isn't released yet).

    Since this is only needed for the DAC unwind, the solution maybe to either:

    • Disable the the DAC Out of Process unwind feature.
    • Use the local libunwind source for DAC only.

  11. mikem8361 commented on Jun 18, 2020

    @mikem8361
    mikem8361
    on Jun 18, 2020 via email
    Contributor

  12. sdmaclea commented on Jun 19, 2020

    @sdmaclea
    sdmaclea
    on Jun 19, 2020
    Contributor

    I guess the third option would be to revert part of #26082 (to keep our custom oop code) when CLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE until libunwind/libunwind#187 is released and available to RHEL.

  13. omajid commented on Jun 24, 2020

    @omajid
    omajid
    on Jun 24, 2020
    Member

    cc @tmds

  14. 3 remaining items

  15. tmds commented on Jul 1, 2020

    @tmds
    tmds
    on Jul 1, 2020
    Member

    Until @sdmaclea 's libunwind PR gets merged and becomes available, the least work is to use the packed libunwind.
    We can look at backporting the PR for distros we care about.

    We should keep this issue open to get CLR_CMAKE_USE_SYSTEM_LIBUNWIND=true back in a working state.

    @omajid wdyt?

  16. tmds commented on Jul 15, 2020

    @tmds
    tmds
    on Jul 15, 2020
    Member

    @sdmaclea are you still actively pursuing libunwind/libunwind#187?

    @omajid are you ok with using the packed libunwind until the feature is available as part of system libunwind?
    We can consider backporting it once the feature is merged upstream.

  17. sdmaclea commented on Jul 15, 2020

    @sdmaclea
    sdmaclea
    on Jul 15, 2020
    Contributor

    I have been working on other issues. I can probably look at libunwind/libunwind#187 later this week.

  18. sdmaclea commented on Jul 15, 2020

    @sdmaclea
    sdmaclea
    on Jul 15, 2020
    Contributor

    #39213 restored some of the code which was removed in #26082. It makes it simpler to fix this issue more directly. @mikem8361 has been considering an approach like this...

  19. mikem8361 commented on Jul 15, 2020

    @mikem8361
    mikem8361
    on Jul 15, 2020
    Contributor

    Now that PR #39213 is in I was planning to add the rest of the necessary code and build stuff in the next month. It missed today's preview8 snap but it be done in the next week or two.

  20. mikem8361 commented on Jul 15, 2020

    @mikem8361
    mikem8361
    on Jul 15, 2020
    Contributor

    I have this coded up and I'm testing.

  21. omajid commented on Jul 15, 2020

    @omajid
    omajid
    on Jul 15, 2020
    Member

    @omajid are you ok with using the packed libunwind until the feature is available as part of system libunwind? We can consider backporting it once the feature is merged upstream.

    Yes, we can use the bundled libunwind until the features are available upstream.

  22. mikem8361
    added 2 commits that reference this issue on Jul 15, 2020

    Fix source build (CLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE)

    41b5dfa

    Fix source build (CLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE) (#39391)

    bf2e135
  23. mikem8361
    closed this as completedon Jul 16, 2020
  24. mikem8361
    added 2 commits that reference this issue on Jul 16, 2020

    Fix source build (CLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE)

    2f18848

    Fix source build (CLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE) (#39417)

    5d0fbba
  25. ghost locked as resolved and limited conversation to collaborators on Dec 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area-Diagnostics-coreclr

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions