Bug 209963
| Summary: | lang/gcc, lang/gcc5 : Fail to build on powerpc64 with GCC 4.2, segmentation fault | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Mathieu Simon <freebsd> | ||||
| Component: | Individual Port(s) | Assignee: | Andreas Tobler <andreast> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | bhs_bsd, gerald, integraldeviation | ||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | powerpc | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
I have confirmed that the lang/gcc (4.8.5_2) build segfaults with FreeBSD 10.3-Release-p5 on a dual G5 (PowerPC 64-bit) when built with GCC 4.2.1 (the PowerPC default) if the MULTILIB option (32-bit and 64-bit) is on. As Mathieu points out, a significant number of ports will cause this to happen. The problem can be avoided by manually building and installing lang/gcc with the MULTILIB option turned off BEFORE building ports that will cause lang/gcc to be built. For some reason, simply doing everything in one pass didn't work for me; gcc needed to be separately built & installed first. Unfortunately, the multilib option is on by default, hence people with 64-bit PowerPCs are finding the issue. I happened to have also turned on the full bootstrap option, but it shouldn't matter. Mathieu mentions GCC 5.0 having a similar problem. I've found GCC 4.9 to also need multilib turned off. Bug report #207331 shows an example of the problem, including an error listing that looked like mine, showing the segfault while building the file libgcc/libgcov.c Andreas, you had USE_GCC=4.9+ added to newer GCC ports, though not lang/gcc itself and this report indicates the issue even happens when building lang/gcc49. Any thoughts? *** Bug 207331 has been marked as a duplicate of this bug. *** I'm working on it. There are several issue with the powerpc64 gcc atm. It'll take a while. Hi Andreas Thanks for you update. So yes, a full bootstrap seemed to give the expected working GCC and compared to building llvm37 (9.5 vs. 13h on my machine) that's still "reasonable". In the meantime I was able to compile som other things successfully. If there is something you are looking for feedback or have a patch to test, drop me a note. I'm more than happy to feed back as much as I can. If the only "proper" workaround is a full boostrap that might be annoying but if the default is giving a working result I'd actually prefer that instead of the current defaults that don't (yet) ;-) -- Mathieu Created attachment 171339 [details]
Patch to enable BOOTSTRAP by default on powerpc64
Thanks for digging into this more!
I am wondering, should we default to BOOTSTRAP for powerpc64, then?
Disabling BOOTSTRAP by default is a shortcut we have employed to save
on build time (and on x86 and x86-64 that has been working pretty well).
However, if that shortcut does not work, best disable it for powerpc64?
Can you confirm that this patch works for you (out of the box), without any local settings? I don't have ppc available to test. Hi all Gerald, let me check but I'd expect it to work from previous results. There one catch: It's only targeted at PPC64. I fear the similar might happen with other Tier-2 architectures and their GCC 4.2. I have posted a patch against lang/jsoncpp in bug #209945 where I worked around another issue with C++11 support (missing in GCC 4.2) by not considering the architecture but checking compiler version instead. What I can propose (however not within the next week) is a Sun v210 with UltraSPARC IIIi's. Optionaly I could also install 32-bit PPC on another Disk on the iMac G5. With the compile times on the G5 I honestly don't want to try this on my other G4 mini ... ;-) Let me know what results you'd like to get. -- Mathieu P.S. I know these are aging exotic architectures and mentioned machines are not of any business value these days but if we can things build on them with a rather small fix that would be nice. :-) Hi Mathieu, thanks for checking! (I want to make sure there is not a typo or other silly mistake I might have made.) And I'd be happy to make a similar change for other Tier-2 architectures, though this is probably better when/if anyone runs into any problem and reports it since bootstrapping take quite a while longer (roughly three times as long) and Tier-2 architectures often are on the slower end. Does this make sense? Hi Gerald - As per documentation the architecture is the same as 'uname -p' which is powerpc64 so your patch should be right - I have removed all make.conf I had - I have tried both with poudriere and plain ports tree + "make rmconfig" to get away with local options. So much about "it should work"....however I think the issue is rather me since logically I don't see why. I'm not certain if 'make config' already checks for the architecture since whatever I tried 'make config' or the equivalent 'poudriere options' command never showed up the options with BOOTSTRAP selected. I'll do a build and see if during that process BOOTSTRAP is enabled on PPC64. If you realize I've made an obvious omission, I'm happy to learn about :-) I'll ping back once the build either completes or fails... -- Mathieu I believe this can be closed now that I have enable BOOTSTRAP for powerpc64 in lang/gcc. Please advise (and reopen) if this is not the case and anything is missing. |
Dear maintainer Since quite many ports depend on lang/gcc to build (i.e many X11 related ones) lang/gcc is therefore built as dependency (I used poudriere) The setup is as follows: 10.3-RELEASE, PowerPC64 (iMac G5), 1.5 GB memory (if that matters), poudriere from ports tree and trying to build parts of X11 which at some point requires lang/gcc. However after some time the lang/gcc always fails with: [...] In file included from /wrkdirs/usr/ports/lang/gcc/work/gcc-4.8.5/libgcc/libgcov.c:41:0: /wrkdirs/usr/ports/lang/gcc/work/gcc-4.8.5/libgcc/../gcc/gcov-io.c: In function '__gcov_read_summary': /wrkdirs/usr/ports/lang/gcc/work/gcc-4.8.5/libgcc/../gcc/gcov-io.h:258:27: internal compiler error: Segmentation fault #define gcov_read_summary __gcov_read_summary ^ /wrkdirs/usr/ports/lang/gcc/work/gcc-4.8.5/libgcc/../gcc/gcov-io.c:520:1: note: in expansion of macro 'gcov_read_summary' gcov_read_summary (struct gcov_summary *summary) ^ no stack trace because unwind library not available [...] The second attempt with was to replace lang/gcc by lang/gcc5 and see if a newer GCC version might work but it also failes with a segmentation fault, although not at the same point: /wrkdirs/usr/ports/lang/gcc/work/gcc-5.3.0/libgcc/libgcov-profiler.c: In function '__gcov_indirect_call_profiler_v2': /wrkdirs/usr/ports/lang/gcc/work/gcc-5.3.0/libgcc/libgcov-profiler.c:287:1: internal compiler error: Segmentation fault __gcov_indirect_call_profiler_v2 (gcov_type value, void* cur_func) ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. Is there anything I could provide to better understand the problem? I imagine it's either related to PowerPC(64) having a dated GCC 4.2.1 in base compared to x86 architectures which ship with more recent LLVM/clang. Thanks, Mathieu