Bug 49992 - lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
Summary: lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-05 17:09 UTC by Jack Howarth
Modified: 2011-11-18 11:48 UTC (History)
10 users (show)

See Also:
Host: x86_64-apple-darwin{10,11)
Target: x86_64-apple-darwin{10,11}
Build: x86_64-apple-darwin{10,11}
Known to work:
Known to fail:
Last reconfirmed: 2011-08-05 20:26:53


Attachments
make errors.c match core-diagnostic.c in the shared interfaces (8.52 KB, patch)
2011-08-08 17:57 UTC, Iain Sandoe
Details | Diff
remove ranlib special casing from the darwin port (840 bytes, patch)
2011-09-22 09:34 UTC, Iain Sandoe
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2011-08-05 17:09:40 UTC
When using an lto-bootstrap on x86_64-apple-darwin11 under Xcode 4.1 with the current work-in-progress patch for containerization of LTO sections on darwin...

http://gcc.gnu.org/ml/gcc-bugs/2011-07/msg00595.html

the bootstrap now fails with a duplicate symbol at...


/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./prev-gcc/g++ -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.7/x86_64-apple-darwin11.0.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/libsupc++/.libs -I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/include/x86_64-apple-darwin11.0.0 -I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110805/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/libsupc++/.libs  -g -O2 -mdynamic-no-pic -flto=jobserver -frandom-seed=1 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -lintl -L/sw/lib -liconv  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
ld: duplicate symbol trim_filename(char const*) in libcommon.a(diagnostic.o) and errors.o for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [gengtype] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
Comment 1 Jack Howarth 2011-08-05 17:12:16 UTC
  $ ../gcc-4.7-20110805/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl
Comment 2 Iain Sandoe 2011-08-05 20:26:53 UTC
also on x86-apple-darwin10.

likely caused by:
 http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg00369.html

which seems to introduce the building of gcc/errors.o
Comment 3 Jack Howarth 2011-08-05 23:21:36 UTC
Confirmed on x86_64-apple-darwiin11 that the lto-bootstrap failure due to duplicate symbols in introduced at...

Author: jakub
Date: Thu Aug  4 11:30:45 2011
New Revision: 177358

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177358
Log:
2011-08-04  Romain Geissler  <romain.geissler@gmail.com>

	* gengtype-state.c: Include "bconfig.h" if
	GENERATOR_FILE is defined, "config.h" otherwise.
	* gengtype.c: Likewise.
	* gengtype-lex.l: Likewise.
	* gengtype-parse.c: Likewise.
	* Makefile.in (gengtype-lex.o-warn): New variable.
	(plugin_resourcesdir): Likewise.
	(plugin_bindir): Likewise.
	(plugin_includedir): Use $(plugin_resourcesdir) as prefix base.
	(MOSTLYCLEANFILES): Add gengtype$(exeext).
	(native): Depend on gengtype$(exeext) is $enable_plugin
	is set to "yes".
	(gtype.state): Depend on s-gtype. Use temporary file.
	(gengtype-lex.o): New rule.
	(gengtype-parse.o): Likewise.
	(gengtype-state.o): Likewise.
	(gengtype$(exeext)): Likewise.
	(install-gengtype): Likewise.
	(gengtype.o): Likewise.
	(build/gengtype.o): Depend on version.h.
	(build/gengtype-state): Depend on double-int.h, version.h,
	$(HASHTAB_H), $(OBSTACK_H), $(XREGEX_H) and build/errors.o.
	(install-plugin): Depend on install-gengtype.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/gengtype-lex.l
    trunk/gcc/gengtype-parse.c
    trunk/gcc/gengtype-state.c
    trunk/gcc/gengtype.c
Comment 4 Dominique d'Humieres 2011-08-06 16:29:58 UTC
On x86_64-apple-darwin10 I get the same bootstrap failure:

...
mv -f Tlto-wrapper lto-wrapper
gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -o gengtype gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -lintl -L/opt/sw64/lib -liconv  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
ld: duplicate symbol _trim_filename in libcommon.a(diagnostic.o) and errors.o
collect2: ld returned 1 exit status
make[3]: *** [gengtype] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gcov.pod gfdl.pod cpp.pod fsf-funding.pod gcc.pod
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

with the following configure

../p_work/configure --prefix=/opt/gcc/gcc4.7p --enable-languages=c,c++,lto,fortran --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --enable-checking=release --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-lto

but not with

../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-lto

Apparently the key is "--enable-checking=something".
Comment 5 Jack Howarth 2011-08-08 17:45:03 UTC
We seem to have...


/* Given a partial pathname as input, return another pathname that
   shares no directory elements with the pathname of __FILE__.  This
   is used by fancy_abort() to print `Internal compiler error in expr.c'
   instead of `Internal compiler error in ../../GCC/gcc/expr.c'.  This
   version is meant to be used for the gen* programs and therefor need not
   handle subdirectories.  */

const char *
trim_filename (const char *name)
{
  static const char this_file[] = __FILE__;
  const char *p = name, *q = this_file;

  /* Skip any parts the two filenames have in common.  */
  while (*p == *q && *p != 0 && *q != 0)
    p++, q++;

  /* Now go backwards until the previous directory separator.  */
  while (p > name && !IS_DIR_SEPARATOR (p[-1]))
    p--;

  return p;
}

in errors.c and...


/* Given a partial pathname as input, return another pathname that
   shares no directory elements with the pathname of __FILE__.  This
   is used by fancy_abort() to print `Internal compiler error in expr.c'
   instead of `Internal compiler error in ../../GCC/gcc/expr.c'.  */

