Created attachment 204724 [details] patch Building on GCC architectures requires adding CXXFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0" to MAKE_ENV. Otherwise: /wrkdirs/usr/ports/devel/psptoolchain-gcc-stage2/work/.build/psp/libstdc++-v3/include/ostream:219:43: internal compiler error: Segmentation fault Please submit a full bug report,
Thanks for your PR. Unfortunately, I cannot reproduce the actual problem, can you share some more information about what your build environment is? I guess you mean that your base system is set up to use GCC and not clang? Can you provide the build log file? Thanks
Created attachment 204743 [details] log (In reply to Tassilo Philipp from comment #1) I build ports on powerpc64. It still uses GCC 4.2 in base instead of Clang. Here's a log file attached.
Thanks! Give me a few days to look at it. There are a few things I want to check (correct me if I'm wrong on any point): - from what I see, the segfault happens with a faulty xgcc, itself built by the base gcc 4.2 - your patch looks fine, b/c it won't really matter if the toolchain's gcc is a bit less optimized - however, I want to run some tests still if the psptoolchain produces working psp binaries
Reporter is committer, assign accordingly Note: Build fixes are blanket approval candidates (if this issue is applicable) Approved by: portmgr (blanket: build fix)
I am still investigating on why this broke. I'm currently looking into a change done by antoine as a potential culprit, namely: https://reviews.freebsd.org/rP499897#change-iee5fTGYlh3m I don't think that this changes anything, but want to exclude this first. I am not sure why this was added to begin with, especially with a comment that it doesn't work anyways with gcc < 4.9: In this case that change doesn't make sense for the psptoolchain-newlib and gcc-stage2 ports, as they are intentionally built iwth gcc 4.6. This is just for reference, I'll report back once I know more.
@Piotr: do you remember what you built this port with when you originally submitted the patch for PR 232744 to psptoolchain-gcc-stage1 (which is this port's master port). Also gcc 4.2? Thanks
(In reply to Tassilo Philipp from comment #5) This change doesn't matter, the port didn't build before. I haven't successfully built this port before using change in this PR. It's just that I was busy fixing other ports.
Ok, thanks for the info. So I have some new insight. Scratch my previous comment (5), I misread the comment in the code. This opened a can of worms, though, as the change from antoine I mentioned is indeed problematic. I now understand why this change was made (b/c without the SSP_CFLAGS?= line it won't compile b/c -fstack-protector-strong would be the default), it is wrong to use this for the pspsdk, b/c there is no libssp at all on this platform. So by now building the SDK with this flag (or the default) will break the psptoolchain entirely, as trying to use it in a proect will result in undefined symbols. So, let me fix this first, submit patches for that that keep antoine's logic, but provide the correct flags, then get back to the issue you reported. I'm sorry I didn't spot this before, but those problematic changes were done without checking back with the maintainer and I guess they were more concerned about not breaking port builds.
"Good" news, I can repro the issue when using gcc. I actually can repro this even on the master port (psptoolchain-gcc-stage1) when using gcc 4.8. I'll implement the logic of your patch in the master port's Makefile, so this will then fix both.
I think I found the real culprit leading to this segfault, which is an out of bounds access in the built gcc 4.6.2 (in actually both xgcc and the final psp-gcc), which is fixed in the gcc 4.7 [1]. The fix seems to work for me, not needing the -O0 anymore, and the resulting psp-gcc seems to build correct psp binaries. While investigating it, I noticed that psptoolchain's upstream moved from gcc 4.6.2 to 4.9.3, last year. So, I guess I'll do the same, updating this port to build psp-gcc 4.9.3, which should implicitly fix this issue. I'll prepare the upgrade, make sure it all works, and submit it as a PR once done. I'll keep this PR here open until then. Thanks [1] https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_7-branch/gcc/ira-int.h?r1=191605&r2=191604&pathrev=191605
Does this PR still apply after the psptoolchain-gcc-stage* update ?
A commit references this bug: Author: pkubaj Date: Tue Jul 2 08:13:56 UTC 2019 New revision: 505662 URL: https://svnweb.freebsd.org/changeset/ports/505662 Log: devel/psptoolchain-gcc-stage2: fix build with GCC-based architectures Add USES=compiler:c11: cc1: error: unrecognized command line option "-Wno-reserved-user-defined-literal" PR: 238249 Approved by: mentors (implicit approval) Changes: head/devel/psptoolchain-gcc-stage1/Makefile
stage1 now compiles, but there's an error when compiling stage2: In file included from /wrkdirs/usr/ports/devel/psptoolchain-gcc-stage2/work/gcc-4.9.3/gcc/cp/except.c:1013: cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)' redeclared inline with 'gnu_inline' attribute
thanks for the report, will try to repro
Sorry for the delay. So I tried unsuccessfully to reproduce this error with GCC 4.2 in base (to mimic your environment). With that version it seems to work fine. However, I can repro the exact error you reported when using GCC 6. So, let me ask you first: Is GCC 6 now used in base for powerpc64?
Will work on a patch that makes it work with gcc6 in the meantime
Created attachment 206141 [details] patch to build with gcc >=6 Find attached a patch that adds two new files/patches to the port: devel/psptoolchain-gcc-stage1/files/patch-gcc_cp_cfns.h devel/psptoolchain-gcc-stage1/files/patch-gcc_cp_cfns.gperf This will fix up the incorrectly specified forward declaration in the error you reported, and match the later definition. I tested it with gcc 4.8, gcc 6.5 and clang 6.0.1, they all should build and the resulting psp-gcc also works.
(In reply to Tassilo Philipp from comment #17) No, gcc 4.2 is used in base, but it cannot compile stage1, so I set the port to use gcc from ports (see USES=compiler:*). This means the default gcc from ports is used, which is currently gcc9.
(In reply to Piotr Kubaj from comment #18) Ah, I see, thanks for clarifying. Please let me know if the patch I attached earlier makes it work now.
(In reply to Tassilo Philipp from comment #19) Thanks, this patch indeed works.
A commit references this bug: Author: pkubaj Date: Sun Aug 4 23:12:35 UTC 2019 New revision: 508131 URL: https://svnweb.freebsd.org/changeset/ports/508131 Log: devel/psptoolchain-gcc-stage1: fix build with GCC-based architectures of stage2 PR: 238249 Submitted by: tphilipp@potion-studios.com (maintainer) Approved by: tphilipp@potion-studios.com (maintainer), tcberner (mentor) Differential Revision: https://reviews.freebsd.org/D21118 Changes: head/devel/psptoolchain-gcc-stage1/files/patch-gcc_cp_cfns.gperf head/devel/psptoolchain-gcc-stage1/files/patch-gcc_cp_cfns.h