[gentoo-user-de] Update-Problem bei coreutils >= 8.25

[gentoo-user-de] Update-Problem bei coreutils >= 8.25

[Uwe Scholz]

Hallo Leute, ein frohes neues Jahr!

Ich kämpfe gerade mit dem Update von coreutils 8.23 auf 8.25: Die
Installation kann nach der Compiler-Phase nicht beendet werden.
Genau der gleiche Fehler tritt auch beim Emergen von (~)8.26 auf,
daher poste ich unten die Ausgabe von dieser Version.

FEATURES="-distcc" MAKEOPTS="-j3" emerge -1av coreutils

Die Compile-Phase wird hier ohne Fehler durchlaufen. Dann:

>>> Install coreutils-8.26
>>> into /dev/shm/portage/sys-apps/coreutils-8.26/image/ category
>>> sys-apps
make -j3 DESTDIR=/dev/shm/portage/sys-apps/coreutils-8.26/image/
install make  install-recursive
...

Das geht ein paar Zeilen gut bis:

 /bin/mkdir -p '/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/bin'
 /bin/mkdir -p
 '/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/libexec/coreutils'
 src/ginstall -c src/ginstall
 '/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/bin/./install' /bin/sh:
 line 25: 32229 Illegal instruction     src/ginstall -c $files
 "/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/bin$dir"
 Makefile:7571: recipe for target 'install-binPROGRAMS' failed make[3]:
 *** [install-binPROGRAMS] Error 132 make[3]: *** Waiting for
 unfinished jobs.... src/ginstall -c src/libstdbuf.so
 '/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/libexec/coreutils' /bin/mkdir
 -p
 '/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/share/info' /bin/sh:
 line 25: 32235 Illegal instruction     src/ginstall -c $files
 "/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/libexec/coreutils$dir"
 Makefile:7616: recipe for target 'install-pkglibexecPROGRAMS' failed
 make[3]: *** [install-pkglibexecPROGRAMS] Error 132 src/ginstall -c -m
 644 ./doc/coreutils.info
 '/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/share/info' /bin/sh:
 line 21: 32247 Illegal instruction     src/ginstall -c -m 644 $files
 "/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/share/info"
 Makefile:12130: recipe for target 'install-info-am' failed make[3]:
 *** [install-info-am] Error 132 make[3]: Leaving directory
 '/dev/shm/portage/sys-apps/coreutils-8.26/work/coreutils-8.26'
 Makefile:12005: recipe for target 'install-am' failed make[2]: ***
 [install-am] Error 2 make[2]: Leaving directory
 '/dev/shm/portage/sys-apps/coreutils-8.26/work/coreutils-8.26'
 Makefile:11513: recipe for target 'install-recursive' failed make[1]:
 *** [install-recursive] Error 1 make[1]: Leaving directory
 '/dev/shm/portage/sys-apps/coreutils-8.26/work/coreutils-8.26'
 Makefile:11999: die Regel für Ziel „install“ scheiterte make: ***
 [install] Fehler 2


Kann mir einer von euch sagen, was hier los ist? Auf einem erst vor
kurzem von mir aufgesetztem Gentoo lief die 8.25er Installation ohne
Probleme. Scheinbar kommt die Installation da beim Setzen der Pfade
durcheinander, oder? Wegen: "line 25: 32229 Illegal instruction
src/ginstall -c $files
"/dev/shm/portage/sys-apps/coreutils-8.26/image//usr/bin$dir""


