Created attachment 204724 [details]
Building on GCC architectures requires adding CXXFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0" to MAKE_ENV.
/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?
Created attachment 204743 [details]
(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?
(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 . 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.
Does this PR still apply after the psptoolchain-gcc-stage* update ?
A commit references this bug:
Date: Tue Jul 2 08:13:56 UTC 2019
New revision: 505662
devel/psptoolchain-gcc-stage2: fix build with GCC-based architectures
cc1: error: unrecognized command line option "-Wno-reserved-user-defined-literal"
Approved by: mentors (implicit approval)
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