[solved]emerge of sys-devel/binutils-2.29.1-r1 fails on RPi2

[christoph_peter_s]

Dear Gentoo experts,

I have persistent problems during a recent upgrade, as sys-devel/binutils-2.29.1-r1 fails to compile. The machine is a Raspi 2. To track the issue down, I did first mount a heat sink on the CPU. This did not show any difference. So I switched the hardware to an RPi 3. But now change. I have the impression, that it always crashes at the same place...

[NeddySeagoon]

christoph_peter_s,

There is no error message in your build log fragment. Its at line 2988/3061 of your log.
The log is difficult to read because of all the ANSI escape sequences and the MAKEOPTS="-j3"

If you use wgetpaste to pastebin the log listed in the instructions, it should test be raw text.

I think the error is

[christoph_peter_s]

Hi Neddy,

I'll try to fix the issue with the characterset of my logs. And yes, I did note the error in hashtable.h - but what is the consequence of this? Did I hit a bug - or is it me, doing something silly?

Best regards
Peter

PS: I will run it on 1 core, so there'll be an update in an hour or so. It is a slow little machine... I hope that I can fix the readability of the logs, too. I switched to an ISO locale.

PS2: OK, now with "-j1" - same error. Does not look like a raspi H/W issue to me...
here's what I got in the console window:

[xaviermiller]

Moved from Portage & Programming to Gentoo on ARM.
_________________
Kind regards,
Xavier Miller

[christoph_peter_s]

I'd like to extend my question: is there any chance, that the compilation would succeed, if I'd upgrade to gcc 6.4.0 (which I expect to become an official update for the ARM branch anyway - sooner or later).

TIA
Peter

PS: yes, I could try this - but the raspi is so slow, that I prefer to ask the question first. It's not that I was totally lazy...

[christoph_peter_s]

What I tried in the meantime:
clean all the cached package files (I thought something could have been garbled here) - no success
downgrade sys-libs/binutils-libs to match the version of the installed binutils package - no success
I now mask the 2.29 versions of binutils and binutils-libs and reemerge @system with emptytree. If this doesn't solve the issue either, I was completely stuck. I expect my raspi to work on it for the rest of the day... I hope, as allways, but without much confidence.

Best regards
Peter

[NeddySeagoon]

christoph_peter_s,

No cross distcc ?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[christoph_peter_s]

Hi Neddy,

no, I haven't worked this out so far. So I compile natively on the raspi itself. I have a prejudice, that the native compile is slow but more reliable. Is this incorrect? Besides the slow SD card limits the compilations speed anyway...

Best regards
Peter


Btw: A big thank You for Your work on the 64bit raspi. I got one here, which will make up my next OpenVPN server. I am fully aware, that Your work is the basis for this option.

[christoph_peter_s]

The emerge --emptytree @system failed while building sys-devel/binutils-2.28.1 (the one, which is installed) at exactly the same location.
I did emerge binutils on a RPi1 and did compare the related files (archive.cc backward_warning.h gdb-index.cc gold.h hash_map hashtable.h system.h) - but all are indentical. Then I compared the build log, where there are a few differences - but nothing that would point me to something useful. Anyway, maybe it is more useful for the eye of an expert...

These are the lines from the failed build, which differ from the log from the good machine:

[christoph_peter_s]

Hi there,

the raspi seems to have some issues, too. Maybe the heat sink is too small, don't know exactly. Anyway, the emerge -e @system crashed while compiling gcc (with -j3 option). I switched back to "-j1" and reemerged gcc. Now it looks like it was compiling OK. It definitely made it over the problematic call.

There are only minimal differences in the present build log vs. the log of the failing compile. First there are some differences in whitespace, which I regard as irrelevant. And only a few real differences...

[NeddySeagoon]

christoph_peter_s,

Compiling natively is safe but slow. Not everything cross compiles properly.
I use a USB HDD to avoid building on SD.

I have had a problem with cross distcc and glibc. It builds, then won't boot.
I have no idea why. It seems that not all versions are affected.
cross distcc is great when it works.

gcc with -j3 probably ran out of RAM. Its written in C++ and C++ can require 1G or more to compile in.
Learn to use /etc/portage/env and /etc/portage/package.env so you don't need to remember.
I've seen over 2G swap used with some things in 64 bit.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[christoph_peter_s]

[NeddySeagoon]

christoph_peter_s,

You certainly need a heatsink
You can still run out of RAM even at -j2.

I use -j5 with the exception of

[christoph_peter_s]

Hi Neddy,

just to understand You right... is this just a formal list, or can one put this to some suitable place, where the system picks the corresponding "-jx"?
I use Gentoo since a few years. Just since the moment Debian switched to Systemd, which wrecked my file server... . I feel pretty comfortable with Gentoo nowadays. For me it is the system, which allows anything I want my machines to do... hm, I do disgress. Gentoo for sure had its learning curve. But in the end really everything I wanted, came out well. I hope Gentoo keeps supplying this service forever.
But anyway, Thank You for the list! It will be helpful anyway.

Best regards
Peter

[NeddySeagoon]

christoph_peter_s,

That file is my /etc/portage/package.env file.

MAKEOPTS-j2, MAKEOPTS-j1, nodistcc, are file names in /etc/portage/env/.

/etc/portage/env/MAKEOPTS-j2 contains

[christoph_peter_s]

Thank You for the free extra lessons.

[n05ph3r42]

At least i suggest to change cflags to

[christoph_peter_s]

Thank You n05ph3r42,

I will definitely check the points You raised. Today I upgraded to the PIE profile on my x64 machines. The same procedure is expected for the arm machines at some point in time, too. So I will have it fixed before starting the complete recompilation. And yes, surely I did not spent enough time on the optimization of these machines. But as I said, that upcoming upgrade is a good possibility to fix it. A lot of that mess is still remaining from my first attempts to get Gentoo up and running on the raspi.

Best regards
Peter

[christoph_peter_s]