clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)
Konstantin Belousov
kostikbel at gmail.com
Tue Nov 19 07:39:13 UTC 2013
On Mon, Nov 18, 2013 at 11:54:00PM +0100, Matthias Andree wrote:
> Glib shares the fate, because it defers to std:: containers where possible.
>
> A nice way would require additional work and get the linkers to complain
> that symbols resolve with a different, incompatible ABI. That would,
> however, require second-guessing other ABIs and namespaces, and would
> hardly be portable -- or add ABI versions into the object files and .a
> and .so libraries, unless we already have ABI tags somewhere down deep
> in the ELF stuff. I never checked.
The ABI there is an ABI of library, so linkers has nothing to do with
such conflict resolution.
Linker indeed could be tricked into stopping the linking if libstdc++
is linked into libc++-using binary. This can be hacked together with
linker script for libc++ and use of ASSERT() and DEFINED() functions.
But the right solution for the port troubles is to just switch to
consistently use (newest) gcc for ports. I assume that Uses/compiler.mk
finally allows to do this from the make.conf ? Anybody could share a
working incantation to put there ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20131119/3403c120/attachment.sig>
More information about the freebsd-toolchain
mailing list