mgorny added a comment.

In, @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.

cfe-commits mailing list

Reply via email to