Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
cross-compiling eix for k6 [WORKAROUND:use gcc<8]
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Sat May 04, 2019 9:39 am    Post subject: cross-compiling eix for k6 [WORKAROUND:use gcc<8] Reply with quote

Hi!

Not sure if this is the right forum but I suspect this is somewhat non-supported, so posting here :)

I have a retro-gaming computer (AMD K6-3) which is dual booting Gentoo just for giggles and maintenance (I dislike Windows 98 and DOS makes things a bit complicated). Compiling anything there is *very* slow. I have a faster box running Gentoo in a 32bit i686 VM. Cross-compiling a Gentoo Kernel in a VM is a breeze, and I have set up a crossdev environment following this guide.

I have compiled a few packages which seem to work, such as cmus, vorbis-tools and mpg123 - however, eix fails with "Illegal instruction". On the retro box:

Code:
ville@RetroMonster ~ $ file $(which cmus)
/usr/bin/cmus: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, stripped
ville@RetroMonster ~ $ file $(which ogg123)
/usr/bin/ogg123: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, stripped
ville@RetroMonster ~ $ file $(which eix)
/usr/bin/eix: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, stripped
ville@RetroMonster ~ $


I've re-created the toolchain once and re-emerged eix, but that didn't fix the eix binary.

Any idea what is wrong? Perhaps the crossdev toolchain is still in some kind of mess? I'd rather spot it now than later, in case I continue with tinkering a retro-installation of Gentoo onto the K6-3 box :lol: . Or, perhaps it is an eix build bug manifesting in a cross-building environment?

On the retro box:

Code:

# emerge --info
Portage 2.3.62 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-8.2.0, glibc-2.28-r6, 4.19.27-gentoo-r1-k6-3-viamvp3-test-3 i586)
=================================================================
System uname: Linux-4.19.27-gentoo-r1-k6-3-viamvp3-test-3-i586-AMD-K6-tm-III_Processor-with-gentoo-2.6
KiB Mem:      767656 total,     82080 free
KiB Swap:    2097148 total,   2095100 free
Timestamp of repository gentoo: Fri, 03 May 2019 06:00:01 +0000
Head commit of repository gentoo: 85dc6d61f79bd4bc0dea9764b0b5b99387f84c1d
sh bash 4.4_p23-r1
ld GNU ld (Gentoo 2.31.1 p5) 2.31.1
distcc 3.3.2 i586-pc-linux-gnu [enabled]
ccache version 3.6 [disabled]
app-shells/bash:          4.4_p23-r1::gentoo
dev-lang/perl:            5.26.2::gentoo
dev-lang/python:          2.7.15::gentoo, 3.6.5::gentoo
dev-util/ccache:          3.6::gentoo
dev-util/cmake:           3.9.6::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.38.3-r1::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.69-r4::gentoo
sys-devel/automake:       1.16.1-r1::gentoo
sys-devel/binutils:       2.30-r4::gentoo, 2.31.1-r4::gentoo
sys-devel/gcc:            8.2.0-r6::gentoo
sys-devel/gcc-config:     2.0::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.28-r6::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts:
    sync-rsync-verify-metamanifest: no
    sync-rsync-verify-jobs: 1
    sync-rsync-verify-max-age: 24

ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i586-pc-linux-gnu"
CFLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer"
CHOST="i586-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -march=k6-3 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="-g"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -march=i486 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg config-protect-if-modified distcc distcc-pump distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -march=i486 -pipe"
GENTOO_MIRRORS="rsync://ftp.fi.muni.cz/pub/linux/gentoo/ rsync://mirror.dkm.cz/gentoo/ rsync://mirror.eu.oneandone.net/gentoo/ rsync://mirror.netcologne.de/gentoo/ rsync://ftp.halifax.rwth-aachen.de/gentoo/ rsync://ftp.fau.de/gentoo rsync://ftp-stud.hs-esslingen.de/gentoo/ rsync://mirror.leaseweb.com/gentoo/ rsync://ftp.snt.utwente.nl/gentoo ftp://mirror.mdfnet.se/gentoo http://mirror.mdfnet.se/gentoo rsync://mirror.bytemark.co.uk/gentoo/"
LANG="fi_FI.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j6 -l0.2"
PKGDIR="/usr/portage/packages"
PORTAGE_BINHOST="ssh://retropkg@ArkkiVille:3333/usr/i586-pc-linux-gnu/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="/var/tmp"
USE="acl alsa bash-completion berkdb bzip2 cddb cdio cli crypt cue curl cxx distcc dri flac fortran gdbm gpm iconv ipv6 libtirpc mad mikmod modplug ncurses nls nptl openmp pam pcre pulseaudio readline seccomp sid ssl tcpd timidity unicode vorbis wavpack x86 xattr zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx 3dnow" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="nouveau" 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"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS



Code:
# cat /etc/portage/make.conf
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
COMMON_FLAGS="-O2 -march=k6-3 -pipe"
CFLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="-O2 -march=i486 -pipe"
FFLAGS="-O2 -march=i486 -pipe"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable before changing.
CHOST="i586-pc-linux-gnu"
CHOST_x86="i586-pc-linux-gnu"

EMERGE_DEFAULT_OPTS="-g"
# NOTE: This stage was built with the bindist Use flag enabled
# These are the USE and USE_EXPAND flags that were used for
# building in addition to what is provided by the profile.
USE="bash-completion distcc ipv6 cddb flac mad mikmod modplug vorbis wavpack curl timidity cdio cue sid alsa gpm pulseaudio"
CPU_FLAGS_X86="mmx 3dnow"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"

VIDEO_CARDS="nouveau"

PORTAGE_BINHOST="ssh://retropkg@ArkkiVille:3333/usr/i586-pc-linux-gnu/packages"

MAKEOPTS="-j6 -l0.2"
FEATURES="buildpkg distcc distcc-pump"
CCACHE_DIR="/gentoo/ccache"
# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C