const char *
trim_filename (const char *name)
{
  static const char this_file[] = __FILE__;
  const char *p = name, *q = this_file;

  /* First skip any "../" in each filename.  This allows us to give a proper
     reference to a file in a subdirectory.  */
  while (p[0] == '.' && p[1] == '.' && IS_DIR_SEPARATOR (p[2]))
    p += 3;

  while (q[0] == '.' && q[1] == '.' && IS_DIR_SEPARATOR (q[2]))
    q += 3;

  /* Now skip any parts the two filenames have in common.  */
  while (*p == *q && *p != 0 && *q != 0)
    p++, q++;

  /* Now go backwards until the previous directory separator.  */
  while (p > name && !IS_DIR_SEPARATOR (p[-1]))
    p--;

  return p;
}

in diagnostic.c. Shouldn't we either rename one of these trim_filename subroutines or unify on a single trim_filename subroutine that is always called from libcommon.a?
Comment 6 Iain Sandoe 2011-08-08 17:57:06 UTC
Created attachment 24951 [details]
make errors.c match core-diagnostic.c in the shared interfaces

OK. So Darwin's ld is telling the truth - the routine does exist in both errors.o and the libcommon.a.

I guess, the issue is that (a) the implementations are subtly different, and (b) there could be causes that would get core-diagnostic.o and errors.o both included (e.g. a reference to fatal_error).

I'm testing out the attached patch on i686-linux, x86-64-linux and *-darwin{9,10}.

What is _not_ obvious to me is why x86_64-darwin{10,11} is bitten by this, but *-darwin9 and linux are not.

===

the patch makes the errors.c interface match the core-diagnostic.c ones (and more rigorously checks that the relevant headers are included on GENERATOR_FILE).

of course, I'm not terribly familiar with the generator programs - there could be some excellent reason that errors.c:fatal () is declared differently from core-diagnostics.c:fatal_error ().
Comment 7 Dominique d'Humieres 2011-08-08 18:12:34 UTC
> Apparently the key is "--enable-checking=something".

It is even more subtle (x86_64-apple-darwin10):

../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-checking=none

fails, while

../work/configure --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64 --enable-cloog-backend=isl --enable-checking=yes

succeeds. This for bootstraps wthout lto enabled:

[macbook] f90/bug% gfc pr49638_2.f90 -flto
f951: error: LTO support has not been enabled in this configuration
Comment 8 Iain Sandoe 2011-08-08 18:22:38 UTC
(In reply to comment #7)
> > Apparently the key is "--enable-checking=something".
> 
> It is even more subtle (x86_64-apple-darwin10):
> 
> ../work/configure --prefix=/opt/gcc/gcc4.7w
> --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/opt/sw64
> --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64
> --enable-cloog-backend=isl --enable-checking=none
> 
> fails, while
> 
> ../work/configure --prefix=/opt/gcc/gcc4.7w
> --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/opt/sw64
> --with-libiconv-prefix=/opt/sw64 --with-system-zlib --with-cloog=/opt/sw64
> --enable-cloog-backend=isl --enable-checking=yes
> 
> succeeds. This for bootstraps wthout lto enabled:
> 
> [macbook] f90/bug% gfc pr49638_2.f90 -flto
> f951: error: LTO support has not been enabled in this configuration

the with/without checking will alter the usage of diagnostic routines.  

It doesn't seem to me to have much to do with lto - it seems a build issue.  I.E. one should not be including two different implementations of  the diagnostics on the same link line.
Comment 9 Dominique d'Humieres 2011-08-08 18:31:02 UTC
> It doesn't seem to me to have much to do with lto - it seems a build issue. 
> I.E. one should not be including two different implementations of  the
> diagnostics on the same link line.

I agree!-) 

BTW your patch in comment #6 does not solve the problem with the configure in comment #4
(with --enable-checking=release).
Comment 10 Jack Howarth 2011-08-08 19:27:58 UTC
This is radar://6320843 "duplicate symbols from static libraries not properly ignored" revisiting us...

26-Oct-2008 10:43 AM Jack Howarth:
Xcode 3.2 fails to link cc1plus-dummy from gcc 4.3.2 due to a reappearance of radar 5808800//5779681 which was appeared and was fixed during the Xcode 3.1 development cycle. The bug causes the following link failure while building FSF gcc 4.3.2...

etc.

Their response was...

06-Nov-2008 03:04 PM KIT CHEUNG :
Engineering has requested the following information in order to further investigate this issue:
 
How was libbackend.a created?  Its table of contents is wrong because it contains entries for tentative definitions.  

We ran ranlib on libbackend.a then bad_link_command succeeded.  

If you run:
   ranlib -c libbackend.a
then bad_link_command fails again.   

So my guess is that the build used the -c option when creating libbackend.a.  Is there a reason for this? 

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.
Comment 11 Iain Sandoe 2011-08-08 22:39:31 UTC
(In reply to comment #9)
> > It doesn't seem to me to have much to do with lto - it seems a build issue. 
> > I.E. one should not be including two different implementations of  the
> > diagnostics on the same link line.
> 
> I agree!-) 
> 
> BTW your patch in comment #6 does not solve the problem with the configure in
> comment #4
> (with --enable-checking=release).

this just completed for me:

