------- Comment #5 from simon at pushface dot org 2010-02-01 22:53 -------
I think this bug is caused by a much more fundamental problem: the -c switch to
ranlib, which seems to be a Darwin special, appears to cause this problem (at
any rate with Xcode >= 3.2, ie darwin10.
The top-level configure.ac includes the following
*-*-darwin*)
# ranlib from Darwin requires the -c flag to look at common symbols.
extra_ranlibflags_for_target=" -c"
;;
and the SVN log for ths says
r60397 | geoffk | 2002-12-22 06:46:41 +0000 (Sun, 22 Dec 2002) | 4 lines
* configure.in (extra_ranlibflags_for_target): New variable.
(*-*-darwin): Add -c to ranlib commands.
* configure (tooldir): Handle extra_ranlibflags_for_target.
The Darwin man page for ranlib says
-c Include common symbols as definitions with respect to the ta-
ble of contents. This is seldom the intended behavior for
linking from a library, as it forces the linking of a library
member just because it uses an uninitialized global that is
undefined at that point in the linking. This option is
included only because this was the original behavior of ran-
lib. This option is not the default.
Apple, in response to Jack Howarth re: radar 6320843
Darwin static archives traditionally do not have common symbols in there table
of contents. The -c option forces common symbols into the table of contents
and causes this problem.
I have replaced the section of configure.ac above by this:
*-*-darwin1[[0123456789]]*)
# ranlib from Darwin 10 (Xcode 3.2) does not require the -c flag
# to look at common symbols.
;;
*-*-darwin*)
# ranlib from older Darwins requires the -c flag to look at common
# symbols.
extra_ranlibflags_for_target=" -c"
;;
and the build proceeds to completion
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
