http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49992
--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> 2011-08-09 17:41:25 UTC --- (In reply to comment #27) > So, the fix is trivial but you guys are wondering in the weeds. Make the > symbols unique and be done with it, that, or remove one of them. You are > getting hung up on darwin -c stuff, ignore that, that's not the bug, even if > bugs do exist in that area. well, the fix @comment 6 does that - but, in this instance, it's not a complete solution. basically, on darwin >= 10 the presence of the ___gnu_lto_v1 causes the first item in a library to be loaded - this does not occur on darwin 9 (regardless of whether ___gnu_lto_v1 is listed in the archive toc). so, it's a "regression" or at least an alteration in the behavior of ld. whilst we have wandered around a bit - that was because there are two issues: 1. duplicate implementations of the diagnostics (comment 6 should fix) 2. random issues caused by archive members being loaded when ___gnu_lto_v1 is present in the toc. my question is about whether there is a reason to include ___gnu_lto_v1 in the toc on Darwin (i.e. why was the -c added - the ChangeLog doesn't identify a PR or reason other than to make it like other ranlibs).