Bug 243666 - lang/gcc9: Fails to upgrade 'gcc9-9.2.0' to 'gcc9-9.2.0_1' on FreeBSD 12.1-RELEASE-p1 powerpc 32 bit:Make-lang.in:124: s-selftest-c] Error 1
Summary: lang/gcc9: Fails to upgrade 'gcc9-9.2.0' to 'gcc9-9.2.0_1' on FreeBSD 12.1-RE...
Status: Closed DUPLICATE of bug 242506
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Only Me
Assignee: freebsd-ppc (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-28 10:34 UTC by canardo
Modified: 2020-02-02 21:48 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description canardo 2020-01-28 10:34:07 UTC
Problem found with lang/gcc9 when Upgrading 'gcc9-9.2.0' to 'gcc9-9.2.0_1' on FreeBSD 12.1-RELEASE-p1 powerpc 32 bit, running on Apple Powerbook 17".



/usr/ports/lang/gcc9 # portupgrade gcc9
[Reading data from pkg(8) ... - 1209 packages found - done]
--->  Upgrading 'gcc9-9.2.0' to 'gcc9-9.2.0_1' (lang/gcc9)
--->  Building '/usr/ports/lang/gcc9'
===>  Cleaning for gcc9-9.2.0_1
Making GCC 9.2.0 for powerpc-portbld-freebsd12.1 [c,c++,objc,fortran]
===>  License GPLv3 GPLv3RLE accepted by the user
===>   gcc9-9.2.0_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by gcc9-9.2.0_1 for building
===>  Extracting for gcc9-9.2.0_1
=> SHA256 Checksum OK for gcc-9.2.0.tar.xz.
.....
.....
.....
echo timestamp > gcc.pod
perl /usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../contrib/texi2pod.pl /usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/doc/invoke.texi > gcc.pod
echo timestamp > doc/gcc.1
(pod2man --center="GNU" --release="gcc-9.2.0" --date=2019-08-12 --section=1 gcc.pod > doc/gcc.1.T$$ && \
	mv -f doc/gcc.1.T$$ doc/gcc.1) || \
	(rm -f doc/gcc.1.T$$ && exit 1)
cp doc/gcc.1 doc/g++.1
/usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc9/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
gmake[5]: *** [/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/c/Make-lang.in:124: s-selftest-c] Error 1
rm gcc.pod
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/gcc'
gmake[4]: *** [Makefile:4662: all-stage1-gcc] Error 2
gmake[4]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[3]: *** [Makefile:22474: stage1-bubble] Error 2
gmake[3]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[2]: *** [Makefile:22806: bootstrap-lean] Error 2
gmake[2]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/lang/gcc9
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/gcc9
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20200127-81195-1gwmifv env UPGRADE_TOOL=portupgrade UPGRADE_PORT=gcc9-9.2.0 UPGRADE_PORT_VER=9.2.0 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
	! lang/gcc9 (gcc9-9.2.0)	(segmentation fault)
Comment 1 Gerald Pfeifer freebsd_committer freebsd_triage 2020-01-28 13:04:03 UTC
Can you please disable the PLUGINS option and see whether that makes the
issue go away?

And if it does, can you re-enable the PLUGINS option again and see whether
the issue re-appears?

That is, can you please confirm that it is exactly the PLUGINS option that
makes the difference and that this is "100%" reproducible?
Comment 2 canardo 2020-01-29 16:13:05 UTC
(In reply to Gerald Pfeifer from comment #1)

I'll try to disable the PLUGINS option, but I don't know how to.
Can you please provide me the relevant command lines ?
Comment 3 Walter Schwarzenfeld freebsd_triage 2020-01-29 16:20:13 UTC
make -C /usr/ports/lang/gcc9 config
Comment 4 canardo 2020-01-29 18:35:52 UTC
I performed the following actions:

cd /usr/ports/lang/gcc9
# make clean
===>  Cleaning for gcc9-9.2.0_1
# make -C /usr/ports/lang/gcc9 config

Default was: only BOOTSTRAP selected, GRAPHITE and PLUGINS are unselected.
I left it like that.


/usr/ports/lang/gcc9 # portupgrade gcc9
[Reading data from pkg(8) ... - 1209 packages found - done]
--->  Upgrading 'gcc9-9.2.0' to 'gcc9-9.2.0_1' (lang/gcc9)
--->  Building '/usr/ports/lang/gcc9'
===>  Cleaning for gcc9-9.2.0_1
Making GCC 9.2.0 for powerpc-portbld-freebsd12.1 [c,c++,objc,fortran]
===>  License GPLv3 GPLv3RLE accepted by the user
===>   gcc9-9.2.0_1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by gcc9-9.2.0_1 for building
===>  Extracting for gcc9-9.2.0_1
=> SHA256 Checksum OK for gcc-9.2.0.tar.xz.
.....
.....
.....
cp doc/gcc.1 doc/g++.1
/usr/ports/lang/gcc9/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc9/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/testsuite/selftests
cc1: internal compiler error: Segmentation fault


Same error as before.
Full log is available if you need it.


Could it be related to portupgrade, and not to gcc9 by itself ?
If you want, I can try to first desinstall gcc9 version gcc9-9.2.0, and then to build gcc9 version gcc9-9.2.0_1. Should I try that ? Or something else ?
Comment 5 Steve Peurifoy 2020-01-30 00:05:41 UTC
FWIW, I encountered the same failure doing a port build on an iBook G4 running freshly installed 12.1 with a ports tree fetched yesterday.

In my case, the PLUGINS option WAS set for gcc9 initially. I ran 'make clean', then 'make config' and disabled PLUGINS.

Build still failed the same way.
Comment 6 MikeH 2020-01-31 17:33:54 UTC
Oddly, I too was getting this same seg fault, but only with PLUGINS enabled.
With it disabled I am able to use portmaster without a problem.
12.0-RELEASE-p13
Comment 7 Gerald Pfeifer freebsd_committer freebsd_triage 2020-01-31 17:52:07 UTC
Was this also on powerpc32, Mike?

Could both of you please do another round of testing, with and without
PLUGINS, so that we get a better feel to what extent that option is the
trigger/difference?

powerpc@, can you please help with this?  Once we know whether it really
is dependant on PLUGINS and one of you can perhaps create a backtrace, 
reporting upstream probably is the most promising course of action (unless
you can debug/hack it, of course ;-).
Comment 8 Piotr Kubaj freebsd_committer freebsd_triage 2020-02-02 10:39:23 UTC
(In reply to Gerald Pfeifer from comment #7)
I have built this port successfully on powerpc head and powerpc12.1 with the following patch:
Index: Makefile
===================================================================
--- Makefile    (revision 524472)
+++ Makefile    (working copy)
@@ -69,6 +69,9 @@
 . else
 USE_GCC=       8
 . endif
+
+.elif ${ARCH} == powerpc
+MAKE_JOBS_UNSAFE=      yes
 .endif

 LANGUAGES:=    c,c++,objc,fortran
Index: files/patch-gcc_dumpfile.c
===================================================================
--- files/patch-gcc_dumpfile.c  (nonexistent)
+++ files/patch-gcc_dumpfile.c  (working copy)
@@ -0,0 +1,11 @@
+--- gcc/dumpfile.c.orig        2020-01-31 16:53:37 UTC
++++ gcc/dumpfile.c
+@@ -2055,7 +2055,7 @@ temp_dump_context::temp_dump_context (bool forcibly_en
+                                     bool forcibly_enable_dumping,
+                                     dump_flags_t test_pp_flags)
+ : m_context (),
+-  m_saved (&dump_context ().get ())
++  m_saved (&dump_context::get())
+ {
+   dump_context::s_current = &m_context;
+   if (forcibly_enable_optinfo)

This is with default options.
Comment 9 Gerald Pfeifer freebsd_committer freebsd_triage 2020-02-02 21:18:18 UTC
(In reply to Piotr Kubaj from comment #8)
> I have built this port successfully on powerpc head and powerpc12.1 with
> the following patch:

I have to admit I don't see how this would be fully related.

The patch, in particular, changes what also is in upstream trunk (the
equivalent of FreeBSD's -CURRENT) still. Where did this come from, and
why? If there is an actual issue here, can you please explain it upstream
so that we can get it fixed there?

canardo, is it possible you system is overloaded by the full GCC build
if it happens in parallel - at least sometimes?  May you want to set 
MAKE_JOBS_UNSAFE=yes in your build environment?
Comment 10 Gerald Pfeifer freebsd_committer freebsd_triage 2020-02-02 21:20:18 UTC
...Maybe...

For example, is it possible you run into out-of-memory situations?
Comment 11 canardo 2020-02-02 21:26:08 UTC
I'm currently testing the portupgrade with the patch in comment #8
(I hope I patched correctly, I don't have much experience in that).

Regarding memory, I have 2GB of RAM on the machine.
It is in console, upgrading, and I opened a ssh session in the same time, and run vmstat.
Does it give you relevant information ?

/usr/ports/lang/gcc9 # vmstat
procs  memory       page                    disks     faults         cpu
r b w  avm   fre   flt  re  pi  po    fr   sr ad0 pa0   in    sy    cs us sy id
1 0 0 548M  132M  2131   1   1   0  2074   43   0   0    0  1503   690 47 21 32
Comment 12 Piotr Kubaj freebsd_committer freebsd_triage 2020-02-02 21:34:59 UTC
(In reply to Gerald Pfeifer from comment #9)
This patch is from Gustavo Romero, taken from other bug.

The machine I build on has 96GB RAM. It can build 64 bit GCC9 and some other ports in parallel without sweating.
Comment 13 Gerald Pfeifer freebsd_committer freebsd_triage 2020-02-02 21:48:09 UTC
Thanks, Piotr.  That's why this felt like a deja vu. :-(

*** This bug has been marked as a duplicate of bug 242506 ***