Link against libc++abi and libunwind as well when building LLVM wrappers on AIX

[bzEq]

Unlike libc++.so on Linux which is a linker script

INPUT(libc++.so.1 -lc++abi -lunwind)

AIX linker doesn't support such script, so c++abi and unwind have to be specified explicitly.

[rustbot]

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[cuviper]

Is unwind always needed in AIX? I'm curious because Fedora's libc++.so is just INPUT(libc++.so.1 -lc++abi). You might already get -lunwind from std too, but I can see you only added it here in your second "fix" commit.

[bzEq]

Is unwind always needed in AIX?

Not really, it's not like libc. Normal C programs don't depend on libunwind.

int main() { return 0; }
ldd a.out
a.out needs:
         /usr/lib/libc.a(shr_64.o)
         /unix
         /usr/lib/libcrypt.a(shr_64.o)

Here, libunwind is the dependency of libc++.

libc++.so.1 needs:
         /usr/lib/libpthread.a(shr_xpg5_64.o)
         /usr/lib/libc.a(shr_64.o)
         /usr/lib/libc++abi.a(libc++abi.so.1)
         /usr/lib/libunwind.a(libunwind.so.1)
         /unix
         /usr/lib/libcrypt.a(shr_64.o)

Fedora's libc++.so is just INPUT(libc++.so.1 -lc++abi)

Fedora's build should have set -DLIBCXXABI_USE_LLVM_UNWINDER=FALSE when building these runtimes, so its libc++abi should be depending on libgcc_s.

You might already get -lunwind from std too, but I can see you only added it here in your second "fix" commit.

Exactly. I was hesitating to add libunwind here. Adding libc++ and libc++abi here already works. From a local view, libc++ depends on libc++abi and libunwind, so I add both here; from a global view, we are building something that definitely depends on std, so no need to duplicate libunwind here.

[cuviper]

OK, sounds fine to just include it.

@bors r+ rollup

[bors]

📌 Commit 00f7f57 has been approved by cuviper

It is now in the queue for this repository.