/GCC/gcc-live-trunk/configure --prefix=/GCC/gcc-4-7-install --target=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --build=x86_64-apple-darwin10 --enable-version-specific-runtime-libs --enable-threads --enable-checking=release --program-suffix=-4.7tnk --with-libiconv-prefix=/usr --with-system-zlib --with-gmp=/GCC/multiprec-math/x86_64 --with-mpfr=/GCC/multiprec-math/x86_64 --with-mpc=/GCC/multiprec-math/x86_64 --enable-languages=c,c++,fortran,objc,lto,obj-c++ --enable-lto --enable-objc-gc
Comment 12 Iain Sandoe 2011-08-08 22:41:32 UTC
(In reply to comment #10)
> This is radar://6320843 "duplicate symbols from static libraries not properly
> ignored" revisiting us...

hm I doubt it.  
Check the Makefiles for darwin11 - but, on x86_64-darwin10,  RANLIB is "ranlib" without the "-c".
Comment 13 Jack Howarth 2011-08-08 22:59:56 UTC
(In reply to comment #12)
> (In reply to comment #10)
> > This is radar://6320843 "duplicate symbols from static libraries not properly
> > ignored" revisiting us...
> 
> hm I doubt it.  
> Check the Makefiles for darwin11 - but, on x86_64-darwin10,  RANLIB is "ranlib"
> without the "-c".

It would still be a form of the problem regardless of whether -c is involved. A normal unix linker should ignore the symbols from a static library in favor of those from the object files. This obviously still isn't the case under darwin'c current linker.
Comment 14 Jack Howarth 2011-08-09 00:09:08 UTC
Iain,
   I would also add that when I was trying avoid having to resort to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01583.html, I found that the linker bug, where duplicate symbols in static libraries weren't properly ignored, appeared to require a specific set of object files to trigger. I believe you will find that if you attempt to extract a reduced test case from just the declarations of trim_filename in errors.c and diagnostics.c, with one in a static lib, you won't be able to trigger the problem.
Comment 15 Iain Sandoe 2011-08-09 10:17:45 UTC
ld doesn't "ignore" anything - the rules it is (supposed) to use are there in "man ld".

however suppose:

object.o : contains (public) symbols foo and bar

library.a : contains (public) symbols baz and bar in module mod.

if a link line causes foo to be resolved from object.o and baz from library.a then there _WILL_ be two versions of bar.
Comment 16 Iain Sandoe 2011-08-09 11:56:33 UTC
(In reply to comment #12)
> (In reply to comment #10)
> > This is radar://6320843 "duplicate symbols from static libraries not properly
> > ignored" revisiting us...
> 
> hm I doubt it.  
> Check the Makefiles for darwin11 - but, on x86_64-darwin10,  RANLIB is "ranlib"
> without the "-c".

well, apologies - it DOES seem to be this issue.

 libcommon.a , libbackend.a amd libcommon-target.a are being "ranlib -c".
(these appear to be the only cases).

diagnostics.o is forced in by resolving ___gnu_lto_v1.

RANLIB_FLAGS is (intentionally) to "-c" by gcc/configure on *-*-darwin*

so .. we need to figure out what to do next - there's no comment on what problem was solved by adding the "-c" in configure - only that it makes darwin's ranlib do the same as others.
Comment 17 Iain Sandoe 2011-08-09 13:15:26 UTC
the use of "-c" (for libbackend.a) was introduced by
http://gcc.gnu.org/viewcvs?view=revision&revision=84088
without any specific comment as to why it was done.

trying *-darwin9 and x86_64-darwin10 with default ranlib behavior.

If it is a ld bug - then I guess the radar needs re-opening - but, if the default on darwin is NOT to include common vars in the table of contents, one wonders why we decided to do different.

the lto symbol is still present in each object in the archive - so, as long as lto does not expect it to be in the table of contents in order to determine if the library is compiled with lto, we should be OK to remove it.
Comment 18 Jack Howarth 2011-08-09 13:52:29 UTC
The radr://6320843, "duplicate symbols from static libraries not properly ignored", has been open since 26-Oct-2008. I later opened radr://6733684, "duplicate symbols in static libs not properly ignored when linking in 10A###" with additional examples including...

gcc -I/sw/include -DXNO_MTSAFE_STRINGAPI -DXNO_MTSAFE_PWDAPI -DXNO_MTSAFE_TIMEAPI -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -fno-tree-ter -I/sw/include/freetype2 -I/sw/include -I/usr/X11/include -I/sw/include -I/sw/include -o wml wml.o -Wl,-framework -Wl,CoreServices -Wl,-framework -Wl,ApplicationServices  -L/sw/lib -L/sw/src/fink.build/openmotif4-2.3.1-3/openmotif-2.3.1/tools/wml -lwml /sw/lib/libiconv.dylib -L/usr/X11R6/lib -lXt -L/usr/X11/lib -lXft -lXrender -lfontconfig /sw/lib/freetype219/lib/libfreetype.dylib -lX11 /sw/lib/libjpeg.dylib /sw/lib/libpng12.dylib -lz  
ld: duplicate symbol _main in /sw/src/fink.build/openmotif4-2.3.1-3/openmotif-2.3.1/tools/wml/libwml.a(wml.o) and wml.o

from openmotif 2.3.0 and it was closed as a duplicate without additional comment. I don't think Apple views this as a critical bug but rather coddling lazy programmers.
Comment 19 Iain Sandoe 2011-08-09 14:10:46 UTC
(In reply to comment #18)
> The radr://6320843, "duplicate symbols from static libraries not properly
> ignored", has been open since 26-Oct-2008. I later opened radr://6733684,
> "duplicate symbols in static libs not properly ignored when linking in 10A###"
> with additional examples

...
> and it was closed as a duplicate without additional
> comment. I don't think Apple views this as a critical bug but rather coddling
> lazy programmers.

not sure if it's a 'laziness' thing - the flag was added in a quite definite manner (it's just not clear as to what problem it was resolving).

==

it's also not clear if Apple acknowledge that it's a bug and it was 'fixed' at least on Darwin 9/ld85 (and then 'unfixed' on darwin >= 10) - or whether there's some other reason that it doesn't manifest on darwin9.

anyway - you could try editing gcc/configure and setting ranlib_flags = "" on Darwin11 and reg-test.

if that is a solution to the problem, and no-one can come up with any reason why we should include common symbols in the table of contents for darwin archives, then maybe we should just do this for darwin >= 9.
Comment 20 Jack Howarth 2011-08-09 14:19:34 UTC
I wonder if addressing...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554#c15

would help such that the change in r157563 is extended to gcc/configure[.ac] would make any difference?
Comment 21 Iain Sandoe 2011-08-09 14:26:36 UTC
(In reply to comment #20)
> I wonder if addressing...
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554#c15
> 
> would help such that the change in r157563 is extended to gcc/configure[.ac]
> would make any difference?

well, that's essentially what I'm suggesting 

something like 
*-*-darwin[[912]]*)
  ranlib_flags = ""
;;

*-*-darwin*)
  ranlib_flags = "-c"
;;
  
*)
  ranlib_flags = ""
;;

(untested, just typed into the browser)

- i.e. actually applying the change to darwin9 too, (testing that here).
Comment 22 Jack Howarth 2011-08-09 14:35:18 UTC
or more correctly just...

Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac	(revision 177598)
+++ gcc/configure.ac	(working copy)
@@ -821,11 +821,8 @@ gcc_AC_PROG_LN_S
 ACX_PROG_LN($LN_S)
 AC_PROG_RANLIB
 case "${host}" in
-*-*-darwin*)
-  # By default, the Darwin ranlib will not treat common symbols as
-  # definitions when  building the archive table of contents.  Other 
-  # ranlibs do that; pass an option to the Darwin ranlib that makes
-  # it behave similarly.
+*-*-darwin[[3-9]]*)
+# ranlib before Darwin10 requires the -c flag to look at common symbols.
   ranlib_flags="-c" 
   ;;
 *)