emerge --info '=sys-apps/coreutils-8.26::gentoo'
Portage 2.3.0 (python 3.4.5-final-0, default/linux/amd64/13.0/desktop,
gcc-4.9.3, glibc-2.22-r4, 4.4.26-gentoo x86_64)
=================================================================
System Settings
=================================================================
System uname:
Linux-4.4.26-gentoo-x86_64-Intel-R-_Celeron-R-_CPU_847_@_1.10GHz-with-gentoo-2.3
KiB Swap:    4194300 total,   4141324 free Timestamp of repository
gentoo: Sun, 01 Jan 2017 21:00:01 +0000 sh bash 4.3_p48 ld GNU ld
(Gentoo 2.25.1 p1.1) 2.25.1 distcc 3.2rc1 x86_64-pc-linux-gnu [enabled]
ccache version 3.2.4 [enabled]
app-shells/bash:          4.3_p48::gentoo
dev-java/java-config:     2.2.0-r3::gentoo
dev-lang/perl:            5.22.2::gentoo
dev-lang/python:          2.7.12::gentoo, 3.4.5::gentoo
dev-util/ccache:          3.2.4::gentoo
dev-util/cmake:           3.5.2-r1::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.3::gentoo
sys-apps/openrc:          0.22.4::gentoo
sys-apps/sandbox:         2.10-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.12.6::gentoo,
1.14.1::gentoo, 1.15::gentoo sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.9.3::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6-r2::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers)
sys-libs/glibc:           2.22-r4::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

UwesOverlay
    location: /usr/local/portage
    masters: gentoo

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=sandybridge -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=sandybridge -O2 -pipe -fomit-frame-pointer"
DISTDIR="/var/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs candy ccache
config-protect-if-modified distcc distlocks ebuild-locks fixlafiles
merge-sync news parallel-fetch parallel-install preserve-libs
protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs
unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo
http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/"
LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j9 -l2" PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links
--safe-links --perms --times --omit-dir-times --compress --force
--whole-file --delete --stats --human-readable --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--exclude=/.git" PORTAGE_TMPDIR="/dev/shm" USE="64bit X a52 aac aalib
acl acpi aim alsa amd64 ao bash-completion berkdb bluetooth branding
bzip2 cairo calendar cdda cddb cdparanoia cdr cli consolekit corefonts
cracklib crypt cups curl custom-optimization cxx dbus device-mapper dga
dri dts dvd dvdr emacs emboss encode exif extras fam fbcon ffmpeg fftw
firefox flac fontconfig fortran fortune gallium gcj gd gdbm geoip gif
gimp glamor gnuplot gnutls gpg gphoto2 gpm gsl gstreamer gtk gtk3
hddtemp iconv icq id3tag idn imagemagick imap imlib iodbc ipv6 jabber
java javascript jikes jingle jpeg jpeg2k kpathsea lame laptop latex
lcms leim libcaca libnotify libsamplerate libwww lm_sensors logrotate
logwatch mad maildir mcal memlimit mhash mime mmx mmxext mng modules
mozilla mp3 mp4 mpeg mplayer msn mule multilib ncurses netboot
new-login nls nptl odbc ogg openal opengl openmp osc oscar pam pango
pcre pdf plotutils png policykit postscript ppds python python3
qt3support qt5 quicktime readline rss ruby sasl sdl seccomp session
spell sse sse2 sse4 sse4_1 sse4_2 ssl ssse3 startup-notification svg
tcl tcpd tetex theora thinkpad tidy tiff tk truetype udev udisks
unicode upower usb v4l2 vaapi vcd vnc vorbis webkit wifi wmf wxwidgets
x264 xattr xcb xcomposite xml xpm xscreensaver xv xvid xvmc zlib"
ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core
authz_core socache_shmcb unixd actions alias auth_basic authn_alias
authn_anon authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache cgi
cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter
file_cache filter headers include info log_config logio mem_cache mime
mime_magic negotiation rewrite setenvif speling status unique_id
userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan
sheets stage tables krita karbon braindump author" CAMERAS="ptp2"
COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog"
CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 sse4 sse4_1 sse4_2 ssse3"
ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18
garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver
oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip
tripmate tnt ublox ubx" INPUT_DEVICES="synaptics evdev" KERNEL="linux"
L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216
lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console
presenter-minimizer" LINGUAS="de" OFFICE_IMPLEMENTATION="libreoffice"
PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7"
PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby21"
USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock
lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee
tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
USE_PYTHON="3.4" Unset:  CC, CPPFLAGS, CTARGET, CXX,
EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Re: [gentoo-user-de] Update-Problem bei coreutils >= 8.25

