mgorny added a comment. In https://reviews.llvm.org/D25568#570222, @EricWF wrote:
> 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. https://reviews.llvm.org/D25568 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
