This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [cmake] Use -print-libgcc-file-name option to find compiler runtime
Needs RevisionPublic

Authored by mgorny on Oct 13 2016, 10:05 AM.

Details

Reviewers
EricWF
Summary

Use the -print-libgcc-file-name compiler option to obtain the path to
libgcc or an equivalent compiler runtime library, rather than hardcoding
-lgcc_s. This aims to make it possible to avoid linking with -lgcc_s
when -rtlib=compiler-rt is used along with libunwind.

If -print-libgcc-file-name call fails, -lgcc_s is used as a fallback.
Furthermore, -lgcc_s is still linked in for unwinding if
LIBCXXABI_USE_LLVM_UNWINDER is not set.

Diff Detail

Event Timeline

mgorny updated this revision to Diff 74535.Oct 13 2016, 10:05 AM
mgorny retitled this revision from to [libcxx] [cmake] Use -print-libgcc-file-name option to find compiler runtime.
mgorny updated this object.
mgorny added a reviewer: EricWF.
mgorny added a subscriber: cfe-commits.
mgorny updated this revision to Diff 74536.Oct 13 2016, 10:09 AM
mgorny updated this revision to Diff 74538.
mgorny updated this object.

Fixed indentation.

EricWF requested changes to this revision.Oct 14 2016, 4:06 AM
EricWF edited edge metadata.

This doesn't seem right seeing as print-libgcc_file-name prints the libgcc.a path, and we were previously linking libgcc_s.

This revision now requires changes to proceed.Oct 14 2016, 4:06 AM

This doesn't seem right seeing as print-libgcc_file-name prints the libgcc.a path, and we were previously linking libgcc_s.

Do you have any other solution in mind? There is no switch to print the shared library path. Should I modify it to detect whether the printed path matches libgcc.a and use libgcc_s in that case?

Just to be clear, since libgcc_s is the shared version of libgcc (+ libgcc_eh), this is mostly a matter of replacing dynamic linking with static. However, it doesn't matter much since in most of the cases no library function is actually used. From my experience, throughout 3.8.1 .. HEAD, no builtin functions were needed on amd64 and only one (__udiv3, if I recall correctly) was needed on 32-bit x86. In this case, I dare say using the static library may actually be less problematic as it makes libc++ less dependent on compiler runtime.

Of course, on the other hand we have the unwinder library which still can be gcc_s and there is no easy way to solve this dependency.