[Sven Eden]

[-- Attachment #1: Type: text/plain, Size: 1770 bytes --]

Am Sonntag, 1. Januar 2017, 23:00:11 CET schrieb Uwe Scholz:
> Hallo Leute, ein frohes neues Jahr!

Dir auch ein frohes Neues!

> Ich kämpfe gerade mit dem Update von coreutils 8.23 auf 8.25: Die
> Installation kann nach der Compiler-Phase nicht beendet werden.
> Genau der gleiche Fehler tritt auch beim Emergen von (~)8.26 auf,
> daher poste ich unten die Ausgabe von dieser Version.
(...)
> Portage 2.3.0 (python 3.4.5-final-0, default/linux/amd64/13.0/desktop,
> gcc-4.9.3, glibc-2.22-r4, 4.4.26-gentoo x86_64)

Also den Fehler hatte ich so noch nicht. "Illegal instruction" klingt jetzt 
auch nicht wirklich spaßig.
Bei meinens Systemen hat das mergen von coreutils-8.26 ganz einwandfrei 
funktioniert, und die einzigen beiden Punkte, die ich an deiner emerge --info 
entdecken konnte, die vielleicht (weit hergeholt) etwas damit zu tun haben 
könnte sind die Unterschiede zu meinen Systemen sind gcc und glibc:

 ~ # emerge --info | grep Portage
Portage 2.3.3 (python 2.7.12-final-0, default/linux/amd64/13.0/desktop/plasma, 
gcc-5.4.0, glibc-2.23-r3, 4.8.15-gentoo x86_64)

Ich kann mir beim besten Willen nicht vorstellen, das die coreutils mit 
gcc-4.9 inzwischen ein Problem haben sollen. Aber vielleicht geht es ja um 
eine Änderung zwischen glibc-2.22 und glibc-2.23?

Welche Versionen (gcc/glibc) hast du denn auf dem System, bei dem die 
Installation einwandfrei funktionierte?

Und, mal so in den blauen Dunst hinein, hast du schon versucht den Merge 
"manuell" abzuschließen? Also per
 ~ # ebuild /usr/portage/sys-apps/coreutils/coreutils-8.25.ebuild merge

Wenn es tatsächlich an der glibc liegt, fände ich das bedenklich, denn die 
coreutils-8.25 sind ja als stabil markiert, und glibc-2.23 nicht.

Gruß

Sven
 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[gentoo-user-de] Teilweise gelöst Was: Re: Update-Problem bei coreutils >= 8.25

[Uwe Scholz]

Hallo Sven,

Am Mon, 02 Jan 2017 08:34:24 +0100 schrieb Sven Eden <sven.eden@gmx.de>:
> Bei meinens Systemen hat das mergen von coreutils-8.26 ganz
> einwandfrei funktioniert, und die einzigen beiden Punkte, die ich an

Vielen Dank für deine Antwort.

Aufgrund dieser (und weil auf meinem Zweit-System auch alles glatt
lief), bin ich heute nochmal tief in mich gegangen und da ist mir 
eingefallen, dass vor Weihnachten in der make.conf von

CFLAGS="-O2 -pipe -fomit-frame-pointer"

auf 

CFLAGS="-march=sandybridge -O2 -pipe -fomit-frame-pointer"

umgestellt habe.

Das war des Pudels Kern. Nach Korrektur auf den alten Wert funktioniert
das Emergen der coreutils wieder.

Der Grund meiner ursprünglichen Änderung betrifft eigentlich distcc: Da
im Gentoo-Wiki steht, man solle für das CFLAG "march" einen Wert !=
"native" angeben, wenn man distcc nutzen möchte, habe ich vor kurzem
eben die sandybridge für mein Notebook gewählt. Denn dies ist der Wert,
der mir durch
gcc -c -Q -march=native --help=target | grep "\-march"
ausgespuckt wird. Siehe Wiki-Eintrag hier (*).

(*) https://wiki.gentoo.org/wiki/GCC_optimization#-march

Ich lasse es jetzt vorerst bei der zweiten Variante. Wahrscheinlich
müsste ich beim Ändern der CFLAGS mein ganzes System neu kompilieren
(emerge -e world), damit die Umstellung sauber funktioniert.

Weiß jemand, was passiert, wenn man bei den CFLAGS das march-Flag
einfach weg lässt? Wird das dann automatisch auf das
prozessorspezifische Flag gesetzt - in meinem Fall auf "sandybridge"?

Viele Grüße
Uwe

Re: [gentoo-user-de] Teilweise gelöst Was: Re: Update-Problem bei coreutils >= 8.25

[Martin Wohlert]

Am 02.01.2017 um 22:41 schrieb Uwe Scholz:
> Weiß jemand, was passiert, wenn man bei den CFLAGS das march-Flag
> einfach weg lässt? Wird das dann automatisch auf das
> prozessorspezifische Flag gesetzt - in meinem Fall auf "sandybridge"?

Hallo Uwe!

Das -march Flag sorgt dafür, dass der Compiler binaries erzeugt, die
prozessorspezifische Instruktionen beinhalten können, die dann nur auf
Prozessoren laufen, die diese Instruktionen kennen. Z.B. sowas wie SSE4
Befehle.

Auf allen Prozessoren, die dann SSE4 unterstützen, würde das binary
laufen, aber halt nicht auf Prozessoren, die kein SSE4 kennen.

Wenn du das -march Flag weglässt, dann erzeugt der Compile einfache
binaries ohne derartige Instruktionen, sodass die binaries theoretisch
auf allen Prozessoren (gleicher Architektur) lauffähig sind. Es gibt
natürlich auch Programme, bei denen im Quelltext selbst noch
Inline-Assembler eingebaut ist, wo derartige Instruktionen einhalten
sein können. Dort findet aber in der Regel im Programmcode auch eine
Prüfung der CPU statt bevor derartige Befehle genutzt werden.

Anstatt des -march Flag kannst du auch das -mtune Flag verwenden, damit
bleiben deine binaries auch auf andere Prozessoren lauffähig, können
aber optimierten Code für speziell deine CPU enthalten. Die binaries
sind dadurch natürlich etwas größer.

LG
Martin

Re: [gentoo-user-de] Teilweise gelöst Was: Re: Update-Problem bei coreutils >= 8.25

[Uwe Scholz]

Hallo Martin,

Am Tue, 3 Jan 2017 07:51:04 +0100 schrieb Martin Wohlert
<martin@b-root-force.de>:
> Am 02.01.2017 um 22:41 schrieb Uwe Scholz:
> > Weiß jemand, was passiert, wenn man bei den CFLAGS das march-Flag
> > einfach weg lässt? Wird das dann automatisch auf das
> > prozessorspezifische Flag gesetzt - in meinem Fall auf
> > "sandybridge"?  
> 
> Wenn du das -march Flag weglässt, dann erzeugt der Compile einfache
> binaries ohne derartige Instruktionen, sodass die binaries theoretisch
> auf allen Prozessoren (gleicher Architektur) lauffähig sind. Es gibt
> natürlich auch Programme, bei denen im Quelltext selbst noch
> Inline-Assembler eingebaut ist, wo derartige Instruktionen einhalten
> sein können. Dort findet aber in der Regel im Programmcode auch eine
> Prüfung der CPU statt bevor derartige Befehle genutzt werden.
> 
> Anstatt des -march Flag kannst du auch das -mtune Flag verwenden,
> damit bleiben deine binaries auch auf andere Prozessoren lauffähig,
> können aber optimierten Code für speziell deine CPU enthalten. Die
> binaries sind dadurch natürlich etwas größer.
> 
> LG
> Martin

Vielen Dank für die tolle Erklärung. Das war mir so noch nicht bewusst.

Mit -mtune=sandybridge hat es jetzt auch geklappt. Dann lass' ich das
jetzt so.

Viele Grüße,
Uwe