Comment 23 Iain Sandoe 2011-08-09 14:49:19 UTC
(In reply to comment #22)
> or more correctly just...
> 
> Index: gcc/configure.ac
> ===================================================================
> --- gcc/configure.ac    (revision 177598)
> +++ gcc/configure.ac    (working copy)
> @@ -821,11 +821,8 @@ gcc_AC_PROG_LN_S
>  ACX_PROG_LN($LN_S)
>  AC_PROG_RANLIB
>  case "${host}" in
> -*-*-darwin*)
> -  # By default, the Darwin ranlib will not treat common symbols as
> -  # definitions when  building the archive table of contents.  Other 
> -  # ranlibs do that; pass an option to the Darwin ranlib that makes
> -  # it behave similarly.
> +*-*-darwin[[3-9]]*)
> +# ranlib before Darwin10 requires the -c flag to look at common symbols.
>    ranlib_flags="-c" 
>    ;;
>  *)

well, I don't see that darwin 9 does anything different from darwin 10 in this respect (and I wonder if darwin 8 does either).

and ...  watch out for the first case matching all darwin ;-) and the second never firing.
Comment 24 Jack Howarth 2011-08-09 15:27:34 UTC
Then you will also want to adjust the original toplevel configure change...

Author: mrs
Date: Fri Mar 19 10:19:52 2010
New Revision: 157563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157563
Log:
	PR ada/42554
	* configure.ac: Only pass -c to ranlib for darwin9 and earlier.
	* configure: Regenerate.

Modified:
    trunk/ChangeLog
    trunk/configure
    trunk/configure.ac

Extending this patch to gcc/configure[.ac] eliminates the lto-bootstrap failures from duplicate symbols under darwin11. As for darwin9, do we know that this change that allows ranlib to look at common symbols in archives has been backported to the Xcode in darwin9?
Comment 25 Jack Howarth 2011-08-09 15:30:54 UTC
(In reply to comment #23)

> and ...  watch out for the first case matching all darwin ;-) and the second
> never firing.

Why would you say that? I believe we have many instances of *-apple-darwin[[3-9]]* in the configure.ac's of FSF gcc.
Comment 26 Iain Sandoe 2011-08-09 15:40:38 UTC
(In reply to comment #25)
> (In reply to comment #23)
> 
> > and ...  watch out for the first case matching all darwin ;-) and the second
> > never firing.
> 
> Why would you say that? I believe we have many instances of
> *-apple-darwin[[3-9]]* in the configure.ac's of FSF gcc.

misread the patch .. 

===

but - I'm not sure what you mean by  "ranlib before Darwin10 requires the -c flag to look at common symbols. "

Where is it documented that there is some different behavior of Darwin 9 (or 8, for that matter)?

what  "ranlib -c" does is to put common symbols into the archive symbol table.

the common symbols are still present in each archive object with (or without) "-c" (so they can be 'seen' if a module is loaded that uses them)..

So, the case that would require '-c' is if a common symbol must be found in the archive table of contents ... this (as the man page says) seems like an unlikely scenario.

Mike: can you recall why this was done and what problem it solved?
Comment 27 Mike Stump 2011-08-09 17:29:28 UTC
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.
Comment 28 Iain Sandoe 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).
Comment 29 Mike Stump 2011-08-09 17:55:15 UTC
From the thread last time we talked about this code:

  http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01183.html
