https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358
--- Comment #11 from Nenad Vukicevic <nenad at intrepid dot com> ---
On 11/24/2015 3:27 PM, iains at gcc dot gnu.org wrote:
> OK so it appears that we do have two issues;
>
> 1. that we're (incorrectly) calling dsymutil for "link only" cases where
> there's no LTO involved (and that seems to be a typo in the argument to
> post_ld_pass() on line 820). We located the PR that gave rise to the change
> (61352) and will just double-check that we do not regress that with the
> change.
> Could you make the change locally and see if it makes the problem "go away"?
> (I note that it doesn't in any way fix #2).
I already tried this approach and the problem "goes away" as we simple
do not execute dsymutil. But, the executable still contains symbols that
will cause the warnings. I think that this will match what clang is
doing as the linker spec for darwin adds 'idsym' and 'dsym' depending on
the source:
---
darwin.h
#define DSYMUTIL_SPEC \
"%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%{v} \
%{gdwarf-2:%{!gstabs*:%{!g0: -idsym}}}\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{gdwarf-2:%{!gstabs*:%{!g0: -dsym}}}}}}}}}}}"
#define LINK_COMMAND_SPEC LINK_COMMAND_SPEC_A DSYMUTIL_SPEC
---
and 'dsymutil' will be called if:
- source file is on the command line
- some object files have lto
and it will not be called if we link object files only.
collect2.c
---
static void
post_ld_pass (bool temp_file) {
if (!(temp_file && flag_idsym) && !flag_dsym)
return;
do_dsymutil (output_file);
}
---
> 2. Some as yet unexplained issue with new dsymutil
> it's probable that if you can do something like:
>
> clang a.o b.o .... z.o -g -o t
> dsymutil t
> and get errors - then the right thing is to file a radar (since that's really
> only using ld64 and dsymutil - which are both outside the GCC source base).
It would be hard in our case to come up with an example that can
duplicate the problem. To many libraries and prepossessed files, etc..
> It's possible that there's some fault with symbols in the object files that
> doesn't somehow affect linking and doesn't trip up nm .. but adversely affects
> dsymutil - not sure I can exactly envision that right now.
Based on some checking on older systems I think that Apple switched to
llvm-dsymutil (part of LLVM source) on El Capitan. Not sure about
Yosemite. I tried darwin10's dsymutil and it does NOT produce any
warnings on the same set of object files.
