| View previous topic :: View next topic |
| Author |
Message |
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
 Posted: Mon Jan 15, 2024 4:28 pm Post subject: Portage/emerge fails with "Illegal instruction" |
 |
|
Hi guys. I have a couple of really old systems that are in the same pickle. They've been chugging along for... over decade? It looks like glibc was updated and now portage will not compile/install anything. I don't *think* CFLAGS has ever been updated...
The error is the same for all packages:
| Code: | /usr/lib/portage/python3.11/ebuild.sh: line 789: 21 Illegal instruction ( if [[ -n ${PORTAGE_PIPE_FD} ]]; then
eval "exec ${PORTAGE_PIPE_FD}>&-"; unset PORTAGE_PIPE_FD;
fi; __ebuild_main ${EBUILD_SH_ARGS}; exit 0 ) |
| Code: | cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Celeron (Mendocino)
stepping : 5
microcode : 0x3
cpu MHz : 465.271
cache size : 128 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr cpuid
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown
bogomips : 930.54
clflush size : 32
cache_alignment : 32
address sizes : 36 bits physical, 32 bits virtual
power management: |
| Code: | grep CFLAGS /etc/portage/make.conf
CFLAGS="-O2 -march=i686 -pipe"
CXXFLAGS="${CFLAGS}" |
I've been poking around on the forums but haven't found anything particularly helpful yet. I am open to suggestions... |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54594
Location: 56N 3W
|
| Posted: Mon Jan 15, 2024 4:40 pm Post subject: |
|
|
drumgod,
Share please.
"Illegal instruction" means that the CPu has been asked to execute an instruction that it doesn't have.
At the of dmesg, after you trigger the problem, it may tell you the offending binary.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Mon Jan 15, 2024 5:54 pm Post subject: |
|
|
Oops:
| Code: | # emerge --info
Portage 3.0.59 (python 3.11.7-final-0, default/linux/x86/17.0, gcc-12, glibc-2.38-r9, 6.5.3 i686)
=================================================================
System uname: Linux-6.5.3-i686-Celeron_-Mendocino-with-glibc2.38
KiB Mem: 369472 total, 147072 free
KiB Swap: 3145720 total, 3145720 free
Timestamp of repository gentoo: Wed, 10 Jan 2024 17:30:02 +0000
Head commit of repository gentoo: e6381523c8cc1f827edbb0386adf058bfd89a4b2
sh bash 5.1_p16-r6
ld GNU ld (Gentoo 2.40 p5) 2.40.0
app-misc/pax-utils: 1.3.7::gentoo
app-shells/bash: 5.1_p16-r6::gentoo
dev-lang/perl: 5.38.2-r1::gentoo
dev-lang/python: 3.11.7::gentoo, 3.12.1::gentoo
dev-util/meson: 1.3.0-r2::gentoo
sys-apps/baselayout: 2.14-r1::gentoo
sys-apps/openrc: 0.48::gentoo
sys-apps/sandbox: 2.38::gentoo
sys-devel/autoconf: 2.71-r6::gentoo
sys-devel/automake: 1.16.5-r1::gentoo
sys-devel/binutils: 2.40-r5::gentoo
sys-devel/binutils-config: 5.5::gentoo
sys-devel/gcc: 12.3.1_p20230526::gentoo
sys-devel/gcc-config: 2.11::gentoo
sys-devel/libtool: 2.4.7-r1::gentoo
sys-devel/make: 4.4.1-r1::gentoo
sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers)
sys-libs/glibc: 2.38-r9::gentoo
Repositories:
gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
volatile: True
sync-rsync-verify-jobs: 1
sync-rsync-extra-opts:
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-max-age: 3
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="@FREE"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind"
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=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LEX="flex"
MAKEOPTS="-j2"
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"
SHELL="/bin/bash"
USE="acl bzip2 cli crypt dri fortran gdbm iconv ipv6 libtirpc ncurses nls nptl openmp pam pcre readline seccomp split-usr ssl test-rust unicode x86 xattr zlib" ABI_X86="32" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio 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 greis isync itrax mtk3301 ntrip navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_11" RUBY_TARGETS="ruby31" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account"
Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PYTHONPATH, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
|
Hmm. From dmesg after a few attempts:
| Code: | [ 504.844394] traps: bash[3110] trap invalid opcode ip:b7e7e9e5 sp:bfde7b1c error:0 in libc.so.6[b7cf8000+192000]
[ 739.359436] traps: bash[3427] trap invalid opcode ip:b7e7c9e5 sp:bfe0cb0c error:0 in libc.so.6[b7cf6000+192000]
[ 6592.767476] traps: bash[3661] trap invalid opcode ip:b7e869e5 sp:bfe61e1c error:0 in libc.so.6[b7d00000+192000] |
That seems to point to glibc as well... I'm thinking I need to figure out what CFLAGS is supposed to be on this processor and rebuild/replace glibc... Somehow. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54594
Location: 56N 3W
|
| Posted: Mon Jan 15, 2024 7:54 pm Post subject: |
|
|
drumgod,
| Code: | | CFLAGS="-O2 -march=i686 -pipe" |
should produce code that will run on any i686 from the Pentium Pro or later.
Your CPU_FLAGS_X86 is unset, there is no default inherited form your profile even, so its not including hand optimised code for instruction set extensions you don't have.
Your CPU has mmx.
As you run a stable system you should find a suitable glibc on the new binhost.
You must not downgrade glibc is your system will be broken differently to the way it is now.
You can install it without using portage too, or using portage from a rescue install. Fix my Gentoo should give you some ideas.
This problem is either a bug, the build system is planting instructions that you don't have, a hardware problem or a RAM soft error.
Once you have the binary glibc installed and tested, you need to rebuild it.
The binary may not match your settings exactly.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Tue Jan 16, 2024 12:39 pm Post subject: |
|
|
Thanks for your help Neddy! I found the "Fix my Gentoo" page while reading through the glibc related post further down in this forum. I also came across the docs for using binary packages...
I configured a binhost repository and re-installed glibc with "emerge -1v --getbinpkg sys-libs/glibc". That seems to have worked fine.
As a test, I then tried to emerge net-analyzer/traceroute.
I get the exact same error. It seems like this should be a valid way to recover... or did I miss something?
| Code: | These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 48.18 s (backtrack: 0/20).
[ebuild N ] net-analyzer/traceroute-2.1.3::gentoo USE="-static" 72 KiB
Total: 1 package (1 new), Size of downloads: 72 KiB
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) net-analyzer/traceroute-2.1.3::gentoo
>>> Downloading 'http://distfiles.gentoo.org/distfiles/1f/traceroute-2.1.3.tar.gz'
--2024-01-16 05:42:47-- http://distfiles.gentoo.org/distfiles/1f/traceroute-2.1.3.tar.gz
Resolving distfiles.gentoo.org... 156.146.36.24, 89.187.177.16, 2a02:6ea0:c400::12, ...
Connecting to distfiles.gentoo.org|156.146.36.24|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 73171 (71K) [application/x-gzip]
Saving to: â/usr/portage/distfiles/traceroute-2.1.3.tar.gz.__download__â
/usr/portage/distfi 100%[===================>] 71.46K --.-KB/s in 0.06s
2024-01-16 05:42:49 (1.16 MB/s) - â/usr/portage/distfiles/traceroute-2.1.3.tar.gz.__download__â saved [73171/73171]
* traceroute-2.1.3.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking traceroute-2.1.3.tar.gz to /var/tmp/portage/net-analyzer/traceroute-2.1.3/work
>>> Source unpacked in /var/tmp/portage/net-analyzer/traceroute-2.1.3/work
>>> Preparing source in /var/tmp/portage/net-analyzer/traceroute-2.1.3/work/traceroute-2.1.3 ...
/usr/lib/portage/python3.11/ebuild.sh: line 789: 21 Illegal instruction ( if [[ -n ${PORTAGE_PIPE_FD} ]]; then
eval "exec ${PORTAGE_PIPE_FD}>&-"; unset PORTAGE_PIPE_FD;
fi; __ebuild_main ${EBUILD_SH_ARGS}; exit 0 )
* The ebuild phase 'prepare' has exited unexpectedly. This type of
* behavior is known to be triggered by things such as failed variable
* assignments (bug #190128) or bad substitution errors (bug #200313).
* Normally, before exiting, bash should have displayed an error message
* above. If bash did not produce an error message above, it's possible
* that the ebuild has called `exit` when it should have called `die`
* instead. This behavior may also be triggered by a corrupt bash binary or
* a hardware problem such as memory or cpu malfunction. If the problem is
* not reproducible or it appears to occur randomly, then it is likely to
* be triggered by a hardware problem. If you suspect a hardware problem
* then you should try some basic hardware diagnostics such as memtest.
* Please do not report this as a bug unless it is consistently
* reproducible and you are sure that your bash binary and hardware are
* functioning properly.
>>> Failed to emerge net-analyzer/traceroute-2.1.3, Log file:
>>> '/var/tmp/portage/net-analyzer/traceroute-2.1.3/temp/build.log'
* Messages for package net-analyzer/traceroute-2.1.3:
* The ebuild phase 'prepare' has exited unexpectedly. This type of
* behavior is known to be triggered by things such as failed variable
* assignments (bug #190128) or bad substitution errors (bug #200313).
* Normally, before exiting, bash should have displayed an error message
* above. If bash did not produce an error message above, it's possible
* that the ebuild has called `exit` when it should have called `die`
* instead. This behavior may also be triggered by a corrupt bash binary or
* a hardware problem such as memory or cpu malfunction. If the problem is
* not reproducible or it appears to occur randomly, then it is likely to
* be triggered by a hardware problem. If you suspect a hardware problem
* then you should try some basic hardware diagnostics such as memtest.
* Please do not report this as a bug unless it is consistently
* reproducible and you are sure that your bash binary and hardware are
* functioning properly. |
More of the same in dmesg:
| Code: | [71240.523335] traps: bash[3373] trap invalid opcode ip:b7e31eb5 sp:bfb703cc error:0 in libc.so.6[b7cab000+193000]
[73188.811445] traps: bash[4382] trap invalid opcode ip:b7db1eb5 sp:bfd7a9ac error:0 in libc.so.6[b7c2b000+193000] |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54594
Location: 56N 3W
|
| Posted: Tue Jan 16, 2024 1:06 pm Post subject: |
|
|
drumgod,
Its a valid recovery process. I've used a few times, so have others here.
The official binhost is new but there have been unofficial binhosts for a long time and unpicking the stage3 and/or rescue installs too.
The fix my Gentoo page pulls things together.
Boot into memtest86 and run half a dozen cycles.
If it fails post the output. It tests a lot more than RAM.
When it fails at the same address, RAM is indicated. When failures are random and cannot be repeated, its probably not RAM.
The x86 binhost is not actually built on an x86 any more.
We have seen instruction 'leakage', most notably on i486.
If the hardware looks good. Its probably time to make a bug post at bugs.gentoo.org.
This started when you built glibc for yourself on this system. Is that correct?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Tue Jan 16, 2024 2:35 pm Post subject: |
|
|
I have two, nearly identical, systems behaving the same way. They both stopped being able to compile in the middle of "emerge -1uDNv world", after glibc was upgraded. They both had the same packages listed by "emerge -v --resume". They both fail with the same message. One is in the original condition, the other I've been working on trying to resolve this...
| NeddySeagoon wrote: | drumgod,
Its a valid recovery process. I've used a few times, so have others here.
The official binhost is new but there have been unofficial binhosts for a long time and unpicking the stage3 and/or rescue installs too.
The fix my Gentoo page pulls things together.
|
I have pulled binaries out of stage tarballs before, as well as from my own systems and unofficial repositories. I guess I was wondering if, in the end, the new "official" way of installing them was any different.
| NeddySeagoon wrote: | Boot into memtest86 and run half a dozen cycles.
If it fails post the output. It tests a lot more than RAM.
When it fails at the same address, RAM is indicated. When failures are random and cannot be repeated, its probably not RAM.
|
I'm assuming it's not ram, as it is happening on two different systems that have been working fine until now. The two systems seem to be up and operating correctly. I just can't compile any longer.
| NeddySeagoon wrote: | The x86 binhost is not actually built on an x86 any more.
We have seen instruction 'leakage', most notably on i486.
If the hardware looks good. Its probably time to make a bug post at bugs.gentoo.org.
This started when you built glibc for yourself on this system. Is that correct? |
Correct, and the binary package installed from gentoo.osuosl.org behaves the same way. Since everything seems to have ground to a halt when gclibc was upgraded, would be possible to try and downgrade glibc? It seems it would need to be done to be via a binary... I'm not sure what that would entail or if it would be worth the time.
Maybe I just need to write these systems off. They are ancient but, up until now, they have been running 24/7 for years, doing what they're supposed to. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54594
Location: 56N 3W
|
| Posted: Tue Jan 16, 2024 2:51 pm Post subject: |
|
|
drumgod,
Check for an existing bug and start a new one if required. Other x86 users will be affected too.
Someone has to be first, it just your turn this time.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22740
|
| Posted: Tue Jan 16, 2024 3:39 pm Post subject: |
|
|
| If you can, please provide a disassembly of the instructions around the faulting address. This may be a case where the chosen -march can, with the right gcc, emit an instruction that your CPU does not understand. This could mean that the -march is actually too aggressive for your CPU (unlikely, but possible) or it could be a compiler bug that the valid -march is causing it to use instructions that ought not be allowed by that -march. I believe I have heard of cases where a system was almost, but not quite, an i686, so -march=i686 allowed some unusual instructions that the not-quite-i686 CPU could not handle, but that a traditional full i686 CPU would handle. |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
| Posted: Tue Jan 16, 2024 7:28 pm Post subject: |
|
|
Thanks again Neddy. Sigh. I'll have to set up an account and figure out how to file a bug.
| Hu wrote: | | If you can, please provide a disassembly of the instructions around the faulting address. This may be a case where the chosen -march can, with the right gcc, emit an instruction that your CPU does not understand. This could mean that the -march is actually too aggressive for your CPU (unlikely, but possible) or it could be a compiler bug that the valid -march is causing it to use instructions that ought not be allowed by that -march. I believe I have heard of cases where a system was almost, but not quite, an i686, so -march=i686 allowed some unusual instructions that the not-quite-i686 CPU could not handle, but that a traditional full i686 CPU would handle. |
Hmm. Not sure I'm doing this correctly...
From "trap invalid opcode ip:b7db1eb5 sp:bfd7a9ac error:0 in libc.so.6[b7c2b000+193000]": b7db1eb5 - b7c2b000 = 186eb5
From the output of "objdump --demangle -d /lib/libc.so.6":
| Code: | 186e8f: e8 ac 68 f3 ff call bd740 <__xpg_strerror_r@@GLIBC_2.3.4+0x13360>
186e94: 8d 78 ff lea -0x1(%eax),%edi
186e97: 89 c3 mov %eax,%ebx
186e99: 89 3c 24 mov %edi,(%esp)
186e9c: e8 6f 07 f0 ff call 87610 <__libc_alloca_cutoff@@GLIBC_PRIVATE>
186ea1: 85 c0 test %eax,%eax
186ea3: 0f 95 c2 setne %dl
186ea6: 81 ff 00 10 00 00 cmp $0x1000,%edi
186eac: 0f 96 c0 setbe %al
186eaf: 08 c2 or %al,%dl
186eb1: 88 95 64 fb ff ff mov %dl,-0x49c(%ebp)
186eb7: 0f 84 75 0b 00 00 je 187a32 <glob@GLIBC_2.0+0xca2>
186ebd: 89 e0 mov %esp,%eax
186ebf: 83 c3 1a add $0x1a,%ebx
186ec2: 83 e3 f0 and $0xfffffff0,%ebx
186ec5: 29 dc sub %ebx,%esp
186ec7: 8d 54 24 23 lea 0x23(%esp),%edx
186ecb: 83 e2 f0 and $0xfffffff0,%edx
186ece: 89 95 80 fb ff ff mov %edx,-0x480(%ebp)
186ed4: 29 e0 sub %esp,%eax
186ed6: 89 85 78 fb ff ff mov %eax,-0x488(%ebp)
186edc: 89 f0 mov %esi,%eax
186ede: 46 inc %esi
186edf: 89 7c 24 0c mov %edi,0xc(%esp)
186ee3: 8b 8d 90 fb ff ff mov -0x470(%ebp),%ecx
186ee9: 89 14 24 mov %edx,(%esp)
186eec: 89 4c 24 04 mov %ecx,0x4(%esp)
186ef0: 29 c8 sub %ecx,%eax
186ef2: 89 44 24 08 mov %eax,0x8(%esp)
186ef6: 8b 9d 8c fb ff ff mov -0x474(%ebp),%ebx |
Does that look like what you're looking for? If not, can you point me in the direction of appropriate instructions? I can't add anything to the system right now. It's a pretty basic installation. Thanks. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2461
|
| Posted: Tue Jan 16, 2024 8:27 pm Post subject: |
|
|
| drumgod wrote: | Oops:
| Code: | # emerge --info
Portage 3.0.59 (python 3.11.7-final-0, default/linux/x86/17.0, gcc-12, glibc-2.38-r9, 6.5.3 i686)
=================================================================
System uname: Linux-6.5.3-i686-Celeron_-Mendocino-with-glibc2.38
|
|
Wow, that brought me back to some 25 years ago I actually had such a thing. Mine gave up after only 5-6 years of service, if it wasn't two of those behaving the same way, I wouldn't be surprised of hardware failure. It's still possible, but less likely both fail the same way at the same time, consistently.
Given the fact how old this thing is and I guess how few of those are in use nowadays, it's rather likely it's a regression in the compiler.
Best Regards,
Georgi |
|
| Back to top |
|
|
drumgod
n00b
Joined: 12 Dec 2003
Posts: 61
|
|
| Back to top |
|
|
|
|
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
|
|
Portage & Programming