Comment 30 Iain Sandoe 2011-08-09 18:57:36 UTC
so, if we have no regressions from omitting the "-c" we might conclude that things have changed since then ;-)

===

simple testcase:

$ cat /Volumes/ScratchCS/tests/statlib.c 

int common_symbol;

int libfunc (int a)
{
  return a + common_symbol;
}

$ cat /Volumes/ScratchCS/tests/main-using-common-sym.c 

int common_symbol ;

int main (int ac, char *av[])
{
  int a;
  a = ac + 5;
  common_symbol = a - 6;
  return common_symbol;

}

===
$ uname -v
Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386
$ ./gcc/xgcc --version
xgcc (GCC) 4.7.0 20110806 (experimental) [trunk revision 177536]

$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/statlib.c -c 
$ ar -cru libstat.a statlib.o 
$ ranlib libstat.a 
$ ./gcc/xgcc -Bgcc /Volumes/ScratchCS/tests/main-using-common-sym.c -c
$ ./gcc/xgcc -Bgcc main-using-common-sym.o -o tt -Wl,-why_load
<no output>
$ ./gcc/xgcc -Bgcc main-using-common-sym.o libstat.a -o tt -Wl,-why_load
<no output>

$ ranlib -c libstat.a 
$ ./gcc/xgcc -Bgcc main-using-common-sym.o libstat.a -o tt -Wl,-why_load
_common_symbol forced load of libstat.a(statlib.o)

OK.. so there's your reduced testcase.

(on Darwin 9 there's no output in either case).
Comment 31 Jack Howarth 2011-08-09 20:23:01 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.

Mike,
   Extending the original fix to PR42554 with the patch I proposed in Comment 22 seems like a better  approach since it is darwin-specifc as is the linker bug requiring the fix. The alternative approach of unifying or renaming trim_filename will require additional reviews and is a heavier lift.
Comment 32 Iain Sandoe 2011-08-09 20:28:54 UTC
testing this (all languages, lto bootstrap, compare debug) on darwin 9.

will post comment 6 for review (it's a tidy up anyway unless there's some gotcha reason for not doing it on some platform).

Index: configure.ac
===================================================================
--- configure.ac	(revision 177599)
+++ configure.ac	(working copy)
@@ -2274,8 +2274,9 @@ case "${target}" in
     extra_arflags_for_target=" -X32_64"
     extra_nmflags_for_target=" -B -X32_64"
     ;;
-  *-*-darwin[[3-9]]*)
-    # ranlib before Darwin10 requires the -c flag to look at common symbols.
+  *-*-darwin[[3-8]]*)
+    # Some earlier (circa 2002) version of Darwin required that common symbols
+    # were placed in archive tocs to resolve an issue with g77.
     extra_ranlibflags_for_target=" -c"
     ;;
 esac
Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac	(revision 177599)
+++ gcc/configure.ac	(working copy)
@@ -821,13 +821,11 @@ gcc_AC_PROG_LN_S
 ACX_PROG_LN($LN_S)
 AC_PROG_RANLIB
 case "${host}" in
-*-*-darwin*)
-  # By default, the Darwin ranlib will not treat common symbols as
-  # definitions when  building the archive table of contents.  Other 
-  # ranlibs do that; pass an option to the Darwin ranlib that makes
-  # it behave similarly.
-  ranlib_flags="-c" 
-  ;;
+*-*-darwin[[3-8]]*)
+    # Some earlier (circa 2002) version of Darwin required that common symbols
+    # were placed in archive tocs to resolve an issue with g77.
+    extra_ranlibflags_for_target=" -c"
+    ;;
 *)
   ranlib_flags=""
 esac
