[PATCH] D106703: [libunwind] adds a way to synthesise libgcc

[Christopher Di Bella via Phabricator via llvm-commits]

cjdb added a comment.

In D106703#2901851 <https://reviews.llvm.org/D106703#2901851>, @efriedma wrote:

> In D106703#2901842 <https://reviews.llvm.org/D106703#2901842>, @efriedma wrote:
>
>> Oh, wait, I am missing something: you're installing a symlink, and dlopen determines whether a shared library is the same based on inode, not the path.  So I guess this works out in its current form.
>
> Err, no, that's not right; the CMake steps in the patch create a symlink in the build directory, then install() copies the whole library to the install directory, so it isn't symlinked anymore.

My Chrome OS build shows this.

  $ ls -l /usr/lib64/libgcc_s*
  lrwxrwxrwx. 1 root root 12 Jul 21 23:31 /usr/lib64/libgcc_s.so -> libunwind.so
  lrwxrwxrwx. 1 root root 14 Jul 21 23:31 /usr/lib64/libgcc_s.so.1 -> libunwind.so.1

Those look like symlinks to me?

> In D106703#2901831 <https://reviews.llvm.org/D106703#2901831>, @cjdb wrote:
>
>> Having said that, processes needn't explicitly link with libunwind when their system vends using this setup because libgcc_s.so is libunwind.so, and so even if my understanding about how shared objects are loaded is wrong, the problem should be avoided nonetheless.
>
> If nothing actually links to the library named libunwind.so, why install a library with that name?

Two reasons:

1. It could possibly break projects that do opt into using libunwind and the library isn't present.
2. It'd be weird for libunwind to install libgcc* on its lonesome.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106703/new/

https://reviews.llvm.org/D106703