[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #35 from Rainer Orth --- (In reply to Iain Sandoe from comment #31) > (In reply to r...@cebitec.uni-bielefeld.de from comment #30) > > With Xcode 6.4 as, 32-bit bootstrap is now well into running the testsuite. > > > > I've filed bug > > > > 23669324 Xcode 7 as creates relocation ld cannot handle > > Thanks! > > The .s file in your attachment crashes TOT llvm/clang (clang -target > i686-apple-darwin12 .s -o t.o ) with an assertion "Value does not fit in > Fixup field". Will try to investigate if I have any spare cycles today. I've just been notified that the bug is fixed in Xcode 7.3.1. Will try that as soon as it hits the Appstore. Rainer
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #36 from Dominique d'Humieres --- > I've just been notified that the bug is fixed in Xcode 7.3.1. > Will try that as soon as it hits the Appstore. I have Xcode 7.3.1 since May 4.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE --- With Xcode 6.4 as, 32-bit bootstrap is now well into running the testsuite. I've filed bug 23669324 Xcode 7 as creates relocation ld cannot handle Rainer
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #31 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #30) > With Xcode 6.4 as, 32-bit bootstrap is now well into running the testsuite. > > I've filed bug > > 23669324 Xcode 7 as creates relocation ld cannot handle Thanks! The .s file in your attachment crashes TOT llvm/clang (clang -target i686-apple-darwin12 .s -o t.o ) with an assertion "Value does not fit in Fixup field". Will try to investigate if I have any spare cycles today.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #32 from Iain Sandoe --- reduced testcase: .text .align 4,0x90 .globl _choose_tmpdir _choose_tmpdir: sbbl$3+_vartmp, %esi ret .space 254 .const .align 2 _vartmp: .byte 47 === It seems that the reloc length is expected to be 1 (which will not, indeed, accommodate the offset). cctools (877.5) using -Q and my local port of GAS both produce; address pcrel length extern typescattered symbolnum/value 0002 False long n/aVANILLA True 0x0108
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #33 from Iain Sandoe --- (In reply to Iain Sandoe from comment #32) > reduced testcase: ..however this is not "our" bug, so there's no known reason to keep this PR open, right? .. if no-one objects by Monday 30th, then let's close it.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #34 from mrs at gcc dot gnu.org --- So, for bugs that aren't fixed, sometimes we work around them. We can use this bug to track things like the vendor bug status (fixed or not), and potential workarounds. Plus, we can list this bug in the documentation for _why_ the compiler doesn't work.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #38 from Eric Gallager --- (In reply to Eric Gallager from comment #37) > (In reply to Rainer Orth from comment #35) > > (In reply to Iain Sandoe from comment #31) > > > (In reply to r...@cebitec.uni-bielefeld.de from comment #30) > > > > With Xcode 6.4 as, 32-bit bootstrap is now well into running the > > > > testsuite. > > > > > > > > I've filed bug > > > > > > > > 23669324 Xcode 7 as creates relocation ld cannot handle > > > > > > Thanks! > > > > > > The .s file in your attachment crashes TOT llvm/clang (clang -target > > > i686-apple-darwin12 .s -o t.o ) with an assertion "Value does not fit > > > in > > > Fixup field". Will try to investigate if I have any spare cycles today. > > > > I've just been notified that the bug is fixed in Xcode 7.3.1. Will try that > > as > > soon as it hits the Appstore. > > > > Rainer > > So does this bug still need to stay open then? Guess not. gcc-5-branch is closed now, anyways, so I'm closing this bug.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 egallager at gcc dot gnu.org changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #37 from egallager at gcc dot gnu.org --- (In reply to Rainer Orth from comment #35) > (In reply to Iain Sandoe from comment #31) > > (In reply to r...@cebitec.uni-bielefeld.de from comment #30) > > > With Xcode 6.4 as, 32-bit bootstrap is now well into running the > > > testsuite. > > > > > > I've filed bug > > > > > > 23669324 Xcode 7 as creates relocation ld cannot handle > > > > Thanks! > > > > The .s file in your attachment crashes TOT llvm/clang (clang -target > > i686-apple-darwin12 .s -o t.o ) with an assertion "Value does not fit in > > Fixup field". Will try to investigate if I have any spare cycles today. > > I've just been notified that the bug is fixed in Xcode 7.3.1. Will try that > as > soon as it hits the Appstore. > > Rainer So does this bug still need to stay open then?
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #20 from Dominique d'Humieres --- Is this still a problem?
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #21 from Iain Sandoe --- (In reply to Dominique d'Humieres from comment #20) > Is this still a problem? I don't believe so - I've bootstrapped 5.2.1(r230380) all langs incl. Ada and Java. Likewise 4.9.3
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #20 from Dominique d'Humieres --- > Is this still a problem? I'm bootstrapping gcc mainline on Mac OS X 10.11.2 Beta just fine. The only problem I'm seeing for quite a while is that i386-apple-darwin bootstrap is failing since mid-August (i386-apple-darwin14.4.0 at that time). Don't have the exact link failure handy, and it certainly warrants its own bug, if we want to deal with 32-bit bootstrap at all. Rainer
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #23 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #22) > > --- Comment #20 from Dominique d'Humieres --- > > Is this still a problem? > > I'm bootstrapping gcc mainline on Mac OS X 10.11.2 Beta just fine. The > only problem I'm seeing for quite a while is that i386-apple-darwin > bootstrap is failing since mid-August (i386-apple-darwin14.4.0 at that > time). Don't have the exact link failure handy, and it certainly > warrants its own bug, if we want to deal with 32-bit bootstrap at all. > > Rainer We do - for darwin9/10 at least (perhaps it's not a drama for 11+ .. but a bootstrap fail indicates something to be looked at IMO). I will be trying 10.5/6 this week for 5.2.1 (at least) in the run up to the rc spin.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #23 from Iain Sandoe --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #22) >> > --- Comment #20 from Dominique d'Humieres --- >> > Is this still a problem? >> >> I'm bootstrapping gcc mainline on Mac OS X 10.11.2 Beta just fine. The >> only problem I'm seeing for quite a while is that i386-apple-darwin >> bootstrap is failing since mid-August (i386-apple-darwin14.4.0 at that >> time). Don't have the exact link failure handy, and it certainly >> warrants its own bug, if we want to deal with 32-bit bootstrap at all. >> >> Rainer > > We do - for darwin9/10 at least (perhaps it's not a drama for 11+ .. but a > bootstrap fail indicates something to be looked at IMO). Ok, I'll dig up the details later today. It may well be related to a command line tools upgraded corresponding to Xcode 7.x. Rainer
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE --- > Ok, I'll dig up the details later today. It may well be related to a > command line tools upgraded corresponding to Xcode 7.x. Here's what I found: in stage2, linking gcj fails with ld: in ../libiberty/libiberty.a(make-temp-file.o), in section __TEXT,__text reloc 17: unsupported r_length=0 for scattered vanilla reloc for architecture i386 collect2: error: ld returned 1 exit status make[3]: *** [gcj] Error 1 ld is @(#)PROGRAM:ld PROJECT:ld64-253.6 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS) LTO support using: Apple LLVM 7.0.0 (clang-700.1.76) on Darwin llaima.fritz.box 15.2.0 Darwin Kernel Version 15.2.0: Fri Nov 13 19:43:59 PST 2015; root:xnu-3248.20.55~1/RELEASE_X86_64 x86_64 otool -r shows build/libiberty/make-temp-file.o: Relocation information (__TEXT,__text) 54 entries address pcrel length extern typescattered symbolnum/value [...] 0257 0 0 n/a0 1 0x03c0 which is (with -rv) 0257 False byte n/aVANILLA True 0x03c0 No idea what ld is complaining about here, though. Rainer
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #26 from mrs at gcc dot gnu.org --- Are there any symbols in .text? If so, this is wrong. All symbols have to have 1 or more bytes after them. This is just how the ABI is. The creator of a symbol with no content after is needs to be fixed, if so. gcc_unreablable is one way to zap things so that there is no nop.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #26 from mrs at gcc dot gnu.org --- > Are there any symbols in .text? If so, this is wrong. All symbols have to > have 1 or more bytes after them. This is just how the ABI is. The creator of Not AFAICS: otool -rv has make-temp-file.o: Relocation information (__TEXT,__text) 54 entries address pcrel length extern typescattered symbolnum/value [...] 0257 False byte n/aVANILLA True 0x03c0 which corresponds to this in the disassembly (otool -tv): 0253addb%al,%cl 0255sbbl$0xc3,%esi 0258leal0x02(%esi),%eax In the .s file, we have addb%al, %cl sbbl$3+_vartmp, %esi leal2(%esi), %eax and .zerofill __DATA,__bss2,_memoized_tmpdir,4,2 .const .align 2 _vartmp: .byte 47 [...] So no zero-size symbol in sight. I'm attaching preprocessed input, .s and .o files so you can see for yourself. Rainer
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #28 from Rainer Orth --- Created attachment 36837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36837&action=edit .i/.s/.o for 32-bit link failure
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- I've done some more digging and found that the switch from a gas-derived as in Xcode 6.4 to the LLVM-based one in Xcode 7 caused this: assembling the exact same .s file with both assemblers introduces the difference in relocations causing ld to choke and the 32-bit bootstrap to break. Command line is as -arch i386 -force_cpusubtype_ALL -o make-temp-file.o make-temp-file.s Rainer
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed indeed.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #2 from Stupachenko Evgeny --- (In reply to howarth from comment #0) > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33915 from > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c55 > > for disabling nonlocal goto receiver and fixing setjmp receiver > Committed to trunk r217237.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert --- I'd like to help, but it's such a mess. There is not one PR per distinct issue, but various things reported in long threads. Regarding the first two patches (libcc1 and ipa-chkp.c), they are straightforward and should be approved fast. Don't hesitate to ping them every few days. The "nonlocal goto and setjmp" patch has been committed. But… the remaining patch (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843) does not appear enough to restore bootstrap. I still get: ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostream >-in-std::strstream' for architecture x86_64 is there another patch required?
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #4 from howarth at bromo dot med.uc.edu --- (In reply to Francois-Xavier Coudert from comment #3) > I'd like to help, but it's such a mess. There is not one PR per distinct > issue, but various things reported in long threads. > > Regarding the first two patches (libcc1 and ipa-chkp.c), they are > straightforward and should be approved fast. Don't hesitate to ping them > every few days. > > The "nonlocal goto and setjmp" patch has been committed. > > But… the remaining patch > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843) does not appear > enough to restore bootstrap. I still get: > > ld: illegal text reloc in 'std::strstream::strstream()' to 'construction > vtable for std::basic_ostream > >-in-std::strstream' for architecture x86_64 > > is there another patch required? Did you apply the PA ICF aliasing restriction patch from https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843? Without it, the new ipa-icf pass will erroneously attempt alias creation on targets which don't support (it like MACH-O on darwin). The cryptic "ld: illegal text reloc" error is emitted from the darwin linker because the use of "-undefined dynamic_lookup" masks the fact that undefined symbols result from the inappropriate alias creation. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c12
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #5 from Francois-Xavier Coudert --- (In reply to howarth from comment #4) > Did you apply the PA ICF aliasing restriction patch from > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843? Yes, I have it in my tree. Yet I still get the following error during stage 1 libstdc++ build: ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostream >-in-std::strstream' for architecture x86_64
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #6 from howarth at bromo dot med.uc.edu --- (In reply to Francois-Xavier Coudert from comment #5) > (In reply to howarth from comment #4) > > Did you apply the PA ICF aliasing restriction patch from > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843? > > Yes, I have it in my tree. Yet I still get the following error during stage > 1 libstdc++ build: > > ld: illegal text reloc in 'std::strstream::strstream()' to 'construction > vtable for std::basic_ostream > >-in-std::strstream' for architecture x86_64 What OS X release and Xcode are you on? I am currently testing x86_64-apple-darwin14 with Xcode 6.1 and have access to test on x86_64-apple-darwin13 with Xcode 6.1 and x86_64-apple-darwin12 with Xcode 5.1.1.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #7 from Francois-Xavier Coudert --- (In reply to howarth from comment #6) Sorry, stupid typo on my part in the latest build. Indeed, with the three patches mentioned, my build is proceeding fine.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #8 from howarth at bromo dot med.uc.edu --- Bootstrap tested at r217238 with the remaining uncommitted patches applied using... Configured with: ../gcc-5.0-20141107/configure --prefix=/sw --prefix=/sw/lib/gcc5.0 --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0 on... x86_64-apple-darwin14 against Xcode 6.1 x86_64-apple-darwin13 against Xcode 6.1 x86_64-apple-darwin12 against Xcode 5.1.1
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #9 from howarth at bromo dot med.uc.edu --- (In reply to howarth from comment #8) Successfully bootstrapped with same configure options at same revision on... x86_64-apple-darwin11 against Xcode 4.6
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #10 from howarth at bromo dot med.uc.edu --- Regression testing on x86_64-apple-darwin14 at https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00806.html.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed|2014-11-07 00:00:00 |2014-11-11 --- Comment #11 from Francois-Xavier Coudert --- Current status of trunk: we need one patch [1] to bootstrap, and one more [2] to help with some failures. I have submitted a libtool patch [3], but it doesn't to change things drastically. Latest test results are here: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg01024.html PS: we also have a breakage in libstdc++ (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63811), but Jonathan said on IRC he'll commit a fix asap. [1] https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c3 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c50 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610#c11
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #12 from howarth at bromo dot med.uc.edu --- With the commits of https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00357.html and https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00370.html, the darwin bootstrap should be fully restored on darwin13 and earlier. The patch to fix the configure scripts, generated from the broken libtool.m4, remains to be applied to fix the darwin14 bootstrap.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #13 from Dominique d'Humieres --- There is still a bootstrapping issue with libcc1 when bootstrapping with gcc 4.9: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00731.html
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #14 from Francois-Xavier Coudert ---
(In reply to Dominique d'Humieres from comment #13)
> There is still a bootstrapping issue with libcc1 when bootstrapping with gcc
> 4.9:
Regarding that one, it should be fixed in the top-level Makefile. The targets
that configure and build libcc1 in this Makefile call $(HOST_EXPORTS), which
should do the trick. Instead, it should probably do like lto, and use
$(HOST_EXPORTS) and $(POSTSTAGE1_HOST_EXPORTS) together for stages > 1.
Looking at Makefile.def, the only difference I see is that libcc1 is not
bootstrapped, so maybe we could fix it this way?
Index: Makefile.def
===
--- Makefile.def(revision 217355)
+++ Makefile.def(working copy)
@@ -123,7 +123,8 @@ host_modules= { module= gnattools; };
host_modules= { module= lto-plugin; bootstrap=true;
extra_configure_flags='--enable-shared @extra_linker_plugin_flags@
@extra_linker_plugin_configure_flags@';
extra_make_flags='@extra_linker_plugin_flags@'; };
-host_modules= { module= libcc1; extra_configure_flags=--enable-shared; };
+host_modules= { module= libcc1; bootstrap=true;
+extra_configure_flags=--enable-shared; };
target_modules = { module= libstdc++-v3;
bootstrap=true;
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #15 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #14)
> (In reply to Dominique d'Humieres from comment #13)
> > There is still a bootstrapping issue with libcc1 when bootstrapping with gcc
> > 4.9:
>
> Regarding that one, it should be fixed in the top-level Makefile. The
> targets that configure and build libcc1 in this Makefile call
> $(HOST_EXPORTS), which should do the trick. Instead, it should probably do
> like lto, and use $(HOST_EXPORTS) and $(POSTSTAGE1_HOST_EXPORTS) together
> for stages > 1.
ACK - I think that's completely the right approach to one part of the problem.
- what's happening is that the analysis for the _bootstrap_ compiler's support
of the -static-libstdc++ is being used for the _stage#3_ build of libcc1
for clang [bootstrap] -static-libstdc++ is not supported and thus libcc1 links
with /usr/lib/libstdc++.dylib (which is not really what was intended).
for gcc [bootstrap] the support is mentioned - and then the -static-libstdc++
flag is provided to the libcc1 link (which then fails with…).
… the second issue - which is that we need a -B…. option for each library path
that will be used for spec-substitution (.a for .dylib).
so we need -B/path/to/libstdc++-v3/src/.libs and -B/path/to/libsupc++/.libs,.
>
> Looking at Makefile.def, the only difference I see is that libcc1 is not
> bootstrapped, so maybe we could fix it this way?
>
> Index: Makefile.def
> ===
> --- Makefile.def (revision 217355)
> +++ Makefile.def (working copy)
> @@ -123,7 +123,8 @@ host_modules= { module= gnattools; };
> host_modules= { module= lto-plugin; bootstrap=true;
> extra_configure_flags='--enable-shared
> @extra_linker_plugin_flags@
> @extra_linker_plugin_configure_flags@';
> extra_make_flags='@extra_linker_plugin_flags@'; };
> -host_modules= { module= libcc1; extra_configure_flags=--enable-shared; };
> +host_modules= { module= libcc1; bootstrap=true;
> + extra_configure_flags=--enable-shared; };
>
> target_modules = { module= libstdc++-v3;
> bootstrap=true;
I don't think we want to bootstrap libcc1 (that was what the patch was
removing).
Probably the right example is gnattools - or something similar that only builds
@stage#3.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #16 from Francois-Xavier Coudert --- (In reply to Iain Sandoe from comment #15) > … the second issue - which is that we need a -B…. option for each library > path that will be used for spec-substitution (.a for .dylib) The necessary -B options are already in POSTSTAGE1_HOST_EXPORTS, through POSTSTAGE1_CXX_EXPORT. > I don't think we want to bootstrap libcc1 (that was what the patch was > removing). > > Probably the right example is gnattools - or something similar that only > builds @stage#3. I cannot find anything in the top-level Makefile that builds at stage3 and uses POSTSTAGE1_HOST_EXPORTS, i.e. properly builds with the final compiler. Even gnarls uses HOST_EXPORTS, so it would probably have similar problems. (Doesn't it? I don't know cause I never build ada.)
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #17 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #16) > (In reply to Iain Sandoe from comment #15) > > … the second issue - which is that we need a -B…. option for each library > > path that will be used for spec-substitution (.a for .dylib) > > The necessary -B options are already in POSTSTAGE1_HOST_EXPORTS, through > POSTSTAGE1_CXX_EXPORT. excellent. Jakub asked Paulo on-list if there was a solution to ... > > I don't think we want to bootstrap libcc1 (that was what the patch was > > removing). > > > > Probably the right example is gnattools - or something similar that only > > builds @stage#3. > > I cannot find anything in the top-level Makefile that builds at stage3 and > uses POSTSTAGE1_HOST_EXPORTS, i.e. properly builds with the final compiler. > Even gnarls uses HOST_EXPORTS, so it would probably have similar problems. > (Doesn't it? I don't know cause I never build ada.) … this ^ i.e. choosing the right one to use depending on cross/disable-bootstrap/stage#n … .. gnattools adds the -B options specifically in its Makefile. interesting - so that also implies it will be affected by the bootstrap compiler (although, of course, that pretty much has to be GCC for Ada). I must confess I'd not looked beyond the handling of certain configure options.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 --- Comment #18 from Francois-Xavier Coudert --- (In reply to Iain Sandoe from comment #17) > interesting - so that also implies it will be affected by the bootstrap > compiler (although, of course, that pretty much has to be GCC for Ada). I > must confess I'd not looked beyond the handling of certain configure options. I suspect it's time to involve Paolo indeed. We have reached the limits of my understanding of the GCC build system :)
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
--- Comment #19 from howarth at bromo dot med.uc.edu ---
(In reply to Francois-Xavier Coudert from comment #18)
> (In reply to Iain Sandoe from comment #17)
> > interesting - so that also implies it will be affected by the bootstrap
> > compiler (although, of course, that pretty much has to be GCC for Ada). I
> > must confess I'd not looked beyond the handling of certain configure
> > options.
>
> I suspect it's time to involve Paolo indeed. We have reached the limits of
> my understanding of the GCC build system :)
I wonder if this needs to be done via HOST_LIBS like in the gcc directory. As
far as I can see, everything else linked against libstdc++.a is an executable
from the gcc directory. Adding the usage of HOST_LIBS to the libcc/Makefile.am
would seem to also require the libcc1/configure to also have...
# Libraries to use on the host. This will normally be set by the top
# level Makefile. Here we simply capture the value for our Makefile.
if test -z "${HOST_LIBS+set}"; then
HOST_LIBS=
fi
AC_SUBST(HOST_LIBS)
added as well and configure regenerated.
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Bug 63773 depends on bug 63622, which changed state. Bug 63622 Summary: [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Bug 63773 depends on bug 63534, which changed state. Bug 63534 Summary: [5 Regression] Bootstrap failure on x86_64/i686-linux https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Bug 63773 depends on bug 63703, which changed state. Bug 63703 Summary: [4.9.2/5 Regression] Bootstrap broken on powerpc-apple-darwin, cc1: internal compiler error: in init_reg_sets https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Bug 63773 depends on bug 64023, which changed state. Bug 64023 Summary: [5 Regression] r216964 breaks bootstrap on darwin when using gcc as the bootstrap compiler. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64023 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 Bug 63773 depends on bug 63831, which changed state. Bug 63831 Summary: [5 Regression] r217292 causes segfaults with -MM https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
