# I could use some help compiling xorg for my iBook G4



## Superrusso (Oct 1, 2019)

Hello everybody, I'm so thankful you're all here.

I'm trying to compile xorg for this old iBook G4, and I've run into a stumble.  I'm trying to compile llvm90, and I get an error:

/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/config/rs6000/rs6000.md:5933: error: integer constant is too large for 'long' type

I actually get this error when trying to compile a few things to move forward, some mesa-dri...etc...I think this is due to an long int being used that is too long for this PowerPC 32 bit processor?  Anyway, is there a path forward, do I need to change some variables in GCC maybe?  I'd really like to get a window manager going on this thing and see how useful I can make it.  This is a venture with education in mind, so I don't mind if it's a buncha work, but thus far this issue my google fu has failed me.

Again, thanks for any help anybody can lend!


----------



## mark_j (Oct 3, 2019)

Take a look at https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html
You may be right and it's defaulting to 64bit instead of Apple's use of 32 bit CPUs in iBooks.

Also, you might want to include the compiler information, host information and more output about the error (ie, use script to capture make's output) in future. More information helps better than less.


----------



## canardo (Oct 5, 2019)

Hello,

I have the same problem that Superrusso has reported above.
I have install FreeBSD 12.0 powerpc on a Apple Powerbook G4 17"
When trying to install xorg via ports, i get a compilation error


```
/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/config/rs6000/rs6000.md:5933: error: integer constant is too large for 'long' type
```

Please find below some informations regarding the environment, and the full error message.

I'm an absolute newbie on FreeBSD (please be kind), and I don't know much about compiling. I gathered the info I could find.
As proposed above, I had a look on *3.18.44 IBM RS/6000 and PowerPC Options* but I don't really understand it.

Question : how do I find the compiler information ? Is it all in the error message below ?


*Hardware informations*



```
# uname -mrs
FreeBSD 12.0-RELEASE powerpc
```


```
# getconf LONG_BIT
32
```


```
# sysctl -a hw.model
hw.model: Motorola PowerPC 7447A
```


*Full error message*


```
# cd /usr/ports/x11/xorg
# make install clean


===>  Staging for xorg-7.7_3
===>   xorg-7.7_3 depends on file: /usr/local/libdata/pkgconfig/dri.pc - not found
===>   mesa-dri-18.3.2_7 depends on package: wayland-protocols>=1.8 - found
===>   mesa-dri-18.3.2_7 depends on file: /usr/local/libdata/pkgconfig/pthread-stubs.pc - found
===>   mesa-dri-18.3.2_7 depends on executable: bison - found
===>   mesa-dri-18.3.2_7 depends on executable: msgfmt - found
===>   mesa-dri-18.3.2_7 depends on executable: gmake - found
===>   mesa-dri-18.3.2_7 depends on package: pkgconf>=1.3.0_1 - found
===>   mesa-dri-18.3.2_7 depends on file: /usr/local/bin/python3.6 - found
===>   mesa-dri-18.3.2_7 depends on package: llvm80>=3.9.0_4 - not found
===>   llvm80-8.0.1_3 depends on executable: sphinx-build-3.6 - found
===>   llvm80-8.0.1_3 depends on package: py36-recommonmark>=0.0.20180530 - found
===>   llvm80-8.0.1_3 depends on executable: swig3.0 - not found
===>   swig30-3.0.12 depends on executable: gmake - found
===>   swig30-3.0.12 depends on shared library: libpcre.so - not found
===>   pcre-8.43_2 depends on executable: gcc9 - not found
===>  Building for gcc9-9.2.0
gmake[12]: Entering directory '/usr/ports/lang/gcc9/work/.build'
echo stage3 > stage_final
gmake[13]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[14]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build'
rm -f stage_current
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[14]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[14]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/libiberty'
gmake[16]: Entering directory '/usr/ports/lang/gcc9/work/.build/libiberty/testsuite'
gmake[16]: Nothing to be done for 'all'.
gmake[16]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libiberty/testsuite'
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libiberty'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake  all-am
gmake[16]: Entering directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[16]: Leaving directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/intl'
gmake[15]: Nothing to be done for 'all'.
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/intl'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/libiberty'
gmake[16]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/libiberty/testsuite'
gmake[16]: Nothing to be done for 'all'.
gmake[16]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/libiberty/testsuite'
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/libiberty'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/fixincludes'
gmake[15]: Nothing to be done for 'all'.
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/fixincludes'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.0/libcpp'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake  all-am
gmake[16]: Entering directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
true  DO=all multi-do # gmake
gmake[16]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libcpp'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/libdecnumber'
gmake[15]: Nothing to be done for 'all'.
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libdecnumber'
gmake[15]: Entering directory '/usr/ports/lang/gcc9/work/.build/gcc'
c++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC    -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/. -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../include -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libcpp/include -I/usr/local/include  -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libdecnumber -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libbacktrace  -DLIBICONV_PLUG -o insn-emit.o -MT insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.c
/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/config/rs6000/rs6000.md:5933: error: integer constant is too large for 'long' type
gmake[15]: *** [Makefile:1116: insn-emit.o] Error 1
gmake[15]: Leaving directory '/usr/ports/lang/gcc9/work/.build/gcc'
gmake[14]: *** [Makefile:4662: all-stage1-gcc] Error 2
gmake[14]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[13]: *** [Makefile:22474: stage1-bubble] Error 2
gmake[13]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[12]: *** [Makefile:22806: bootstrap-lean] Error 2
gmake[12]: 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[11]: stopped in /usr/ports/lang/gcc9
*** Error code 1

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

Stop.
make[9]: stopped in /usr/ports/devel/pcre
*** Error code 1

Stop.
make[8]: stopped in /usr/ports/devel/pcre
*** Error code 1

Stop.
make[7]: stopped in /usr/ports/devel/swig30
*** Error code 1

Stop.
make[6]: stopped in /usr/ports/devel/swig30
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/devel/llvm80
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/devel/llvm80
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/graphics/mesa-dri
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/graphics/mesa-dri
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11/xorg
*** Error code 1

Stop.
make: stopped in /usr/ports/x11/xorg
```



Thanks a lot for your help.


----------



## mark_j (Oct 6, 2019)

I "think" it's a bug in gcc-9.2.0 port because insn-emit.c is a generated file while building the compiler.

Looking at the command line, there's no *-mcpu=powerpc* or *-mcpu=native* specified. I would have expected something like either of these to be present (unless GCC defaults to what it detects as the CPU architecture).

I think all you could reasonably do is report this to the maintainer of the gcc-9.2.0 port, see:





						FreshPorts -- lang/gcc9: GNU Compiler Collection 9
					

GCC, the GNU Compiler Collection, supports a number of languages. This port installs the C, C++, and Fortran front ends as gcc9, g++9, and gfortran9, respectively.  Gerald Pfeifer <gerald@FreeBSD.org>




					www.freshports.org
				




You could also try to just build gcc9 in ports and see if that emits any more errors (doubtful, but hey, it's better than nothing).

Perhaps try building an earlier version of gcc to see if you can get a functioning GCC?

(It's scary to me that an application depends on a compiler's specific version :
pcre-8.43_2 depends on executable: gcc9 - not found). Depending on any compiler does seem backward, and contrary to why we have so many "standards"... LOL.


----------



## canardo (Oct 10, 2019)

Same error, as expected, when trying to directly compile gcc9.

FYI, gcc8 compiles fine, but xorg definitely asks for gcc9.

A bug already exists in BugZilla for this problem, but has been reported for 12.1-BETA2, so I've added a comment related to 12.0-RELEASE : PR 241125

I don't know if I could/should update the bug title or the version by myself, so I let them as they were.
Maybe someone more "experienced" should do it ?


----------



## D-FENS (Oct 10, 2019)

There was another thread in the forum recently, where they had a similas issue. It turned out different versions of gcc might get mixed up, when installed in parallel. Maybe try to have only one version installed and see if this resolves the problem.
Also, you could upgrade the system to a higher patch level. Yours is 12.0 unpatched.


----------



## canardo (Oct 10, 2019)

My final goal was to install xorg, and while installing it, I bumped on the gcc-9.2.0 problem.
It is only after, that I tried to install gcc-8, so my guess is gcc-9 by itself has a problem.

Indeed, my 12.0 is unpatched. But when I tried to updated it, I got the following error message

*


		Code:
	

freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update4.FreeBSD.org... failed.
Fetching public key from update1.FreeBSD.org... failed.
Fetching public key from update2.FreeBSD.org... failed.
No mirrors remaining, giving up.

*
It is a fresh install, so maybe I have to tweak something in my config. I didn't had time to investigate this error yet.
If you have any suggestions they are very welcome 
Thanks


----------



## mark_j (Oct 11, 2019)

canardo said:


> Same error, as expected, when trying to directly compile gcc9.
> 
> FYI, gcc8 compiles fine, but xorg definitely asks for gcc9.
> 
> ...


Well the compilation of gcc8 was always a 'hail mary'.
As to the bug report, I wouldn't worry. It's been assigned, someone knows the variants are 12R and 12.1b2.


----------



## mark_j (Oct 11, 2019)

roccobaroccoSC said:


> There was another thread in the forum recently, where they had a similas issue. It turned out different versions of gcc might get mixed up, when installed in parallel. Maybe try to have only one version installed and see if this resolves the problem.
> Also, you could upgrade the system to a higher patch level. Yours is 12.0 unpatched.



Patching it now, knowing the bug is still around would be a waste of time, IMHO.


----------



## D-FENS (Oct 11, 2019)

mark_j said:


> Patching it now, knowing the bug is still around would be a waste of time, IMHO.


I did not mean that patching would fix the bug. I meant generally patching would be probably a good idea.


----------



## acheron (Oct 11, 2019)

canardo said:


> Indeed, my 12.0 is unpatched. But when I tried to updated it, I got the following error message
> 
> *
> 
> ...


freebsd-update doesn't work for tier2 arches, it's only for i386/amd64. You can either set up your own server or use the traditionnal make buildworld buildkernel / installworld installkernel.


----------



## acheron (Oct 11, 2019)

The problematic code was added with this commit https://github.com/gcc-mirror/gcc/commit/4b4c309c5ddb4cf08c87fc552d8c85e89de32e14
You can try to change (not tested) : 0xFFFFFFF8FFFFFFFF to 0xFFFFFFF8FFFFFFFFLL


----------



## goosnarrggh (Nov 28, 2019)

acheron said:


> The problematic code was added with this commit https://github.com/gcc-mirror/gcc/commit/4b4c309c5ddb4cf08c87fc552d8c85e89de32e14
> You can try to change (not tested) : 0xFFFFFFF8FFFFFFFF to 0xFFFFFFF8FFFFFFFFLL


And it is patched in trunk: https://github.com/gcc-mirror/gcc/commit/297d694377b6bd379e5cd7b885abed5fc31323e1
It's also been back-ported to the gcc-9 branch: https://github.com/gcc-mirror/gcc/commit/72bbeccc70e7f509d0ff46ba94508eef2381cd02

It seems likely that the patch suggested above has been approved by people who are in a position to know for certain that it is appropriate, and it is reasonable to expect that, eventually, an upstream minor gcc 9.x update will be released which will eliminate the need for a private patch.


----------



## canardo (Dec 1, 2019)

Bugzilla ticket PR 241125 is now Closed FIXED

The FreeBSD version I'm using is
FreeBSD 12.1-RELEASE-p1 powerpc

I've updated ports following the fix, and then compile gcc9.
Problem is I now have another error.
I search on FreeBSD forum, Bugzilla and Google, and did not find the same error.

My questions are:
- does someone else has the same error ?
- should I open a new thread on the forum or stay in this thread ?
- should I create a new bug on Bugzilla ?
- do you know how to fix this problem (maybe I made a mistake..) ?

Thanks a lot


Error is



```
# cd /usr/ports/lang/gcc9
# make install clean
===>  Building for gcc9-9.2.0
gmake[2]: Entering directory '/usr/ports/lang/gcc9/work/.build'
echo stage3 > stage_final
....
....
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libdecnumber'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/gcc'
/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
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
```


----------



## tibikuera (Dec 8, 2019)

canardo said:


> Bugzilla ticket PR 241125 is now Closed FIXED
> 
> The FreeBSD version I'm using is
> FreeBSD 12.1-RELEASE-p1 powerpc
> ...


I have exactly the same error.


----------



## canardo (Dec 8, 2019)

Regarding error 'internal compiler error: Segmentation fault' described above, I've created a new bugzilla ticket  PR 242506.

If you have the same error, I invite you to had comments in the bug, related for example to your hardware/software/config info.


----------



## mark_j (Dec 11, 2019)

Note, this error has been fixed with a patch, attached to  PR 242506


----------



## MarkG108 (Mar 18, 2020)

mark_j said:


> Note, this error has been fixed with a patch, attached to  PR 242506


I have been following this because I too was having difficulties compiling XOrg for an iBook G4.  At one brief point in time, PR 242506 was closed, deemed to have been fixed with a patch which became part of the package, but that is no longer the case.  The bug is still open, and gcc9, in my experience (and I imagine others) fails to compile.


----------



## mark_j (Mar 18, 2020)

Try manually applying the patch Gustavo provided. Canardo's feedback was it worked.





						242506 – lang/gcc9: powerpc: cc1: internal compiler error: Segmentation fault (on FreeBSD 12.1-RELEASE-p1)
					






					bugs.freebsd.org
				



Also, if you have an error, add it to the bug report. At the very least it adds another head count to the problem.


----------



## MarkG108 (Mar 18, 2020)

mark_j said:


> Try manually applying the patch Gustavo provided. Canardo's feedback was it worked.
> 
> 
> 
> ...



Being new to this, I'm not completely sure how to do that.  I tried directly adding the patch contents of Gustavo's post (#3) to the /usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/dumpfile.c, but that failed.  I've also been trying to follow the instructions here, but I find it a bit confusing.


----------



## mark_j (Mar 18, 2020)

That's a handbook for porters, it's sort of relevant but not.
All you need is patch(1), specifically *patch < patchfile*. Make a copy of the relevant file, patch the file and check for errors or a* .rej *file.

Also, this is no criticism, but saying it "just failed" isn't too helpful now, is it? 

Capture the error message (you can use *script* to capture to a file if you like) and post it. I know this can be a chore, but hey, that's open source for you...


----------



## MarkG108 (Mar 19, 2020)

Okay, so again I tried using the the patch contents of Gustavo's post (#3) for gcc9, which I named dumpfile.diff.

```
diff -u dumpfile.c dumpfile.diff > patchtest.diff
patch dumpfile.c < patchtest.diff
```
Seemed to work.  But it still gives  the following when I try to install and/or upgrade it:

```
cc1: internal compiler error: Segmentation fault
```

I dunno.  I likely made an error in my patching effort.


----------



## mark_j (Mar 19, 2020)

patching: If you made an error, it would say so and/or produce a .rej file telling you what it couldn't do. This patch is so trivial in terms of its complexity, I rather doubt you stuffed it up.

Is there any context to this compiler error? Messages before or after it? 
See how canardo displayed the errors:








						I could use some help compiling xorg for my iBook G4
					

Hello everybody, I'm so thankful you're all here.  I'm trying to compile xorg for this old iBook G4, and I've run into a stumble.  I'm trying to compile llvm90, and I get an error:  /usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/config/rs6000/rs6000.md:5933: error: integer constant is too large for...




					forums.freebsd.org
				




This allows people to see it in context.


----------



## MarkG108 (Mar 19, 2020)

```
root@/usr/ports/lang/gcc9 # make install clean
Building for gcc9-9.2.0_1
[..]
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/gcc'
/usr/pports/lang/gcc9/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc9/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -f
cc1: internal compiler error: Segmentation fault
no stack trace because unwind library not avaiilable
Please submit a full bug report,
with prepropcessed 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
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
```


----------



## mark_j (Mar 19, 2020)

You've cut off the entire command line for the compile, but it seems like the same issue canardo had, which was solved by the patch.

You made a copy of the original unpatched source code file, did you not?

In that case, rename it back and do this:

Take this patch:

```
index 7ea8f85..fc17fe9 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -2076,7 +2076,7 @@ temp_dump_context::temp_dump_context (bool forcibly_enable_optinfo,
                                      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)
```

Save the patch as */tmp/dumpfile.c.patch*

Go back to your file location where it's located (in /usr/ports/lang/gcc9/work somewhere) and rename your backup copy of dumpfile.c to dumpfile.c
Stay in that directory.

Now run the following:


```
$ script /tmp/my_log

$ patch -C /tmp/dumpfile.c.patch

$ exit
```

Then post the /tmp/my_log to here.


----------



## MarkG108 (Mar 20, 2020)

Thanks for the suggestion.  Yeah, it's a bit tricky transcribing the code since I'm using two different laptops, that being the iBook G4 (without xwindows) and another one to access this site.

Anyway, I decided to reinstall the system on the iBook G4, and then, without upgrading anything, immediately install llmv80, which if successful, I gather will set the stage for a successful install of xorg.  It's been compiling for hours and is still going now.  
[edit]
Well, that failed..


----------



## MarkG108 (Mar 20, 2020)

mark_j said:


> Save the patch as */tmp/dumpfile.c.patch*
> 
> Go back to your file location where it's located (in /usr/ports/lang/gcc9/work somewhere) and rename your backup copy of dumpfile.c to dumpfile.c
> Stay in that directory.
> ...



Okay, so I did that and I'm now running `patch -C /tmp/dumpfile.c.patch`, but it's frozen.


```
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc # script /tmp/my_log
Script started, output file is /tmp/my_log
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc # patch -C /tmp/dumpfile.c.patch
```
It seems to be still processing it, which is odd.  I'll continue waiting.

[edit]
Well, I waited over thirty minutes, and nothing happened.  I had to press Ctrl-C to stop it.  Here's my_log:

```
Script started on Fri Mar 20 02:36:39 2020
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc # patch -C /tmp/dumpfile.c.patch^M^M
^M
exit^M
^X^CYou have new mail.^M
```


----------



## MarkG108 (Mar 20, 2020)

Well, I went to the patching style I used previously.  I created another script file:

```
Script started on Fri Mar 20 04:07:19 2020
You have mail.
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc # diff -u dumpfile.c /tmp/dumpfile.c.patch > prepatch.diff
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc # patch dumpfile.c < prepatch.diff
Hmm...      Looks like a unified diff to me...
The text leading up to this was:
---------------------------------
|--- dumpfile.c 2019-01-30 02:18:22.000000000 -0500
|*** /tmp/dumpfile.c.patch           2020-03-20 02:26:17.855403000 -0400
---------------------------------
Patching file dumpfile.c using Plan A...
Hunk #1 succeeded at 1.
done^M
```

[edit]
Nuts, I think I got it backwards.  Okay, I renamed "prepatch.diff" to dumpfile.c.  I'll now try to make and install gcc9 (and follow it with a script.)

Okay, here was the feedback:

```
Script started on Fri Mar 20 04:44:27 2020
You have mail.
root@machine1:/usr/ports/lang/gcc9 # make install clean 
===>  Building for gcc9-9.2.0
gmake[2]: Entering directory '/usr/ports/lang/gcc9/work/.build'
echo stage3 > stage_final
gmake[3]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[4]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build'
rm -f stage_current
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[4]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[4]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libiberty'
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/libiberty/testsuite'
gmake[6]: Nothing to be done for 'all'.
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libiberty/testsuite'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libiberty'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake  all-am
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/intl'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/intl'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty'
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty/testsuite'
gmake[6]: Nothing to be done for 'all'.
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty/testsuite'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/fixincludes'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/fixincludes'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libcpp'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake  all-am
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
true  DO=all multi-do # gmake
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libcpp'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libdecnumber'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libdecnumber'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/gcc'
c++ -std=gnu++98 -fno-PIE -c   -g -DIN_GCC    -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/. -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../include -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libcpp/include -I/usr/local/include  -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libdecnumber -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/../libbacktrace  -DLIBICONV_PLUG -o insn-emit.o -MT insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.c
/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc/config/rs6000/rs6000.md:5933: error: integer constant is too large for 'long' type
gmake[5]: *** [Makefile:1116: insn-emit.o] Error 1
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
root@machine1:/usr/ports/lang/gcc9 #
```


----------



## mark_j (Mar 20, 2020)

MarkG108 said:


> Okay, so I did that and I'm now running `patch -C /tmp/dumpfile.c.patch`, but it's frozen.
> 
> 
> ```
> ...



Sorry, I didn't get an email to advise me you'd replied. This forum software's flakey in that regard. 
patch -C *< */tmp/dumpfile.c.patch

That's my mistake. I'm sorry about that. I forgot the redirection... eek.


----------



## mark_j (Mar 20, 2020)

MarkG108 said:


> Thanks for the suggestion.  Yeah, it's a bit tricky transcribing the code since I'm using two different laptops, that being the iBook G4 (without xwindows) and another one to access this site.
> 
> Anyway, I decided to reinstall the system on the iBook G4, and then, without upgrading anything, immediately install llmv80, which if successful, I gather will set the stage for a successful install of xorg.  It's been compiling for hours and is still going now.
> [edit]
> Well, that failed..


I think the problem is that xorg requires gcc, not clang.


----------



## mark_j (Mar 20, 2020)

MarkG108 said:


> Well, I went to the patching style I used previously.  I created another script file:
> 
> ```
> Script started on Fri Mar 20 04:07:19 2020
> ...



Please also collect the output of freebsd-version and uname -a and post it in here. Thanks.


----------



## T-Daemon (Mar 20, 2020)

This morning, reading this thread, I was thinking it must be quit slow building (trying to build) large ports like devel/llvm80 on PowerPc G4. The idea I had was building with ports-mgmt/poudriere on a fast system, with ZFS, devel/ccache and all the trimmings, packages for powerpc. It doesn't help with the current lang/gcc9 problem directly, but maybe indirect it does, see below.

Web searching "_freebsd poudriere powerpc jail_" got me to this recent  mail at the freebsd-ppc@freebsd.org mailing list, title, hold on, "Building powerpc (32-bit) packages on amd64", with howto included. In the following mail from Gustavo Romero is a claim that he was able to "_build of gcc9 on ppc32 G4 and hit_[ting] _a couple of issues which I_ [he] _was able to work around_."!!

I suggest you join the freebsd-ppc@freebsd.org list, and the thread, ask there, eventually ask Gustav Romero directly. Chances are high to get the gcc9 problem resolved, and maybe you find the idea of building packages on a faster system appealing.

If you can resolve the problem on the mailing list, please post your findings.


----------



## mark_j (Mar 20, 2020)

Yes, it's a good thought. I do that with aarch64 stuff and with a quad core and a few spinning rust disks, it takes well over 4 days to compile GCC.
Cross compiling on FreeBSD (unless you have access to some swift systems) is horrible at best.
However, saying all that, it would probably be faster than running it on a 32bit PowerPC which were never that good even when new.


----------



## MarkG108 (Mar 20, 2020)

mark_j said:


> Please also collect the output of freebsd-version and uname -a and post it in here. Thanks.




```
uname -a
FreeBSD machine1.example.com 12.1-RELEASE r354233 GENERIC  powerpc
```


----------



## MarkG108 (Mar 20, 2020)

There's also problems with perl5-5.30.  It fails to upgrade.

```
root@machine1:/usr/ports # portmaster lang/perl5.30  
]0;portmaster: perl5-5.30.0 
===>>> Currently installed version: perl5-5.30.0 
===>>> Port directory: /usr/ports/lang/perl5.30 
 
===>>> Gathering distinfo list for installed ports 
 
===>>> Launching 'make checksum' for lang/perl5.30 in background 
===>>> Gathering dependency list for lang/perl5.30 from ports 
===>>> Initial dependency check complete for lang/perl5.30 
 
]0;portmaster: perl5-5.30.0 
===>>> Starting build for lang/perl5.30 <<<=== 
 
===>>> All dependencies are up to date 
 
===>  Cleaning for perl5-5.30.2 
===>  License ART10 GPLv1+ accepted by the user 
===>   perl5-5.30.2 depends on file: /usr/local/sbin/pkg - found 
===> Fetching all distfiles required by perl5-5.30.2 for building 
===>  Extracting for perl5-5.30.2 
=> SHA256 Checksum OK for perl/perl-5.30.2.tar.xz. 
/bin/ln -s libperl.so.5.30.2 /usr/ports/lang/perl5.30/work/perl-5.30.2/libperl.so 
/bin/ln -s libperl.so.5.30.2 /usr/ports/lang/perl5.30/work/perl-5.30.2/libperl.so.5.30 
===>  Patching for perl5-5.30.2 
===>  Applying FreeBSD patches for perl5-5.30.2 
/usr/bin/sed -i.bak -e 's|/usr/local|/usr/local|g'  /usr/ports/lang/perl5.30/work/perl-5.30.2/Configure /usr/ports/lang/perl5.30/work/perl-5.30.2/hints/freebsd.sh 
===>  Configuring for perl5-5.30.2 
First let's make sure your kit is complete.  Checking... 
Locating common programs... 
Checking compatibility between /bin/echo and builtin echo (if any)... 
Symbolic links are supported. 
Checking how to test for symbolic links... 
You can test for symbolic links with 'test -h'. 
Checking for cross-compile 
No targethost for running compiler tests against defined, running locally 
Good, your tr supports [:lower:] and [:upper:] to convert case. 
Using [:upper:] and [:lower:] to convert case.

[..]

    Making utilities 
../miniperl -I../lib encguess.PL 
Extracting encguess (with variable substitutions) 
../miniperl -I../lib corelist.PL 
Extracting corelist (with variable substitutions) 
../miniperl -I../lib cpan.PL 
Extracting cpan (with variable substitutions) 
../miniperl -I../lib h2ph.PL 
Extracting h2ph (with variable substitutions) 
../miniperl -I../lib h2xs.PL 
Extracting h2xs (with variable substitutions) 
../miniperl -I../lib instmodsh.PL 
Extracting instmodsh (with variable substitutions) 
../miniperl -I../lib json_pp.PL 
Extracting json_pp (with variable substitutions) 
../miniperl -I../lib perlbug.PL 
Extracting perlbug (with variable substitutions) 
../miniperl -I../lib perldoc.PL 
Extracting "perldoc" (with variable substitutions) 
../miniperl -I../lib perlivp.PL 
Extracting perlivp (with variable substitutions) 
../miniperl -I../lib pl2pm.PL 
Extracting pl2pm (with variable substitutions) 
../miniperl -I../lib prove.PL 
Extracting prove (with variable substitutions) 
../miniperl -I../lib ptar.PL 
Extracting ptar (with variable substitutions) 
../miniperl -I../lib ptardiff.PL 
Extracting ptardiff (with variable substitutions) 
../miniperl -I../lib ptargrep.PL 
Extracting ptargrep (with variable substitutions) 
../miniperl -I../lib shasum.PL 
Extracting shasum (with variable substitutions) 
../miniperl -I../lib splain.PL 
Extracting splain (with variable substitutions) 
../miniperl -I../lib libnetcfg.PL 
Extracting libnetcfg (with variable substitutions) 
../miniperl -I../lib piconv.PL 
Extracting piconv (with variable substitutions) 
../miniperl -I../lib enc2xs.PL 
Extracting enc2xs (with variable substitutions) 
../miniperl -I../lib xsubpp.PL 
Extracting xsubpp (with variable substitutions) 
../miniperl -I../lib pod2html.PL 
Extracting pod2html (with variable substitutions) 
../miniperl -I../lib zipdetails.PL 
Extracting zipdetails (with variable substitutions) 
LD_LIBRARY_PATH=/usr/ports/lang/perl5.30/work/perl-5.30.2 ./miniperl -Ilib make_ext.pl lib/auto/Math/BigInt/FastCalc/FastCalc.so  MAKE="/usr/bin/make" LIBPERL_A=libperl.so.5.30.2 LINKTYPE=dynamic 
Generating a Unix-style Makefile 
Writing Makefile for Math::BigInt::FastCalc 
"../../miniperl" "-I../../lib" "../../lib/ExtUtils/xsubpp"  -typemap '/usr/ports/lang/perl5.30/work/perl-5.30.2/cpan/Math-BigInt-FastCalc/../../lib/ExtUtils/typemap'  FastCalc.xs > FastCalc.xsc 
mv FastCalc.xsc FastCalc.c 
Running Mkbootstrap for FastCalc () 
chmod 644 "FastCalc.bs" 
cc -c    -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DUSE_THREAD_SAFE_LOCALE -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_FORTIFY_SOURCE=2 -Wall -Werror=declaration-after-statement -Werror=pointer-arith -Wextra -Wc++-compat -Wwrite-strings -O2 -pipe -fstack-protector-strong -fno-strict-aliasing    -DVERSION=\"0.5008\"  -DXS_VERSION=\"0.5008\" -DPIC -fPIC "-I../.."   FastCalc.c 
/usr/ports/lang/perl5.30/work/perl-5.30.2/cpan/Math-BigInt-FastCalc/../../miniperl "-I../../lib" -MExtUtils::Command::MM -e 'cp_nonempty' -- FastCalc.bs ../../lib/auto/Math/BigInt/FastCalc/FastCalc.bs 644 
rm -f ../../lib/auto/Math/BigInt/FastCalc/FastCalc.so 
cc  -shared  -L/usr/ports/lang/perl5.30/work/perl-5.30.2 -L/usr/local/lib/perl5/5.30/mach/CORE -lperl -L/usr/local/lib -fstack-protector-strong  FastCalc.o  -o ../../lib/auto/Math/BigInt/FastCalc/FastCalc.so         
chmod 755 ../../lib/auto/Math/BigInt/FastCalc/FastCalc.so 
LD_LIBRARY_PATH=/usr/ports/lang/perl5.30/work/perl-5.30.2  ./perl -Ilib -I. -f pod/buildtoc -q 
pod/buildtoc: Perl lib version (5.30.2) doesn't match executable '/usr/ports/lang/perl5.30/work/perl-5.30.2/perl' version (5.30.0) at lib/Config.pm line 62. 
Compilation failed in require at lib/locale.pm line 4. 
BEGIN failed--compilation aborted at lib/locale.pm line 4. 
Compilation failed in require at pod/buildtoc line 10. 
BEGIN failed--compilation aborted at pod/buildtoc line 10. 
*** [pod/perltoc.pod] Error code 255 
 
make[2]: stopped in /usr/ports/lang/perl5.30/work/perl-5.30.2 
1 error 
 
make[2]: stopped in /usr/ports/lang/perl5.30/work/perl-5.30.2 
===> 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/perl5.30 
*** Error code 1 
 
Stop. 
make: stopped in /usr/ports/lang/perl5.30 
 
===>>> make build failed for lang/perl5.30 
===>>> Aborting update 
 
 
===>>> You can restart from the point of failure with this command line: 
       portmaster <flags> lang/perl5.30  
 
This command has been saved to ~/portmasterfail.txt 
 
root@machine1:/usr/ports #
```


----------



## mark_j (Mar 21, 2020)

Did you apply the patch? Is gcc compiling?

As to perl, maybe try `export PERL5LIB=/usr/ports/lang/perl5.30/work/perl-5.30.2` then run it again?
If you're running csh/tcsh then `setenv PERL5LIB /usr/ports/lang/perl5.30/work/perl-5.30.2`
or perhaps:
Is there a packaged version of perl5 or is it a port? For the former remove it, for the later deinstall it then go to /usr/ports/lang/perl5 and make after either exporting or setenv-ing (a new word for today) MAKE_JOBS_UNSAFE=yes


----------



## MarkG108 (Mar 21, 2020)

Regarding perl, the `portmaster -m MAKE_JOBS_UNSAFE=yes` command did work.  The "export" command wasn't even found, and "setenv" command did not work.

Regarding gcc9, the patch did not work.  Here is the log:

```
Script started on Sat Mar 21 13:44:11 2020
You have mail.
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc # patch -C < /tmp/dumpfile.c.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|index 73a8f85..fc17fe9 100644
|--- a/gcc/dumpfile.c
|+++ b/gcc/dumpfile.c
--------------------------
Patching file dumpfile.c using Plan A...
Hunk #1 succeeded at 2055 (offset -21 lines).
done
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0/gcc # cd ..
root@machine1:/usr/ports/lang/gcc9/work/gcc-9.2.0 # cd ..
root@machine1:/usr/ports/lang/gcc9/work # cd ..
root@machine1:/usr/ports/lang/gcc9 # make install clean
===>  Building for gcc9-9.2.0_1
gmake[2]: Entering directory '/usr/ports/lang/gcc9/work/.build'
echo stage3 > stage_final
gmake[3]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[4]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build'
rm -f stage_current
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[4]: Leaving directory '/usr/ports/lang/gcc9/work/.build'
gmake[4]: Entering directory '/usr/ports/lang/gcc9/work/.build'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libiberty'
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/libiberty/testsuite'
gmake[6]: Nothing to be done for 'all'.
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libiberty/testsuite'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libiberty'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake  all-am
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/lto-plugin'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/intl'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/intl'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty'
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty/testsuite'
gmake[6]: Nothing to be done for 'all'.
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty/testsuite'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libiberty'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/fixincludes'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/fixincludes'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/build-powerpc-portbld-freebsd12.1/libcpp'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake  all-am
gmake[6]: Entering directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
true  DO=all multi-do # gmake
gmake[6]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libbacktrace'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libcpp'
test -f config.h || (rm -f stamp-h1 && gmake stamp-h1)
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libcpp'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/libdecnumber'
gmake[5]: Nothing to be done for 'all'.
gmake[5]: Leaving directory '/usr/ports/lang/gcc9/work/.build/libdecnumber'
gmake[5]: Entering directory '/usr/ports/lang/gcc9/work/.build/gcc'
/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
[01m[Kcc1:[m[K [01;31m[Kinternal compiler error: [m[KSegmentation 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
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
root@machine1:/usr/ports/lang/gcc9 # ^Dexit

Script done on Sat Mar 21 13:48:08 2020
```


----------



## MarkG108 (Mar 21, 2020)

I also tried `portmaster -m MAKE_JOBS_UNSAFE=yes` within /usr/ports/lang/gcc9 and that did not work.  It reported a "Segmentation fault".


----------



## acheron (Mar 21, 2020)

Have you patched it after building it? You have to do the reverse, apply the patch and the build it.


----------



## mark_j (Mar 21, 2020)

MarkG108 said:


> I also tried `portmaster -m MAKE_JOBS_UNSAFE=yes` within /usr/ports/lang/gcc9 and that did not work.  It reported a "Segmentation fault".


In /usr/ports/lang/gcc9 can you `make V=1`


----------



## mark_j (Mar 21, 2020)

acheron said:


> Have you patched it after building it? You have to do the reverse, apply the patch and the build it.


Yes it's weird because the patch is reported to fix the problem. Something's not right.


----------



## mark_j (Mar 21, 2020)

MarkG108 said:


> Regarding perl, the `portmaster -m MAKE_JOBS_UNSAFE=yes` command did work.  The "export" command wasn't even found, and "setenv" command did not work.
> 
> Regarding gcc9, the patch did not work.  Here is the log:
> 
> ...


Export/setenv are shell commands not portmaster commands.


----------



## mark_j (Mar 21, 2020)

I just noticed, you're still using -C in the patch command. That was there to test if the patch would apply. You need to remove that and actually apply the patch. The make the port.


----------



## MarkG108 (Mar 22, 2020)

Removing the "-C" from the command seems to have properly patched it.  I'm now building gcc9 (`make install clean`) and it's taking a long time.  That is promising, given that before it would quickly reject the proposition, citing errors.  I'll report later if it succeeds.


----------



## MarkG108 (Mar 23, 2020)

Great news!  gcc9 installed successfully.  Now time to see if llvm80 will also install, and then XOrg.


----------



## MarkG108 (Mar 23, 2020)

I feel like I've gone full circle.  llvm80 fails to install due to issues with python, specifically, it wants python 37, but python 37 won't install due to the presence of python 36.


```
root@machine1:/usr/ports/devel/llvm80 # make install clean  
===>   llvm80-8.0.1_3 depends on executable: sphinx-build-3.7 - not found 
===>   py37-sphinx-1.6.5_2,1 depends on package: py37-Jinja2>=2.3 - not found 
===>   py37-Jinja2-2.10.1 depends on package: py37-setuptools>0 - not found 
===>  Installing for py37-setuptools-44.0.0 
===>  Checking if py37-setuptools is already installed 
===>   Registering installation for py37-setuptools-44.0.0 as automatic 
Installing py37-setuptools-44.0.0... 
pkg-static: py37-setuptools-44.0.0 conflicts with py36-setuptools-41.2.0 (installs files into the same place).  Problematic file: /usr/local/bin/easy_install 
*** Error code 70 
 
Stop. 
make[5]: stopped in /usr/ports/devel/py-setuptools 
*** Error code 1 
 
Stop. 
make[4]: stopped in /usr/ports/devel/py-Jinja2 
*** Error code 1 
 
Stop. 
make[3]: stopped in /usr/ports/devel/py-Jinja2 
*** Error code 1 
 
Stop. 
make[2]: stopped in /usr/ports/textproc/py-sphinx 
*** Error code 1 
 
Stop. 
make[1]: stopped in /usr/ports/devel/llvm80 
*** Error code 1 
 
Stop. 
make: stopped in /usr/ports/devel/llvm80 
root@machine1:/usr/ports/devel/llvm80 #
```


----------



## mark_j (Mar 23, 2020)

Is python 3.6 required?

Yes, I will preempt your question, it is damn stupid that llvm requires python to build.

Edit: I just looked at freshports, it says dependency is python 3.6. What is your default python3 in /etc/make.conf?


----------



## MarkG108 (Mar 23, 2020)

It seems python of some sort is required.  Anyway, just to get it built, I created /etc/make.conf and added:

```
DEFAULT_VERSIONS+=python=3.6
DEFAULT_VERSIONS+=python3=3.6
```
I got this from another post.  Anyway, it does seem to be building now.  I assume this will go on for hours.  So, since it's night time here, I'll sleep on it and see how it turns out in the morning.


----------



## MarkG108 (Mar 23, 2020)

The internet was disconnected, so it stopped installing llvm80.  So, instead, I decided to just try installing X.Org, since the concerns about python seem to be resolved.  I started it this morning and, ten hours later, it's about 19% done.  It's taking forever.

I assume there are no packages for PowerPC due to its Tier Two status, is that right?  I ask simply ask because compiling ports takes such a long time.


----------



## mark_j (Mar 24, 2020)

MarkG108 said:


> The internet was disconnected, so it stopped installing llvm80.  So, instead, I decided to just try installing X.Org, since the concerns about python seem to be resolved.  I started it this morning and, ten hours later, it's about 19% done.  It's taking forever.
> 
> I assume there are no packages for PowerPC due to its Tier Two status, is that right?  I ask simply ask because compiling ports takes such a long time.


Look at http://pkg.freebsd.org/.

Your device is 32 bit so no, no packages.

Your only real alternative is to build packages on an Intel box. This too will be horribly slow (cross-compiling on FreeBSD is atrocious) but faster than compiling on a slow old PowerPC 1.2? GHz machine.

Perhaps you want to look at NetBSD? 


			Index of pub/pkgsrc/packages/NetBSD/macppc/
		

and their FAQ with links to XFree86 stuff:


			NetBSD/macppc Frequently Asked Questions
		


Unfortunately, everything not x86/AMD64 on FreeBSD is a second rate (read: badly supported) citizen. Armv8 might get there soon, but a lot of packages are not built for that platform either.


----------



## MarkG108 (Mar 24, 2020)

Even if NetBSD would be better in the long run, I couldn't figure out the stuff on their site.  Where is the install ISO?  Not there, it seems.  So no, too complicated for me.

I'm quite liking setting up FreeBSD.  Though I think I will surrender if this attempt at XOrg fails.  It currently reads "1252/4888", so, it's like a quarter done.  It's been compiling all day, so, I guess I can expect a few more days, at this rate.


----------



## mark_j (Mar 24, 2020)

Installation procedure for NetBSD/macppc 9.0
		


Yes, sub-Tier 1 NetBSD installs are pretty raw (no img file) but at least they have compiled packages for them.  
Anyway, I better stop spruiking NetBSD on a FreeBSD forum.


----------



## MarkG108 (Mar 24, 2020)

60 hours+ to compile XOrg is a sobering reality (llvm80 being the big dependency).  So, even if successful, it means a future of time consuming upgrades awaits.  Regarding NetBSD, apparently there is an img file, but heaven help anyone who tries to find it on their unintuitive website.  I discovered that here:  http://bgafc.t-hosting.hu/oses4ppc.php

After thirty hours, it's just over halfway done (2580/4888).


----------



## mark_j (Mar 24, 2020)

MarkG108 said:


> 60 hours+ to compile XOrg is a sobering reality (llvm80 being the big dependency).  So, even if successful, it means a future of time consuming upgrades awaits.  Regarding NetBSD, apparently there is an img file, but heaven help anyone who tries to find it on their unintuitive website.  I discovered that here:  http://bgafc.t-hosting.hu/oses4ppc.php
> 
> After thirty hours, it's just over halfway done (2580/4888).


Yes their web site is rather horrid. If you're disinclined to 'get your hands dirty' with an OS then understandably NetBSD won't be for you; but at least it has compiled packages for your platform.   
Short term pain, long term gain.


----------



## MarkG108 (Mar 26, 2020)

Okay, I finally did succeed in compiling and installing xorg unto the iBook G4.


----------



## mark_j (Mar 27, 2020)

For interest's sake how long did it take, roughly?


----------



## MarkG108 (Mar 27, 2020)

Around seventy hours.  llvm80 took the longest time.  Then there were a few others after that needed installing (py-mako, mesa-libs, mesa-dri).  I'm now looking to get Fluxbox going on it.  The installation of Leafpad is taking a while, since various dependencies need to be satisfied (like CUPS).


----------



## canardo (Mar 29, 2020)

Hi,

Regarding Perl5-5.30, I get the same error than MarkG108 (except that my current version is (5.30.1) instead of (5.30.0) for MarkG108).

On my machine, building fails 
- when using portupgrade
- when building with 'make install clean'
=> I've created a PR (I think it should work out of the box) : PR 245163


Regarding compilation time for ports, yes it took aaages for gcc9, llvm80 and xorg, but it worked !

Regarding WM, I tried few of them, but I know almost nothing related to WM config, so I just tried them out of the box. Most troubles I had are probably easy to fix, but I didn't tried, and I'm not planning to try soon.

- fluxbox compiles OK, but has a weird behaviour with my trackpad
- icewm works fine
- dwm works fine
- lxqt crashs and got back ton console
- windowmaker crashs and got back ton console


A while ago, I tried to install xfce, but some dependencies fail to build
I opened a PR for that : PR 243742


----------



## MarkG108 (Mar 29, 2020)

The trackpad didn't work at all in the iBook G4 until I added the following to /etc/rc.conf:

```
moused_enable="YES"
moused_port="/dev/atp0"
```
And yes, in Fluxbox (which I chose to go with) the two-finger tap (Mac version of "right-click") did not give the menu -- instead it only gave the option to change workspaces.  A regular mouse works fine, though, and I'll simply put a menu option on the keybindings.


----------