GENTOO_MIRRORS="rsync://ftp.fi.muni.cz/pub/linux/gentoo/ rsync://mirror.dkm.cz/gentoo/ rsync://mirror.eu.oneandone.net/gentoo/ rsync://mirror.netcologne.de/gentoo/ rsync://ftp.halifax.rwth-aachen.de/gentoo/ rsync://ftp.fau.de/gentoo rsync://ftp-stud.hs-esslingen.de/gentoo/ rsync://mirror.leaseweb.com/gentoo/ rsync://ftp.snt.utwente.nl/gentoo ftp://mirror.mdfnet.se/gentoo http://mirror.mdfnet.se/gentoo rsync://mirror.bytemark.co.uk/gentoo/"


On the build host:

Code:
$ emerge --info
Portage 2.3.62 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-8.2.0, glibc-2.28-r6, 4.19.23-gentoo i686)
=================================================================
System uname: Linux-4.19.23-gentoo-i686-Intel-R-_Core-TM-_i7-4790K_CPU_@_4.00GHz-with-gentoo-2.6
KiB Mem:     4073388 total,    726532 free
KiB Swap:    2097148 total,   2094580 free
Timestamp of repository gentoo: Fri, 03 May 2019 06:00:01 +0000
Head commit of repository gentoo: 85dc6d61f79bd4bc0dea9764b0b5b99387f84c1d
sh bash 4.4_p23-r1
ld GNU ld (Gentoo 2.31.1 p5) 2.31.1
distcc 3.3.2 i686-pc-linux-gnu [disabled]
ccache version 3.6 [enabled]
app-shells/bash:          4.4_p23-r1::gentoo
dev-lang/perl:            5.26.2::gentoo
dev-lang/python:          2.7.15::gentoo, 3.6.5::gentoo
dev-util/ccache:          3.6::gentoo
dev-util/cmake:           3.9.6::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.38.3-r1::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.69-r4::gentoo
sys-devel/automake:       1.16.1-r1::gentoo
sys-devel/binutils:       2.31.1-r4::gentoo
sys-devel/gcc:            8.2.0-r6::gentoo
sys-devel/gcc-config:     2.0::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.28-r6::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-verify-jobs: 1
    sync-rsync-verify-max-age: 24
    sync-rsync-verify-metamanifest: yes
    sync-rsync-extra-opts:

crossdev
    location: /usr/local/portage-crossdev
    masters: gentoo
    priority: 10

ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--jobs 3 --load-average 3.2"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="rsync://ftp.fi.muni.cz/pub/linux/gentoo/ rsync://mirror.dkm.cz/gentoo/ rsync://mirror.eu.oneandone.net/gentoo/ rsync://mirror.netcologne.de/gentoo/ rsync://ftp.halifax.rwth-aachen.de/gentoo/ rsync://ftp.fau.de/gentoo"
LANG="fi_FI.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j8 -l4.2"
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="/var/tmp"
USE="acl bash-completion berkdb bzip2 ccache cli crossdev crypt cxx doc dri fortran gdbm iconv ipv6 libtirpc ncurses nls nptl openmp pam pcre readline seccomp ssl tcpd unicode x86 xattr zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy v4l" 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"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Code:

$ i586-pc-linux-gnu-emerge --info
Portage 2.3.62 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-8.2.0, glibc-2.28-r6, 4.19.23-gentoo i686)
=================================================================
System uname: Linux-4.19.23-gentoo-i686-Intel-R-_Core-TM-_i7-4790K_CPU_@_4.00GHz-with-gentoo-2.6
KiB Mem:     4073388 total,    734108 free
KiB Swap:    2097148 total,   2094580 free
Timestamp of repository gentoo: Fri, 03 May 2019 06:00:01 +0000
Head commit of repository gentoo: 85dc6d61f79bd4bc0dea9764b0b5b99387f84c1d
sh bash 4.4_p23-r1
ld GNU ld (Gentoo 2.31.1 p7) 2.31.1
distcc 3.3.2 i686-pc-linux-gnu [disabled]
ccache version 3.6 [disabled]
app-shells/bash:          4.4_p23-r1::gentoo
dev-lang/perl:            5.26.2::gentoo
dev-lang/python:          2.7.15::gentoo, 3.6.5::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.38.3-r1::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.69-r4::gentoo
sys-devel/automake:       1.16.1-r1::gentoo
sys-devel/binutils:       2.31.1-r4::gentoo
sys-devel/gcc:            8.2.0-r6::gentoo
sys-devel/gcc-config:     2.0::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.28-r6::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-verify-metamanifest: yes
    sync-rsync-verify-max-age: 24
    sync-rsync-extra-opts:
    sync-rsync-verify-jobs: 1

crossdev
    location: /usr/local/portage-crossdev
    masters: gentoo
    priority: 10

ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer"
CHOST="i586-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=k6-3 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--jobs 3 --load-average 3.2"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -march=i486 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news nodoc noinfo noman parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -march=i486 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="fi_FI.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j6 -l3.3"
PKGDIR="/usr/i586-pc-linux-gnu/packages/"
PORTAGE_CONFIGROOT="/usr/i586-pc-linux-gnu/"
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="/usr/i586-pc-linux-gnu/tmp/"
USE="acl alsa bash-completion berkdb bzip2 cddb cdio cli crypt cue curl cxx distcc dri flac fortran gdbm gpm iconv ipv6 libtirpc mad mikmod modplug ncurses nls nptl openmp pam pcre pulseaudio readline seccomp sid ssl tcpd timidity unicode vorbis wavpack x86 xattr zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx 3dnow" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="nouveau" 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"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Code:
$ cat /usr/i586-pc-linux-gnu/etc/portage/make.conf
# Note: profile variables are set/overridden in profile/ files:
# etc/portage/profile/use.force (overrides kernel_* USE variables)
# etc/portage/profile/make.defaults (overrides ARCH, KERNEL, ELIBC variables)

COMMON_FLAGS="-O2 -march=k6-3 -pipe"
CHOST=i586-pc-linux-gnu
CBUILD=i686-pc-linux-gnu

CFLAGS="${COMMON_FLAGS} -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
FCFLAGS="-O2 -march=i486 -pipe"
FFLAGS="-O2 -march=i486 -pipe"


HOSTCC=${CBUILD}-gcc

ROOT=/usr/${CHOST}/

ACCEPT_KEYWORDS="${ARCH}" # ~${ARCH}"

USE="${ARCH} pam bash-completion distcc ipv6 cddb flac mad mikmod modplug vorbis wavpack curl timidity cdio cue sid alsa gpm pulseaudio"

