hi,
I'm running 
slackware 10 
 gcc  3.4.2 
 kernel 2.6.8.1(vanilla with nvidia 's binary module)
libc.so.6

recently when i try to run clear i get this message.

Inconsistency detected by ld.so: ../sysdeps/i386/dl-machine.h: 611:
elf_machine_rel_relative: Assertion `((reloc->r_info) & 0xff) == 8'
failed!

but when i copied the clear binary from a redhat 9 machine it worked
mine !!
i still haven't replaced the original binary though.
I would like to know what went wrong.

Regards
Manu

On Mon, 18 Oct 2004 06:39:56 -0700, Manu wrote:

> recently when i try to run clear i get this message.
> 
> Inconsistency detected by ld.so: ../sysdeps/i386/dl-machine.h: 611:
> elf_machine_rel_relative: Assertion `((reloc->r_info) & 0xff) == 8'
> failed!
> 
> but when i copied the clear binary from a redhat 9 machine it worked
> mine !!
> i still haven't replaced the original binary though.
> I would like to know what went wrong.

Maybe the output on my Slackware X - will help:

~$ file `which clear`
/usr/bin/clear: Bourne shell script text executable
~$ cat `which clear`
#! /bin/sh
tput clear
~$ ldd `which tput`
        libncursesw.so.5 => /lib/libncursesw.so.5 (0x40022000)
        libgpm.so.1 => /lib/libgpm.so.1 (0x40067000)
        libncurses.so.5 => /lib/libncurses.so.5 (0x4006d000)
        libc.so.6 => /lib/libc.so.6 (0x400ac000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
~$ md5sum `which tput`
12b356fda4a6139ace0b383842aef57f  /usr/bin/tput

You might want to get your Slackware version's "tput" from some mirror
site, and "diff" (and "md5sum") that to the one you have. If all seems
fine, have a look through /etc/ld.so.conf - maybe just run "ldconfig"...

Upon finding nothing odd there: compare your libraries (also maybe stuff
in /etc, /bin and /sbin) with standard ones. I'd be paranoid enough to run
go run some "ckrootkit", "rkhunter" and "strins" myself (even though it
was probably just some bit-shift in core, or a HD gone haywire. <:)

Hell, this got all got me running:
lsattr -R / |grep '\-i\-'

HTH.

-- 
-Menno.

hi,

> ~$ file `which clear`
> /usr/bin/clear: Bourne shell script text executable
> ~$ cat `which clear`
> #! /bin/sh
> tput clear
> ~$ ldd `which tput`
>         libncursesw.so.5 => /lib/libncursesw.so.5 (0x40022000)
>         libgpm.so.1 => /lib/libgpm.so.1 (0x40067000)

>         libncurses.so.5 => /lib/libncurses.so.5 (0x4006d000)
>         libc.so.6 => /lib/libc.so.6 (0x400ac000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> ~$ md5sum `which tput`
> 12b356fda4a6139ace0b383842aef57f  /usr/bin/tput

funny ! my clear is a binary .

I had checked my clear binary as well as redhat9 clear binary before
posting my question.

[12:05 PM][manu:manu]$ file `which clear`
/usr/bin/clear: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), stripped

i had also run ldconfig and the ldd run on both binaries.my slackware
binary
depends on 
libncursesw.so.5 => /lib/libncursesw.so.5 (0x4002d000)

which is not the case with the redhat 9 version.

i had never known that something called tput existed :-)
and surprisingly tput clear works !
and since tput also depends on
libncursesw.so.5 => /lib/libncursesw.so.5 (0x4002d000)
i think it's my clear binary  which is  corrupt...

no i'm not paranoid enough to run ckrootkit :-)
this is a single user machine behind a nat and firewall with only
access to web through a
proxy.
so i guess it's my hard disk gone haywire.It's been giving me troubles
for
a long time.

guess it's time to backup stuff ;-)
Thanks for the quick response 

cheers
manu
PS:btw which version of slackware are you running ??
md5sum of my tput binary is same as your's.

In comp.os.linux.misc Menno Duursma <pan@desktop.lan> wrote:

> Maybe the output on my Slackware X - will help:

> ~$ file `which clear`
> /usr/bin/clear: Bourne shell script text executable
> ~$ cat `which clear`
> #! /bin/sh
> tput clear
> ~$ ldd `which tput`
>         libncursesw.so.5 => /lib/libncursesw.so.5 (0x40022000)
>         libgpm.so.1 => /lib/libgpm.so.1 (0x40067000)
>         libncurses.so.5 => /lib/libncurses.so.5 (0x4006d000)
>         libc.so.6 => /lib/libc.so.6 (0x400ac000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This is a good example of what not to do (libncursesw and libncurses are
conflicting libraries - the underlying problem is the gpm configuration).

The current version of ncurses is 5.4 (20040208)
There's an faq at
	http://invisible-island.net/ncurses/ncurses.faq.html

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

On Tue, 19 Oct 2004 10:19:55 +0000, Thomas Dickey wrote:
> In comp.os.linux.misc Menno Duursma <pan@desktop.lan> wrote:

>> ~$ ldd `which tput`
>>         libncursesw.so.5 => /lib/libncursesw.so.5 (0x40022000)
>>         libgpm.so.1 => /lib/libgpm.so.1 (0x40067000)
>>         libncurses.so.5 => /lib/libncurses.so.5 (0x4006d000)
>>         libc.so.6 => /lib/libc.so.6 (0x400ac000)
>>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> This is a good example of what not to do (libncursesw and libncurses are
> conflicting libraries

Well, this is what my machine has (it's just standard Slackware 10 - with
all the patches applied), both "clear" and ^L work fine overhear BTW.

$ ls -l libncurses*
lrwxrwxrwx  1 root root     17 2004-07-10 01:29 libncurses.so.5 -> libncurses.so.5.4
-rwxr-xr-x  1 root root 253600 2004-02-18 00:22 libncurses.so.5.4
lrwxrwxrwx  1 root root     18 2004-07-10 01:29 libncursesw.so.5 -> libncursesw.so.5.4
-rwxr-xr-x  1 root root 279320 2004-02-18 00:22 libncursesw.so.5.4

> - the underlying problem is the gpm configuration).

Could you elaborate on that ?
(As gpm works fine here: imps2 protocol - /dev/psaux device.)

> The current version of ncurses is 5.4 (20040208)

I guess i'm all up-to-date then ... :-)

> There's an faq at
> 	http://invisible-island.net/ncurses/ncurses.faq.html

Maybe the OP is helped by that, all is fine here, thanks non the less.

If you're sure about the above being wrong though, you might want to
report it to Patrick ...

-- 
-Menno.

In alt.os.linux.slackware Menno Duursma <pan@desktop.lan> wrote:
> On Tue, 19 Oct 2004 10:19:55 +0000, Thomas Dickey wrote:
>> In comp.os.linux.misc Menno Duursma <pan@desktop.lan> wrote:

>>> ~$ ldd `which tput`
>>>         libncursesw.so.5 => /lib/libncursesw.so.5 (0x40022000)
>>>         libgpm.so.1 => /lib/libgpm.so.1 (0x40067000)
>>>         libncurses.so.5 => /lib/libncurses.so.5 (0x4006d000)
>>>         libc.so.6 => /lib/libc.so.6 (0x400ac000)
>>>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>> 
>> This is a good example of what not to do (libncursesw and libncurses are
>> conflicting libraries

> Well, this is what my machine has (it's just standard Slackware 10 - with
> all the patches applied), both "clear" and ^L work fine overhear BTW.

But that doesn't mean (for example) that someone could successfully
run a 'clear' which is linked to libncurses (and gpm mis-linked to
libncurses).

> $ ls -l libncurses*
> lrwxrwxrwx  1 root root     17 2004-07-10 01:29 libncurses.so.5 -> libncurses.so.5.4
> -rwxr-xr-x  1 root root 253600 2004-02-18 00:22 libncurses.so.5.4
> lrwxrwxrwx  1 root root     18 2004-07-10 01:29 libncursesw.so.5 -> libncursesw.so.5.4
> -rwxr-xr-x  1 root root 279320 2004-02-18 00:22 libncursesw.so.5.4

>> - the underlying problem is the gpm configuration).

> Could you elaborate on that ?
> (As gpm works fine here: imps2 protocol - /dev/psaux device.)

>> The current version of ncurses is 5.4 (20040208)

> I guess i'm all up-to-date then ... :-)

yes (though some distributions package beta versions of ncurses - not always
a good thing).

>> There's an faq at
>> 	http://invisible-island.net/ncurses/ncurses.faq.html

> Maybe the OP is helped by that, all is fine here, thanks non the less.

> If you're sure about the above being wrong though, you might want to
> report it to Patrick ...

it's been in my ncurses faq since 1998 - long enough for people to be
aware of the issue.  Since no one's pointed out a (real(*)) application that
actually uses the backwards interface, there's no reason why I should regard
it as anything but a bug.

(Patrick could of course send a bug report to me - it's been a couple of years
since the last one)

(*) I'm aware of a couple of very poor quality pieces of code which do this,
    and choose to not discuss them in polite company.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net