Comment 33 Mike Stump 2011-08-09 20:58:15 UTC
The patches are wrong, so, I don't favor them.  The patch to fix this, is the patch to either boost things to -fno-common, or to fix trim_filename.
Comment 34 Jack Howarth 2011-08-09 22:00:59 UTC
(In reply to comment #33)
> The patches are wrong, so, I don't favor them.  The patch to fix this, is the
> patch to either boost things to -fno-common, or to fix trim_filename.

I am puzzled as to why you are so wedded to the use of 'ranlib -c' which was only introduce to solve an ancient linker bug. By this logic, we also need to revert ...

Author: mrs
Date: Fri Mar 19 10:19:52 2010
New Revision: 157563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157563
Log:
    PR ada/42554
    * configure.ac: Only pass -c to ranlib for darwin9 and earlier.
    * configure: Regenerate.

Modified:
    trunk/ChangeLog
    trunk/configure
    trunk/configure.ac

which you committed yourself. If you accept that r157563 was correct, then the proposed patch can be viewed as addressing http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554#c15.
Comment 35 mrs@gcc.gnu.org 2011-08-10 22:11:22 UTC
I believe this problem has been fixed.  trim_filename doesn't appear twice.
Comment 36 Jack Howarth 2011-08-10 23:22:57 UTC
Still broken at r177628 with http://gcc.gnu.org/ml/gcc-bugs/2011-08/msg00935.html and...

 ../gcc-4.7-20110810/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl

...at..

/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./prev-gcc/g++ -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.7/x86_64-apple-darwin11.0.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/libsupc++/.libs -I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/include/x86_64-apple-darwin11.0.0 -I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20110810/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/prev-x86_64-apple-darwin11.0.0/libstdc++-v3/libsupc++/.libs  -g -O2 -mdynamic-no-pic -flto=jobserver -frandom-seed=1 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie -o gengtype \
	    gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -lintl -L/sw/lib -liconv  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
ld: duplicate symbol trim_filename(char const*) in libcommon.a(diagnostic.o) and errors.o for architecture x86_64

Again, I don't understand your resistance to weaning darwin9+ off of 'ranlib -c' in light of the darwin linker developer's confirmation that the use of  ranlib '-c' is discouraged on darwin. Considering that it was added in prehistoric times (gcc 3.3), there appears to be no rational need to retain its usage.
Comment 37 Jack Howarth 2011-08-11 00:02:40 UTC
This issue is not fixed.
Comment 38 Jack Howarth 2011-08-11 01:25:05 UTC
(In reply to comment #35)
> I believe this problem has been fixed.  trim_filename doesn't appear twice.

Exactly what commit led you to believe this was fixed?  I see nothing that could have possibly eliminated the duplicate trim_filename's in errors.c and diagnostic.c
Comment 39 Iain Sandoe 2011-08-11 08:52:24 UTC
(In reply to comment #37)
> This issue is not fixed.

concur.

Mike; there are two problems.

a.  the link line for gcc/gengtype (recently introduced) includes both errors.o and libcommon.a

  - this could cause a conflict on any system if, say, fatal_error (resolved from diagnostics.o) and fatal (resolved from errors.o) were called.

  - comment 6. addresses this.

b. the "regression" in Darwin's ld that causes it to load the first member of an archive that includes a used common symbol.  

 - this will always happen with LTO, which uses a common symbol "___gnu_lto_v1" to flag that an object has been built LTO (see toplev.c).

- it can also happen subtly and randomly with other cases using common symbols.

* the vendor's response to a repost on this ld bug is "The preferred solution is to not use -c with ranlib.  "

 ... unless you can produce a patch (or identify a plan for such a patch) that would obviate the need for common symbols in the darwin port, it doesn't seem that we have any realistic expectation of fixing this in any other way than comment 32.
Comment 40 Jack Howarth 2011-08-11 12:47:02 UTC
(In reply to comment #39)
>  ... unless you can produce a patch (or identify a plan for such a patch) that
> would obviate the need for common symbols in the darwin port, it doesn't seem
> that we have any realistic expectation of fixing this in any other way than
> comment 32.

I would also add that we have already abandoned the use of 'ranlib -c' in the top level configure so  extending this change to the gcc subdirectory's configure can be viewed as making the calls to ranlib on darwin10+ consistent.
Comment 41 Jack Howarth 2011-08-11 13:22:46 UTC
Note that I can also confirm the failure from Comment 4 on darwin11. Using unpatched gcc trunk svn at r177665 when building with clang on darwin11 using...

../gcc-4.7-20110811/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=release --enable-cloog-backend=isl

results  in the linkage failure...

../../gcc-4.7-20110811/gcc/vegcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H  -o gengtype \
    gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -lintl -L/sw/lib -liconv  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
...
ld: duplicate symbol _fancy_abort in libcommon.a(diagnostic.o) and errors.o for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [gengtype] Error 1
...
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2

So we can not really ignore this PR as it breaks --enable-checking=release. Note that lto is not required for this failure mode.
Comment 42 Mike Stump 2011-08-11 13:26:18 UTC
Ick.  Oh well.  Ok, how about outright removing for all darwin releases the -c setting?  I think the only thing this could break was fortran.  I have no clue about what to do for Ada.  :-(  I'll pre-approve the solution you two decide on.
Comment 43 Iain Sandoe 2011-08-11 13:48:56 UTC
(In reply to comment #42)
> Ick.  Oh well. 

Ick, indeed ....  this is (yet another) reason to have our own tool-chain.

----
 >Ok, how about outright removing for all darwin releases the -c
> setting?  I think the only thing this could break was fortran.  

Darwin9 (including java and fortran) are unaffected by removing the '-c' (no surprise really, since it correctly ignores common symbols in the archive toc).

I'd like to check Darwin 8 before making the change global - and my ppc machine is busy - so let's hang fire for a couple of days.

As things stand, Darwin 7 is only capable of building the c compiler using XCode 1.5 toolset [c++, fortran etc. require section support not available in XCode 1.5].

I did manage to build trunk of 4.6 on Darwin 7 by using odcctools-98 (plus some config header mods).

Thus, if Darwin 8 works without regression, then I'd say that we've realistically covered all bases that apply to Darwin versions that are capable of building trunk (since any earlier version would have to use odcctools).

> I have no clue about what to do for Ada.  :-(  I'll pre-approve the solution you two decide
> on.

It's on my TODO to bootstrap a version of ADA - I guess that means doing a canadian from linux - likely to be a bundle of laughs (unless you know of a downloadable ada binary for Darwin 9 or 10 at least).

====

Changing the topic to target - although there's a latent issue with the two diagnostic implemenations, (and I will post comment 6, when the reg-tests are done on linux) the actual bug is a target one.
Comment 44 Jack Howarth 2011-08-11 14:28:31 UTC
(In reply to comment #42)
> Ick.  Oh well.  Ok, how about outright removing for all darwin releases the -c
> setting?  I think the only thing this could break was fortran.  I have no clue
> about what to do for Ada.  :-(  I'll pre-approve the solution you two decide
> on.

I see no evidence of breakage on fortran...

http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg01198.html

Note that...

XPASS: gfortran.dg/graphite/interchange-1.f  -O  scan-tree-dump-times graphite "will be interchanged" 1

is occurring on other targets.
Comment 45 Mike Stump 2011-08-11 16:32:50 UTC
On Aug 11, 2011, at 6:48 AM, iains at gcc dot gnu.org wrote:
> It's on my TODO to bootstrap a version of ADA - I guess that means doing a
> canadian from linux - likely to be a bundle of laughs (unless you know of a
> downloadable ada binary for Darwin 9 or 10 at least).

Jack or the Ada folks might have a pointer.  google turns up http://aadl.enst.fr/ocarina/releases/, if you have ppc or rosetta.
Comment 46 Jack Howarth 2011-08-11 17:19:14 UTC
(In reply to comment #45)
> Jack or the Ada folks might have a pointer.  google turns up
> http://aadl.enst.fr/ocarina/releases/, if you have ppc or rosetta.

I've never added ada to the language set for the fink gcc4x packages because I object to the concept of having to add an external dependency on a prebuilt ada compiler in order to bootstrap FSF gcc.
Comment 47 Jack Howarth 2011-08-11 23:06:45 UTC
(In reply to comment #43)

> Changing the topic to target - although there's a latent issue with the two
> diagnostic implemenations, (and I will post comment 6, when the reg-tests are
> done on linux) the actual bug is a target one.

Iain,
    Note that error posted in Comment 41. There are additional duplicated symbols in errors.c that conflict with those in diagnostic.c (in that case fancy_abort). So if you intend to proceed with the patch in comment 6, it should be expanded to address all the duplicated symbols which can potentially conflict. Alternative, we can simply drop the use of '-c' with ranlib and be done with it.
Comment 48 Jack Howarth 2011-08-12 00:51:20 UTC
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01083.html.
Comment 49 Iain Sandoe 2011-08-12 08:51:32 UTC
(In reply to comment #47)
> (In reply to comment #43)
> 
> > Changing the topic to target - although there's a latent issue with the two
> > diagnostic implemenations, (and I will post comment 6, when the reg-tests are
> > done on linux) the actual bug is a target one.


>     Note that error posted in Comment 41. There are additional duplicated
> symbols in errors.c that conflict with those in diagnostic.c (in that case
> fancy_abort). So if you intend to proceed with the patch in comment 6, it
> should be expanded to address all the duplicated symbols which can potentially
> conflict. 

comment 6 does not rename the duplicated symbols.  In fact  what it does is to rename "fatal" = > "fatal_error" in the gen* and errors.c, so that it is not necessary to link errors.o when libcommon.a is available. 

Looking at comment 41, it doesn't look as if you had applied comment 6 when the test was carried out - since the link line includes both errors.o and libcommon.a.

>Alternative, we can simply drop the use of '-c' with ranlib and be
> done with it.

let's complete the testing on darwin 8 - and, if that is OK, I'll produce a patch to remove the special casing of ranlib on darwin entirely (as suggested by Mike).
Comment 50 Iain Sandoe 2011-08-14 08:10:32 UTC
(In reply to comment #42)
>   I have no clue about what to do for Ada.

Ada is unaffected on i686-darwin9 ... 
... it won't bootstrap on powerpc-darwin9 for 4.6 or trunk (investigating).

have to see what can be done to bootstrap on darwin10.

===

powerpc-darwin9-X-darwin8 using cctools 622 is also unaffected.

(native bootstrap on darwin8 will have to wait until the investigation of ada bootstrap issue is complete).
Comment 51 mrs@gcc.gnu.org 2011-08-31 17:48:05 UTC
So, I propose we fix this now and deal with any potential fallout later.  Slightly bug pushing, which I'm not terribly fond of, but, better than leaving it sit.  The other fix, arguable better, would be to never use a public common for this lto data.  I don't understand and know lto well enough to know what to suggest.  If things can look at private symbols, maybe make it private.  If it doesn't have to be storage, make it an absolute value.  Add a target hook to generate it, and then do something special for darwin.  Make it a hard define, which is weak.  Try one's hand at COMDAT on it.  When it comes to shared libraries, having any trace of common could be a deal killer anyway.
Comment 52 Iain Sandoe 2011-09-22 09:34:49 UTC
Created attachment 25336 [details]
remove ranlib special casing from the darwin port

so, this has taken a long time...

Mike's throw-away comment about Ada took some answering ;)  
(well, at least we now have Ada bootstrap on powerpc again).

Anyway, I have nearly finished testing this on Darwin 9 and Darwin 10 (normal bootstraps).

I would appreciate some help with testing on Darwin 11 and with lto-bootstraps on Darwin 10 (since my resources are stretched to the limit right now).

===

In summary, for current usable toolsets that are able to bootstrap 4.6 or 4.7 on Darwin 8 .. 10, I can see no reason that we should (or need to) retain a special case for ranlib on Darwin.

Since Darwin < 8 will _not_ bootstrap 4.6 with its native toolset (it needs at least odcctools from Darwin 8) then it is academic whether the special casing would still apply to an earlier toolset.

I am happy for someone else to push this through if time is of concern (not able to devote much right now).
Comment 53 janus 2011-09-22 10:51:49 UTC
(In reply to comment #52)
> Created attachment 25336 [details]
> remove ranlib special casing from the darwin port
> 
> [...]
> 
> I would appreciate some help with testing on Darwin 11 and with lto-bootstraps
> on Darwin 10 (since my resources are stretched to the limit right now).

Is this patch supposed to fix the duplicate symbol issues? On Darwin 11.1 I still get (also with the patch):

ld: duplicate symbol _trim_filename in libcommon.a(diagnostic.o) and errors.o for architecture x86_64
Comment 54 Iain Sandoe 2011-09-22 11:01:05 UTC
(In reply to comment #53)
> (In reply to comment #52)
> > Created attachment 25336 [details]
> > remove ranlib special casing from the darwin port
> > 
> > [...]
> > 
> > I would appreciate some help with testing on Darwin 11 and with lto-bootstraps
> > on Darwin 10 (since my resources are stretched to the limit right now).
> 
> Is this patch supposed to fix the duplicate symbol issues? On Darwin 11.1 I
> still get (also with the patch):

yes (assuming that those problems are still the result of the common symbols).

> 
> ld: duplicate symbol _trim_filename in libcommon.a(diagnostic.o) and errors.o
> for architecture x86_64

The patch is in the standard form for submission - you will need to regenerate configure and gcc/configure (or it will have essentially no effect).

I use:
autoconf -I. -Iconfig (in the root)
and
autoconf -I. -I.. -I../config (in ./gcc)

you must use autoconf etc. as per the GCC pre-requisites;
Comment 55 Jack Howarth 2011-09-22 15:31:13 UTC
The proposed patch (with the necessary 177598-pr48108-WIP applied.. hint, hint) completes an lto-boostrap on darwin11 without issues for...

Using built-in specs.
COLLECT_GCC=gcc-fsf-4.7
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.2.0
Configured with: ../gcc-4.7-20110922/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.7.0 20110922 (experimental) (GCC) 

will post regression test later tonight to gcc-testresults.
Comment 56 Jack Howarth 2011-09-22 23:59:25 UTC
Regtest results for darwin11 at http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg02262.html.
Comment 57 Dominique d'Humieres 2011-09-23 10:16:28 UTC
> I would appreciate some help with testing on Darwin 11 and with lto-bootstraps
> on Darwin 10 (since my resources are stretched to the limit right now).

See pr50492 for bootstrap with --with-build-config=bootstrap-lto which blocks any testing of the patch with it. Without this option, the results are the same as those without the patch.
Comment 58 Nenad Vukicevic 2011-10-21 19:12:47 UTC
Is there a final patch for this? Or more testing is required.
Comment 59 Iain Sandoe 2011-10-21 19:23:53 UTC
(In reply to comment #58)
> Is there a final patch for this? Or more testing is required.

http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01245.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01246.html

I will ping these over the weekend 

also you would need:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01622.html

if you want to do LTO bootstraps.
Comment 60 Iain Sandoe 2011-11-18 10:52:37 UTC
Author: iains
Date: Fri Nov 18 10:52:32 2011
New Revision: 181469

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181469
Log:

toplevel:

	PR target/49992
	* configure.ac: Remove ranlib special-casing for Darwin.
	* configure: Regenerate.

gcc:

	PR target/49992
	* configure.ac: Remove ranlib special-casing for Darwin.
	* configure: Regenerate.


Modified:
    trunk/ChangeLog
    trunk/configure
    trunk/configure.ac
    trunk/gcc/ChangeLog
    trunk/gcc/configure
    trunk/gcc/configure.ac
Comment 61 Iain Sandoe 2011-11-18 10:54:24 UTC
Author: iains
Date: Fri Nov 18 10:54:21 2011
New Revision: 181470

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181470
Log:

gcc/ada:

2011-11-18  Tristan Gingold  <gingold@adacore.com>
	    Iain Sandoe  <iains@gcc.gnu.org>

	PR target/49992
	* mlib-tgt-specific-darwin.adb (Archive_Indexer_Options): Remove.
	* gcc-interface/Makefile.in (darwin): Remove ranlib special-casing
	for Darwin.


Modified:
    trunk/gcc/ada/ChangeLog
    trunk/gcc/ada/gcc-interface/Makefile.in
    trunk/gcc/ada/mlib-tgt-specific-darwin.adb
Comment 62 Iain Sandoe 2011-11-18 11:45:48 UTC
Author: iains
Date: Fri Nov 18 11:45:44 2011
New Revision: 181471

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181471
Log:

toplevel:

	PR target/49992
	* configure.ac: Remove ranlib special-casing for Darwin.
	* configure: Regenerate.
gcc:

	PR target/49992
	* configure.ac: Remove ranlib special-casing for Darwin.
	* configure: Regenerate.


Modified:
    branches/gcc-4_6-branch/ChangeLog
    branches/gcc-4_6-branch/configure
    branches/gcc-4_6-branch/configure.ac
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/configure
    branches/gcc-4_6-branch/gcc/configure.ac
Comment 63 Iain Sandoe 2011-11-18 11:47:01 UTC
Author: iains
Date: Fri Nov 18 11:46:58 2011
New Revision: 181472

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181472
Log:

gcc/ada:

2011-11-18  Tristan Gingold  <gingold@adacore.com>
	    Iain Sandoe  <iains@gcc.gnu.org>

	PR target/49992
	* mlib-tgt-specific-darwin.adb (Archive_Indexer_Options): Remove.
	* gcc-interface/Makefile.in (darwin): Remove ranlib special-casing
	for Darwin.


Modified:
    branches/gcc-4_6-branch/gcc/ada/ChangeLog
    branches/gcc-4_6-branch/gcc/ada/gcc-interface/Makefile.in
    branches/gcc-4_6-branch/gcc/ada/mlib-tgt-specific-darwin.adb
Comment 64 Iain Sandoe 2011-11-18 11:48:54 UTC
fixed, although it might be nice one day if we could rationalize the error interfaces so that it is not necessary to link both sets for the plugin generator files.