CPU_FLAGS_X86="mmx 3dnow"

VIDEO_CARDS="nouveau"

EMERGE_DEFAULT_OPTS="--jobs 3 --load-average 3.2"
MAKEOPTS="-j6 -l3.3"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=${ROOT}tmp/

PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/portage/local/"

_________________
- Ville


Last edited by ville.aakko on Sun Jun 02, 2019 8:20 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43577
Location: 56N 3W

PostPosted: Sat May 04, 2019 10:23 am    Post subject: Reply with quote

ville.aakko,

The build log for eix, or anything else that breaks would be useful.

You don't need a cross compiler or a 32 bit VM for any of this. Its an unnecessary complication.
A 32 bit chroot will work for building code for the k6-3, however. the code may not run there, so the toolchain and its dependencies must not be rebuilt.

The cross compiler is only required on an amd64 no-multilib install. A multilib system can build 32 bit code. While all that is interesting and could simplify things, what you have should work.

I understand that you have the following setup
a host system (arch unknown)
a i686 Virtual machine
a i586 cross compiler inside the i686 Virtual machine that you would like to use to build k6-3 code.

Its interesting that you have
Code:
CHOST="i586-pc-linux-gnu"
on the retro box. its not wrong, its just hard work to get there, since you need to follow the CHOST changing guide.

On the build host ...
Code:
ccache version 3.6 [enabled]
that breaks things horribly when it returns the wrong code. Turn off ccache and try again.

It the cross environment you have CHOST="i586-pc-linux-gnu" That only affects the toolchain as built in the cross environment.
Cross compiling gcc is a black art. When you do it for a totally different arch, failures are obvious. As this gcc won't be used here, it won't matter but it might be a problem using it on a k6.

Cross compiling is far from perfect. Some things try to build and run build products on the build host. You may not notice that.
Other things suck in build host libraries, you may not notice that until run time.

This sort of thing is definitely supported but most users use cross toolchains for building for a foreign arch, like arm or mips on amd64.
Build time things that break hard there may sneak thorough to be run time errors for you.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3159
Location: Illinois, USA

PostPosted: Sat May 04, 2019 2:54 pm    Post subject: Reply with quote

I do as Neddyseagoon suggested. I have a 32 bit install on a partition on Phenom II machine that I build bin packages for the real k6-3 that has only 500Meg memory and 450Mhz speed. I just finished yesterday updating portage last updated August 2018 so there were the usual blockers and such.

Anyway, enough background. The point is that the CHOST on either machine is NOT CHOST="i586-pc-linux-gnu" but rather CHOST="i486-pc-linux-gnu". I set this up a long time ago and I forget the details. IIRC I had to find a very old stage3 and update it in stages. But my memory may be clouded.
The very important point is that the Pentium i586 has some instructions that the k6 does not share. The k6 is Pentium class but not Pentium compatible. The i486 was the last Intel CPU whose instruction set was a subset of the k6 instruction set. I use a very old sysrescuecd for that reason also.

ASIDE: I'm very interested in an ebuild or build script for the latest sysrescuecd for that reason, so that I can build a k6 code compatible version on the Phenom II.


A VM should work too with the proper CHOST. I use
Code:
CFLAGS="-Os -m32 -march=k6-3 -mtune=k6-3 -pipe"
The mtune may be redundant.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43577
Location: 56N 3W

PostPosted: Sat May 04, 2019 3:09 pm    Post subject: Reply with quote

Tony0945,

In days of old, before amd64 was even released, Gentoo produced an i388 and i686 stage3 tarball.
When glibc-2.3 came along, support for i386 was dropped (forced by glibc) and the stages became i488 and i686
There has never been an official i586 stage3 tarball.

In the days of the stage1 installs, it didn't matter. Part of the setup was setting CHOST, so i586 users would get the i486 stage1 and change the CHOST to i586 as a matter of course.
However, the CHOST is hard coded in bits of the toolchain at build time, so the rebuild order matters.

CHOST does not change the code generated by gcc any way, that depends on CFLAGS. It does change the way that the toolchain is built and what it will run on.

If the toolchain works at all and CHOST has been changed, we can be sure that the the CHOST changing dance has been performed correctly.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Sat May 04, 2019 4:23 pm    Post subject: Reply with quote

Hi NeddySagon!

The installation on the k6-3 box is a bit non-standard. There is the stage3 i486 tarball available, which I could have used. But I thought, in case I want to actually use the Gentoo installation for anything besides file transfers (umm, like some retro-Linux-gaming? Cool retroish mediabox?), every optimization possible might be useful! Well, I was actually not so sure about that, but I decided to go i586 because it just might :roll:

Also, I only learned / thought about chrooting into the installation only after I had already put up the Gentoo installation on the box. But that might be somewhat limiting, as I can not use -march. But using -mtune should not hurt, and make things easier, right?

Of course, that would be a workaround, since what I am doing, should "just work" - and in case I was using some other totally incompatible architectures, that would not be an option.

In any case, why I am in this situation I'm now, is a long story. I was making choices that seemed easiest while going on, and the choices I've made might not have been the most sensible ones. One intermediary step was, that I was trying to use distcc/ccache, but even preprocessing (which can not be distributed, or can be but will fail silently and weird ways, with pump mode) is waaay too slow to be a feasible approach for a very weak box such as this AMD K6-3.[/list] The whole setup is this:

x86_64 Arch Linux (running Intel i7) :
- Virtualbox running
- i686 Gentoo with
- i586-crossdev

You got good points and insights! My comments inline:
NeddySeagoon wrote:

The build log for eix, or anything else that breaks would be useful.


I re-compiled eix by running:
Code:
FEATURES=keepwork i586-pc-linux-gnu-emerge -1 eix


And as far as I can spot, there is nothing obviously wrong in the logs, and things like CXXFLAGS seem to be set correctly .... though I must admit there's quite a lot of information and I'm not sure what to look for.

NeddySeagoon wrote:

You don't need a cross compiler or a 32 bit VM for any of this. Its an unnecessary complication.
A 32 bit chroot will work for building code for the k6-3, however. the code may not run there, so the toolchain and its dependencies must not be rebuilt.


Because I had already decided to go not-just-i486 or i586 (i.e. having -march=k6-3), I figured I might run into problems with chroot, that's why I didn't go that route. However, if things get too complicated, I just might just revert into that, and forget k6-3 specific optimizations (use -mtune instead...).

NeddySeagoon wrote:

The cross compiler is only required on an amd64 no-multilib install. A multilib system can build 32 bit code. While all that is interesting and could simplify things, what you have should work.


I don't know / have no idea, how does one go about building 32-bit code / binary packages for the k6-3 box on a 64-bit, multilib installation?

To re-iterate, my options (from a 64-bit Linux OS) are:
    * chroot into a 32-bit installation, which could be usable on the amd k6-3 installation as-is
    * build 32-bit binaries on a 64-bit multilib installation without chroot

Any pointers (to documentation), how to do the latter?

NeddySeagoon wrote:

I understand that you have the following setup
a host system (arch unknown)
a i686 Virtual machine
a i586 cross compiler inside the i686 Virtual machine that you would like to use to build k6-3 code.

Its interesting that you have
Code:
CHOST="i586-pc-linux-gnu"
on the retro box. its not wrong, its just hard work to get there, since you need to follow the [uurl=https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable]CHOST changing guide[/url].


Yes, I've changed the chost. This was because I fealt i486 is not optimized enough for the K6-3 - not sure that it matters. And that is the exact guide I've looked at.

NeddySeagoon wrote:


On the build host ...
Code:
ccache version 3.6 [enabled]
that breaks things horribly when it returns the wrong code. Turn off ccache and try again.

This is a mistake on my part - I never intended enabling ccache on the build host! I must have mixed up terminal windows while making changes. Thanks for spotting it.

NeddySeagoon wrote:

It the cross environment you have CHOST="i586-pc-linux-gnu" That only affects the toolchain as built in the cross environment.
Cross compiling gcc is a black art. When you do it for a totally different arch, failures are obvious. As this gcc won't be used here, it won't matter but it might be a problem using it on a k6.

The goal is to avoid compiling anything on the k6-3. I have compiled stuff on it - and that's why there's distcc stuff in the configs, and also I had ccache enabled on the target box - k6-3 (the slave box ccache was a mistake). I've disabled it on both since I figured it wont do any good - preprocessing is way too time-consuming even on itself, and I'm not planning on doing repeated re-compiles which would be benefitting from ccache that much.
NeddySeagoon wrote:


Cross compiling is far from perfect. Some things try to build and run build products on the build host. You may not notice that.
Other things suck in build host libraries, you may not notice that until run time.

This sort of thing is definitely supported but most users use cross toolchains for building for a foreign arch, like arm or mips on amd64.
Build time things that break hard there may sneak thorough to be run time errors for you.


Yes, I've noticed - it seems like the crossdev environment is like a house of cards. A simple mistake might make a glitch somewhere, and the build system is not clever enough to notice what is wrong. I've needed to start over once or twice just because of that (once glibc was not installed correctly / failed silently in the crossdev, like missing locales support totally, which broke autotools...)

TL;DR: My choices are:
    * Re-start by creating a i486 (or i586 in case I go stage1 again) without amd k6-3 specific -march, but using -mtune is safe (in CFLAGS, CXXFLAGS), and chroot into that from any Linux (EDIT: which is x86)
    * Fix the issues in the current approach - which seems difficult since I'm not sure where it fails!

_________________
- Ville


Last edited by ville.aakko on Sat May 04, 2019 4:30 pm; edited 1 time in total
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Sat May 04, 2019 4:29 pm    Post subject: Reply with quote

Tony0945 wrote:

The very important point is that the Pentium i586 has some instructions that the k6 does not share. The k6 is Pentium class but not Pentium compatible. The i486 was the last Intel CPU whose instruction set was a subset of the k6 instruction set. I use a very old sysrescuecd for that reason also.

I think you are in the right direction *but* you have mixed up i686/i586. AMD K6-3 is almost i686, but not quite. i686 basically started with Pentium Pro. AMD K6-2 (and equivalents) are certainly i586, and more.

More specifically, I believe it is missing the CMOV instruction. Confusions arise from what AMD K6-2/3 was competing with when it was contemporary
_________________
- Ville
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3159
Location: Illinois, USA

PostPosted: Sat May 04, 2019 5:11 pm    Post subject: Reply with quote

ville.aakko wrote:
AMD K6-3 is almost i686, but not quite.

Definitely true, which is why I have to use a very old sysrescuecd. Later versions bomb out on 32 bit with "illegal instruction".
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43577
Location: 56N 3W

PostPosted: Sat May 04, 2019 5:31 pm    Post subject: Reply with quote

ville.aakko,

Lets talk about the 32 bit chroot on an amd64 multilib. Multilib is important. The host has to run the 32 bit code in the chroot.
Some of it anyway. The "some of it is" important, as it will let use use -march=k6-3

When you download the i486 stage3, its all built for a 486DX, if the FPU matters. You can do
Code:
linux32 chroot /mnt/i486 /bin/bash
and all will be well.
As you say, you can use -mtune=k6-3 and nothing breaks but that's suboptimal.

The key to using -march=k6-3 is to not reinstall any packages into the chroot built with -march=k6-3.
Lets emphasise the reinstall. Building packages with -march=k6-3 is fine.

So
Code:
emerge -eB @system
will build the system set without installing anything but will make packages with -march=k6-3 for you.
For anything other than the system set, its OK to install them too because you don't want to run them in the chroot.

If you do want to upgrade the system set, its tiring to remember to switch -march= ... one day you will forget.
Portage can manage this for you. Its all at Working with Portage but that will make your eyes glaze over. Keep that as a reference and start reading at
Introduction. The first few paragraphs explain about per package CFLAGS.
This allows you to have the best of both worlds
    -march=k6-3 in make.conf
    Per package CFLAGS as generics that override make.conf to protect the system set, so you can keep it generic to avoid breaking the chroot.
    Command line CFLAGS to override the per package make.conf overrides, so you can build but not install packages for -march=k6-3

I'm sure a few evil packages will still break.

-- edit --
You can even arrange for the per package overrides to not save package files, so you don't get generics on the k6-3
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Sat May 04, 2019 7:37 pm    Post subject: Reply with quote

Hi again NeddySagon,

I believe the chroot option is the way to go.

I just thought that messing around with the incompatibilities of the -march are too much of a hassle. But you gave the pointers how to manage them :)

I believe I will just have another chrooted Gentoo installation which will make binary packages for the k6-3 box. Much more simple, and I will not need the VM anymore! (other option being to chroot directly onto the k6-3 box, but considering all things, another build-slave chroot makes more sense - one benefit is that the k6-3 does not need to be online while compiling packages...)

The Arch installation I already have is already multilib. Gaming requires that, as many are 32 bit.... already chrooted into the i486 chroot (and if I like, I will make it i586).

Thanks!
_________________
- Ville
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4213
Location: Dallas area

PostPosted: Sat May 04, 2019 7:57 pm    Post subject: Reply with quote

ville.aakko wrote:
Tony0945 wrote:

The very important point is that the Pentium i586 has some instructions that the k6 does not share. The k6 is Pentium class but not Pentium compatible. The i486 was the last Intel CPU whose instruction set was a subset of the k6 instruction set. I use a very old sysrescuecd for that reason also.

I think you are in the right direction *but* you have mixed up i686/i586. AMD K6-3 is almost i686, but not quite. i686 basically started with Pentium Pro. AMD K6-2 (and equivalents) are certainly i586, and more.

More specifically, I believe it is missing the CMOV instruction. Confusions arise from what AMD K6-2/3 was competing with when it was contemporary


Code:
i386     –     Intel i386/80386   (in 1985)          or          AMD386 / AM386 (in 1991)

i486     –     Intel i486/80486   (in 1989)          or          AMD486 / AM486 (in 1993)

i586     –     Intel Pentium         (in 1993)          or          AMD-K5 (in 1996)

i686     –     Intel Pentium Pro (in 1995)          or          AMD-K6 (in 1997)

i786     –     Intel Pentium 4      (in 2000)          or          AMD-K7 (in 1999)


Quote:
i586
Intel i586 was released in 1993. It was brand named Pentium. Also called P5, meant to be the 5th generation of x86 micro-architecture. In 1996, Pentium MMX was released based on this processor. It added new MMX instructions.
Read more about Intel i586 here

AMD K5 was released in 1996. It was AMD’s first x86 processor to be developed entirely in-house.
The K5 lacked MMX instructions, which Intel had started giving with this genre.
Read more about AMD K5 here

NOTE: Packages that are compiled for i586 architecture, are compatible with i586, i686 & i786 architectures.


i686
Intel i686 was released in 1995. It was brand named Pentium Pro. Also called P6, meant to be the 6th generation of x86 micro-architecture.
Read more about Intel i686 here

AMD K6 was released in 1997. It included MMX instructions and an FPU.
It was complemented by AMD K6-2 in 1998, which introduced AMD’s 3D-Now!
AMD released AMD K6-III was released in1999
Read more about AMD K6 here

NOTE:Packages that are compiled for i686 architecture, is compatible with i686 & i786 architectures.


https://myonlineusb.wordpress.com/2011/06/08/what-is-the-difference-between-i386-i486-i586-i686-i786/


ETA:
Quote:
Basically, they are broken down as follows:
386: obvious, barebones, compatible with everything
486: uses some 486 instructions, optimized for 486 processors.
586: uses some new instructions introduced with the Pentium and make use of the TSC (time stamp counter)... Pentium [MMX], AMD K5/K6[-2|-III], Cyrix 6x86[MX], MII, Via C3 (Ezra and earlier, which lack one 686 instruction)
686: 586 with more enhancements, some new instructions (but not MMX apparently, since PPro lacks MMX)... PPro, PII, PIII, P4, Celeron, AMD K7/XP/MP/Duron, Via C3 (Nehemiah)

Processors with MMX: Pentium MMX, PII, PIII, P4, Celeron, K6, K7, Athlon XP, Athlon 64, 6x86 MX, C3
Processors with SSE: PIII, P4, Athlon XP, C3(Nehemiah)
Processors with SSE2: P4, Athlon64/Opteron
Processors with 3DNow: K6-2/K6-III, K7, AXP, C3(Ezra)

I know at one point during the 2.0.x and 2.1.x days (I think) the AMD K6 was considered a 686 processor, but they later bumped it down to 586. Not sure why; probably it lacked some feature they decided to require for 686.

Note that when you compile your own kernel you select your specific processor, not just a family, so for example a PIII kernel may add some SSE and MMX optimizations not found in the generic 686 kernel, similarly with Athlon XP vs. Athlon K7.

_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Mon May 06, 2019 5:28 pm    Post subject: Reply with quote

Veering a bit off course from the original headline, but seems like the core symptom - eix being not runnable - is still not resolved.

I can not compile a working eix even in a 32bit chroot! However, that is the only package which seems to generate wrong kind of binary (but I haven't emerged that many packages yet).

I noticed I had not set -fomit-frame-pointer in CXXFLAGS on the k6-3 box, but the build box did have that set. However, I think it should not cause this kind of failure?

I can emerge eix on the k6-3 box locally - which would of course work around the issue. however, why does the error happen on the build host, and will it happen again, is unresolved!

Any ideas? I'm currently making another compile run on both the k6-3 box and the build slave with FEATURES="keepwork", and compare the environments. EDIT: Reading this page, I've realized I got some more sensible alternatives, to look into the actual packages[/url]...

Also, thinking about firing up gdb and try to see what is going on, but I'm very novice when it comes to gdb...
_________________
- Ville
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43577
Location: 56N 3W

PostPosted: Mon May 06, 2019 6:04 pm    Post subject: Reply with quote

ville.aakko,

What does
Code:
lddtree /usr/bin/eix
tell about required libraries?
When eix crashes, what does it leave at the end of dmesg?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Tue May 07, 2019 8:07 am    Post subject: Reply with quote

Well:

Code:
# lddtree $(which eix)
eix => /usr/bin/eix (interpreter => /lib/ld-linux.so.2)
    libstdc++.so.6 => /usr/lib/gcc/i586-pc-linux-gnu/8.2.0/libstdc++.so.6
        libm.so.6 => /lib/libm.so.6
        ld-linux.so.2 => /lib/ld-linux.so.2
    libgcc_s.so.1 => /usr/lib/gcc/i586-pc-linux-gnu/8.2.0/libgcc_s.so.1
    libc.so.6 => /lib/libc.so.6


That paste is from the binary causing illegal instruction (compiled on the slave). Seems right to me, and the output from the locally compile (emerge -B --usepkg-exclude eix - since I already got eix in packages) is identical.

In syslog invalid opcode messages appear:

Code:
May  6 08:36:45 RetroMonster kernel: [76774.184555] traps: eix[14915] trap invalid opcode ip:444220 sp:bfa5d2ec error:0 in eix[427000+124000]
May  6 09:06:32 RetroMonster kernel: [ 1040.421749] traps: eix[2584] trap invalid opcode ip:46b220 sp:bf94feec error:0 in eix[44e000+124000]
May  6 13:17:02 RetroMonster kernel: [16070.622047] traps: eix[8759] trap invalid opcode ip:45a220 sp:bfeee74c error:0 in eix[43d000+124000]
May  6 13:19:48 RetroMonster kernel: [16236.239120] traps: eix[9092] trap invalid opcode ip:42a220 sp:bf9d560c error:0 in eix[40d000+124000]
May  6 14:24:04 RetroMonster kernel: [20092.924930] traps: eix[16216] trap invalid opcode ip:4f8220 sp:bf9d0a4c error:0 in eix[4db000+124000]
May  6 14:57:02 RetroMonster kernel: [22070.213245] traps: eix[22794] trap invalid opcode ip:45c220 sp:bf94689c error:0 in eix[43f000+124000]
May  6 15:11:23 RetroMonster kernel: [22931.547364] traps: eix[25190] trap invalid opcode ip:508220 sp:bfb42a2c error:0 in eix[4eb000+124000]
May  6 15:16:06 RetroMonster kernel: [23214.149848] traps: eix[26270] trap invalid opcode ip:473220 sp:bf9de56c error:0 in eix[456000+124000]
May  6 15:44:40 RetroMonster kernel: [24928.121987] traps: eix[31174] trap invalid opcode ip:4cd220 sp:bfb82cec error:0 in eix[4b0000+124000]
May  6 15:44:59 RetroMonster kernel: [24947.255818] traps: eix[31175] trap invalid opcode ip:4ee220 sp:bf9b67ac error:0 in eix[4d1000+124000]
May  6 16:27:06 RetroMonster kernel: [27474.525436] traps: eix[31223] trap invalid opcode ip:50f220 sp:bf9b536c error:0 in eix[4f2000+124000]
May  6 18:57:01 RetroMonster kernel: [36469.690246] traps: eix[4270] trap invalid opcode ip:43f220 sp:bfaf943c error:0 in eix[422000+124000]
May  6 19:39:25 RetroMonster kernel: [39013.388582] traps: eix[4290] trap invalid opcode ip:4c3220 sp:bfb531dc error:0 in eix[4a6000+124000]
May  6 19:43:54 RetroMonster kernel: [39282.302914] traps: eix[5103] trap invalid opcode ip:4c2220 sp:bf84cbec error:0 in eix[4a5000+124000]
May  6 19:45:10 RetroMonster kernel: [39358.642144] traps: eix[5370] trap invalid opcode ip:4c5220 sp:bfe3bdcc error:0 in eix[4a8000+124000]
May  6 19:45:20 RetroMonster kernel: [39368.219827] traps: eix-diff[5405] trap invalid opcode ip:4b8220 sp:bfdfc47c error:0 in eix[49b000+124000]
May  6 21:05:19 RetroMonster kernel: [44167.733952] traps: eix[7333] trap invalid opcode ip:44b220 sp:bfc155ec error:0 in eix[42e000+124000]
May  6 21:08:27 RetroMonster kernel: [   82.504042] traps: eix[2603] trap invalid opcode ip:44d220 sp:bfa38d6c error:0 in eix[430000+124000]
May  6 21:09:21 RetroMonster kernel: [  136.904001] traps: eix[2626] trap invalid opcode ip:4d9220 sp:bfde488c error:0 in eix[4bc000+124000]
May  6 21:14:23 RetroMonster kernel: [  438.338478] traps: eix[3210] trap invalid opcode ip:510220 sp:bfd24d7c error:0 in eix[4f3000+124000]
May  6 21:14:38 RetroMonster kernel: [  453.312491] traps: eix[3243] trap invalid opcode ip:467220 sp:bfa0f16c error:0 in eix[44a000+124000]
May  6 21:14:44 RetroMonster kernel: [  459.212513] traps: eix[3278] trap invalid opcode ip:431220 sp:bfec65ec error:0 in eix[414000+124000]
May  6 21:18:05 RetroMonster kernel: [  660.515728] traps: eix[3609] trap invalid opcode ip:4db220 sp:bfd4a59c error:0 in eix[4be000+124000]
May  6 22:26:26 RetroMonster kernel: [ 4762.034067] traps: eix[9606] trap invalid opcode ip:448220 sp:bfb2063c error:0 in eix[42b000+124000]
May  6 22:26:46 RetroMonster kernel: [ 4781.257065] traps: eix[9609] trap invalid opcode ip:461220 sp:bf93f85c error:0 in eix[444000+124000]
May  7 10:54:04 RetroMonster kernel: [ 2625.944945] traps: eix[3156] trap invalid opcode ip:4ad220 sp:bfc75bcc error:0 in eix[490000+124000]


Nothing suprising here; though I must admit I have no idea what the numbers mean, or even if they are useful information in this case - and couldn't find a reference via a quick google search. These are all not necessarily from the exact same binary, did a emerge -1 eix on the binhost and refetched the binary (--rebuilt-binaries) at least once.
_________________
- Ville
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43577
Location: 56N 3W

PostPosted: Tue May 07, 2019 9:02 am    Post subject: Reply with quote

ville.aakko,

Code:
May  6 08:36:45 RetroMonster
Calendar date, time and hostname.
Code:
kernel: [76774.184555]
kernel uptime.
Code:
traps: eix[14915]
offending program and process ID.
Code:
ip:444220 sp:bfa5d2ec
Instruction pointer and stack pointer.

Given a memory map for eix, ip:444220 will pinpoint the function that failed but I'm not sure how that would help, since examining the code for that function would tell you what you already know. You have an illegal instruction. It would tell what the instruction is but not how it got there.

lddtree shows the libraries in use. Mostly glibc and gcc. Lots of things use them, so we can probably rule them out.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Wed May 08, 2019 11:59 am    Post subject: Reply with quote

Ok, a bit more (perhaps useful?) information. I have no idea if I'm on the right track or no - I'm not any sort of programmer and don't know how to use gdb :D .

Anyways, the theory I have is that something is off with the chroot environment. Either something in /proc, or /sys (I'm chrooting from a multilib Arch installation) or some setting is making the toolchain in the chroot to trip over itself.

I noticed I had not
    * set locale on the build slave chroot
    * set timezone on the build slave chroot


The first I noticed by comparing the environments from the working binary package (compiled locally on the k6-3) to the one build in the slave chroot (on the i7 machine running Arch).

I actually noticed the missing timezone information only after I installed gdb and recompiled eix with debugging information on the slave. Gdb tells me the function where it breaks down:

Code:
# gdb eix
runGNU gdb (Gentoo 8.1 p1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from eix...
Reading symbols from /usr/lib/debug//usr/bin/eix.debug...done.
done.
(gdb) run
Starting program: /usr/bin/eix

Program received signal SIGILL, Illegal instruction.
_GLOBAL__sub_I_spaces () at eixTk/stringutils.cc:645
645     }
(gdb)
/usr/src/debug/app-portage/eix-0.33.7/eix-0.33.7/src/eixTk/stringutils.cc


But this is as far I can use gdb at the moment. And the rest of the system is not recompiled with FEATURES="nostrip".

However, from stringutils.cc I can see line:645 is this string::size_type utf8size - and then I noticed from the header that it uses heavily ATTRIBUTE_PURE, which is defined in glibc timezone/private.h (which probably gets included trough something, which is trivial to check somehow, but I don't know how... cstdlib?)

And then it occurred to check timezone settings, and it was not set (on the built slave chroot). Did echo "Europe/Helsinki" > /etc/timezone and emerge --config sys-libs/timezone-data, verified TZ is correctly set, re-emerged the eix on the host and... still: "illegal instruction".

Whatever the case, I don't think things should fail because of timezone not being set - and that could definitely be a red herring, it could fail because of something totally unrelated. Currently, I'm trying to shoot with a shotgun and I'm recompiling the toolchain and after that, eix yet again.
_________________
- Ville
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3159
Location: Illinois, USA

PostPosted: Wed May 08, 2019 2:10 pm    Post subject: Reply with quote

One problem I found with building in a chroot was forgetting linux32 and chrooting in as 64 bit and polluting the environment by building inadvertently as 64 bit.
That is why I recommended a 32 bit partition booted through grub as I do now. Another possibility is a 32 bit virtual machine. I have a virtual 32 bit Windows XP running on 64 bit Gentoo.
OTOH, since the CPU is 64 bit, the build host won't choke if it encounters a 64 bit instruction.

Another thing that will cause an illegal instruction (and I am a programmer) is an incorrectly calculated offset causing a miscalculated pointer. It's not a good practice but some code calculates a pointer by adding an offset based on size which will be smaller (generally) on 32 bit. I'm not saying there is code like this in eix or a library, but there might be. In that case the error would also occur in 32-bit eix/python.

If you can isolating the offending instruction, in hexadecimal, I will endeavor to research what 8086 derived instruction it may be. This will take quite a while, but is easier than trying to decipher someone else's code since 90+% of programmer's disdain the idea of properly documenting their code.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3159
Location: Illinois, USA

PostPosted: Wed May 08, 2019 3:13 pm    Post subject: Reply with quote

On my k6 machine which runs eix with no problem.
Code:
k6 ~ # file $(which eix)
/usr/bin/eix: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped
k6 ~ # equery w eix
/usr/portage/app-portage/eix/eix-0.33.7.ebuild
k6 ~ # uname -a
Linux k6 4.4.115-gentoo #7 Thu May 2 23:26:01 CDT 2019 i586 AMD-K6(tm)-III Processor AuthenticAMD GNU/Linux


I see that I don't use pie. I don't know what the 2.6.32 refers to, but it's different from your 3.2.0
I'm not sure which gcc I compiled with. Probably an older one.

Code:
k6 ~ # ls -al /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 10 May  3 22:49 /lib/ld-linux.so.2 -> ld-2.23.so
k6 ~ # equery b /lib/ld-linux.so.2
 * Searching for /lib/ld-linux.so.2 ...
sys-libs/glibc-2.23-r4 (/lib/ld-2.23.so)
sys-libs/glibc-2.23-r4 (/lib/ld-linux.so.2 -> ld-2.23.so)
So that, 2.23-r4 is the glibc version that eix is using on my working system.

NeddySeagoon, do you think there may be a problem with pie on k6?

Code:
k6 ~ # gcc-config -l
 [1] i486-pc-linux-gnu-4.9.4 *
 [2] i486-pc-linux-gnu-8.2.0
I'm still using an old gcc. Not sure what the build machine is using yet.

UPDATE: The build machine is using 7.3.0

Which gcc and binutils are you using? I can duplicate your exact eix with that information and see if it works on my machine without using pie. I think compiling with pie would take some considerable effort.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3159
Location: Illinois, USA

PostPosted: Wed May 08, 2019 3:39 pm    Post subject: Reply with quote

Position Independent Code is a very useful feature that’s been here for a long time, but is still weakly supported by our C++ ecosystem. Unless enforced as the default by the compiler (you can build gcc/clang that way) it is quite painful to deploy as soon as you start dealing with projects that mix-up various libraries. The issue is further complicated by the fact that it works in “reverse”: you must know how your code will be finally linked at the time you compile it (something you probably can’t know if you publish a library).
...
In the end the easiest solution might simply be to always compile with -fPIC, and let the final linker decide if it wants a PIE or not. I did not run the benchmarks, but it seems like the impact is negligible for general purpose x86_64 code. It is not as easy on x86 32 bits: according to this paper, you should expect a 10% overhead on average.


Leading me to suspect a toolchain incompatibility.
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Wed May 08, 2019 3:40 pm    Post subject: Reply with quote

Thanks Tony0945 for your reply.

Dualbooting grub is out of the question for this project. I specifically tried out with a VM, as you can see in my OP... funny thing is, that's where I started, and had already forgotten about that :lol: .

The reason I tried with a VM is exactly because I though something might pollute the code with i686 code! Also thought about 64bit, which seemed even more error-prone. But the problem is haunting me: I'm kind of going on in circles - the same problem persist in this chroot.

I might create the chroot yet again and make sure I use linux32 every single time (I'm chrooting via a script now to eliminate making such a stupid error). But I've done "emerge -e system" many times know on the slave, I believe that should rebuild the toolchain properly?

The chroot still "sees" a i686:
Code:
uname -a
Linux ArkkiVille 5.0.13-zen1-1-zen #1 ZEN SMP PREEMPT Sun May 5 18:05:42 UTC 2019 i686 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux


Perhaps something is autodetecting stuff despite chost being set to i586?

What is pie?
_________________
- Ville
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3159
Location: Illinois, USA

PostPosted: Wed May 08, 2019 4:33 pm    Post subject: Reply with quote

https://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables
https://packages.gentoo.org/useflags/pie
https://forums.gentoo.org/viewtopic-t-1075400-start-0.html
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43577
Location: 56N 3W

PostPosted: Wed May 08, 2019 6:49 pm    Post subject: Reply with quote

ville.aakko,

Position Independent Executables (PIE) have been the Gentoo default since the /17.0/ profile was introduced,
You may not mix PIE and not PIE code. It breaks all your static libraries.
Part of the move to /17.0/ profiles was to rebuild all the installed static libraries.

To rebuild all the bits of your toolchain, in the right order (order is important), run the script
Code:
/usr/portage/scripts/bootstrap.sh

Thats a piece of Gentoo history. Its the step to move from a stage1 to a stage2, when you do a stage1 install.
It sets its own USE flags and must be run in one go.

Getting from stage2 to stage3 consists of
Code:
emerge -e @system
it also builds your toolchain and a lot of other things but as the @system set are not required to have fully defined dependencies, it may build things in the wrong order to have the desired effect. Not having fully defined dependencies avoids issues with circular dependencies within the system set.

After the linux32 chroot, uname -a shows a fake 32 bit name. That it says i686 is harmless.
What is actually installed depends on your CFLAGS, CXXFLAGS and CPU_FLAGS_X86, all of which must be set explicitly to to match the k6-3 target.
You must not use -march=native

Invalid data should not be able to case illegal instruction exceptions.
The difference between code and data is only context. Think of it this way.
The source code read by gcc, is data that gcc will operate on (data to gcc)
The output from gcc (the binary that you will execute) is output data to gcc.
When the gcc output data is loaded into memory, its input data to the loader.
It only becomes code when control is passed to the location where the programs first instruction is.
Code becomes a well defined context, as all the instruction sizes are known to the CPU.
It follows that illegal instructions come from a small number of sources.
gcc planted a valid instruction but your CPU does not know how to execute it.
gcc did something wrong (a gcc bug)
The program tried to execute some data. (Either a program bug or a gcc bug)
If you can make a program execute data by presenting it with invalid input, that's a major bug.

I suspect the problem is that gcc planted a valid instruction but your CPU does not know how to execute it due to your somewhat rare build environment.
That also answers the question of why just you.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 3159
Location: Illinois, USA

PostPosted: Wed May 08, 2019 7:39 pm    Post subject: Reply with quote

ville.aakko,

My native k6-3 and the Phenom II build partition are on profile 13.0. My 64-bit computers are on 17.0

I don't know if profile 13.0 is still available. I support it out of local overlay. IMHO, it makes more sense for 32-bit computers with limited caches. YMMV.
I don't know NeddySeagoon's stand on this, but if it's different from mine, your wisest course is follow him. As a retired professional software developer, I refuse to yield for MY systems.
However, that path calls for a lot of knowledge that you don't have and a lot of effort that you can probably use to greater effect elsewhere.
Neddy is also a professional engineer but pros can differ. Laymen had best follow the mainstream. It's like architecture.
Back to top
View user's profile Send private message
ville.aakko
Tux's lil' helper
Tux's lil' helper


Joined: 06 Aug 2006
Posts: 100
Location: Oulu, Finland

PostPosted: Wed May 08, 2019 7:52 pm    Post subject: Reply with quote

Hi guys,

Thanks for all your input, it is appreciated!

Need to go sleep, I will take a look at things tomorrow.

FWIW both (the chroot and the K6-3 box) have been set to the same profile (as was the VM), i.e. ./../usr/portage/profiles/default/linux/x86/17.0 .

Also I don't use --march native anywhere, as it is very easy to notice in the documentation not to use it (and if one is also thinking while making the choices instead of blindly following some wiki, it is quite obvious, at least to me, not use it if compiling to another target in any way).

After spotting the timezone error, I already run bootstrap.sh once on the host. After that, emerge -e system and emerge -e world. However, I didn't yet re-generate all of the system packages for the k6-3 box.

But as I said, I will double check everything tomorrow, and will get back. Perhaps this is just a too tough a nut to crack...
_________________
- Ville
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43577
Location: 56N 3W

PostPosted: Wed May 08, 2019 9:42 pm    Post subject: Reply with quote

ville.aakko,

Code:
emerge -e world
includes
Code:
emerge -e system
. You should use the set namespace too. @system and @world.
It won't actually matter until someone adds a package called system or world, then you will get the packages and not the sets.


Tony0945,

I was never a professional software person, I just had to do some now and again.

I presume your objection to 17.0 profiles on i686 and below are the default USE=pie setting, which demands the use of a base address register on an arch that doesn't have enough registers to start with?
You don't have to have pie on the 17.0 and later profiles. The profile forces USE=pie but you are free to unforce it and turn it off. That's the path of least resistance.
With the 17.0 profiles, you also get package mask changes that you may or may not find useful.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4213
Location: Dallas area

PostPosted: Wed May 08, 2019 10:01 pm    Post subject: Reply with quote

I run the 17.0 profile w/o pie and pass gcc -pie when I built it. No problem with any of it.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum