Menu
▾
▴
valgrind-users
|
From: Britton K. <bri...@gm...> - 2013-05-17 18:27:43
|
I'm on a beaglebone white with vanilla Angstrom (linux 3.2) distribution. Valgrind fails like this: root@bboneumh2:~/software# ~/local/bin/valgrind --leak-check=yes ./my_program ==13719== Memcheck, a memory error detector ==13719== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==13719== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==13719== Command: ./heat_and_water_meter ==13719== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: memcpy valgrind: in an object with soname matching: ld-linux.so.3 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux.so.3 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue -- exiting now. Sorry. I've installed libc6-dbg as it says. Same problem. While installing libc6-dbg, opkg complains like this: bash-dbg: unsatisfied recommendation for ncurses-libtinfo-dbg libc6-dbg: unsatisfied recommendation for libsegfault-dbg libc6-dbg: unsatisfied recommendation for eglibc-thread-db-dbg libc6-dbg: unsatisfied recommendation for eglibc-extra-nss-dbg libc6-dbg: unsatisfied recommendation for libcidn-dbg But trying 'opkg install eglibc-thread-db-dbg' says its an unknown package. Any clues? Am I missing some other step not mentioned here? Thanks, Britton |
|
From: John R. <jr...@bi...> - 2013-05-20 15:52:06
|
> I'm on a beaglebone white with vanilla Angstrom (linux 3.2) > distribution. Valgrind fails like this: > ==13719== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: memcpy > valgrind: in an object with soname matching: ld-linux.so.3 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux.so.3 > I've installed libc6-dbg as it says. Same problem. Which other Linux distribution is Angstrom derived from, or is most similar to? Try running the previous version 3.7 of valgrind. Also post the output from: readelf --symbols ld-linux.so.3 | grep mem -- |
|
From: Britton K. <bri...@gm...> - 2013-05-23 17:14:25
|
On Mon, May 20, 2013 at 7:53 AM, John Reiser <jr...@bi...> wrote:
>> I'm on a beaglebone white with vanilla Angstrom (linux 3.2)
>> distribution. Valgrind fails like this:
>
>> ==13719== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
>
>> valgrind: A must-be-redirected function
>> valgrind: whose name matches the pattern: memcpy
>> valgrind: in an object with soname matching: ld-linux.so.3
>> valgrind: was not found whilst processing
>> valgrind: symbols from the object with soname: ld-linux.so.3
>
>> I've installed libc6-dbg as it says. Same problem.
>
> Which other Linux distribution is Angstrom derived from, or is most similar to?
Well, its based in part on OpenZaurus, which was debian-based. And it seems
pretty debian-like in the way its package manager opkg works. But that
about all I know, I'm just using it because it ships on the beaglebone.
> Try running the previous version 3.7 of valgrind.
This version doesnt seem to be available on the release archive page,
where can I get it?
> Also post the output from:
> readelf --symbols ld-linux.so.3 | grep mem
root@bboneumh:/# readelf --symbols /lib/ld-linux.so.3 | grep mem
12: 000150a8 332 FUNC WEAK DEFAULT 10 __libc_memalign@@GLIBC_2.4
root@bboneumh:/#
Note that I had to use /lib/ld-linux.so.3, as the argument to readelf,
what you suggested said this:
root@bboneumh2:~# readelf --symbols ld-linux.so.3 | grep mem
readelf: Error: 'ld-linux.so.3': No such file
root@bboneumh2:~#
Britton
|
|
From: John R. <jr...@bi...> - 2013-05-27 05:06:10
|
On 05/23/2013 10:14 AM, Britton Kerin wrote:
> On Mon, May 20, 2013 at 7:53 AM, John Reiser <jr...@bi...> wrote:
>>> I'm on a beaglebone white with vanilla Angstrom (linux 3.2)
>>> distribution. Valgrind fails like this:
>>
>>> ==13719== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
>>
>>> valgrind: A must-be-redirected function
>>> valgrind: whose name matches the pattern: memcpy
>>> valgrind: in an object with soname matching: ld-linux.so.3
>>> valgrind: was not found whilst processing
>>> valgrind: symbols from the object with soname: ld-linux.so.3
>>
>>> I've installed libc6-dbg as it says. Same problem.
>>
>> Which other Linux distribution is Angstrom derived from, or is most similar to?
>
> Well, its based in part on OpenZaurus, which was debian-based. And it seems
> pretty debian-like in the way its package manager opkg works. But that
> about all I know, I'm just using it because it ships on the beaglebone.
OK. It's Debian. The specific version of Debian might matter,
but perhaps in this case that info is no longer so significant.
>
>> Try running the previous version 3.7 of valgrind.
>
> This version doesnt seem to be available on the release archive page,
> where can I get it?
In general, try the Internet Archive. But in this case the source code
to valgrind is better anyway; see below.
>
>> Also post the output from:
>> readelf --symbols ld-linux.so.3 | grep mem
>
> root@bboneumh:/# readelf --symbols /lib/ld-linux.so.3 | grep mem
> 12: 000150a8 332 FUNC WEAK DEFAULT 10 __libc_memalign@@GLIBC_2.4
> root@bboneumh:/#
The actual source of memcheck's complaint is coregrind/m_redir.c:
void VG_(redir_initialise) ( void )
<<snip>>
# elif defined(VGP_arm_linux)
/* If we're using memcheck, use these intercepts right from
the start, otherwise ld.so makes a lot of noise. */
if (0==VG_(strcmp)("Memcheck", VG_(details).name)) {
add_hardwired_spec(
"ld-linux.so.3", "strlen",
(Addr)&VG_(arm_linux_REDIR_FOR_strlen),
complain_about_stripped_glibc_ldso
);
//add_hardwired_spec(
// "ld-linux.so.3", "index",
// (Addr)&VG_(arm_linux_REDIR_FOR_index),
// NULL
//);
add_hardwired_spec(
"ld-linux.so.3", "memcpy",
(Addr)&VG_(arm_linux_REDIR_FOR_memcpy),
complain_about_stripped_glibc_ldso
);
}
So the deal is: any valgrind tool [not just memcheck] for ARM Linux
will demand that ld-linux.so.3 has a subroutine named "memcpy"
which can be re-directed to an internal valgrind routine
that "does the same thing" in a way that valgrind considers
to be easier to understand and emulate or instrument.
Perhaps your version of ld-linux.so.3 does not have such a 'memcpy'.
The "readelf --symbols" shows that ld-linux.so.3 does not have this
itself, and you say that installing the debug package still does not
have a symbol for 'memcpy'. So perhaps ld-linux.so.3 no longer uses
_subroutine_ memcpy; it was replaced by memmove, or a macro which was
expanded inline, or by an open-coded loop. Therefore, try commenting-out
the code for memcpy, just like the code for 'index' is commented out:
//add_hardwired_spec(
// "ld-linux.so.3", "memcpy",
// (Addr)&VG_(arm_linux_REDIR_FOR_memcpy),
// complain_about_stripped_glibc_ldso
//);
Visit the main web page http://www.valgrind.org/ ,
follow the "Code Repository" link, use 'svn' source code manager
to checkout some version (try for top-of-trunk first, else 3.8.1).
Modify VG_(redir_initialise) as indicated. Build, install, test, use.
--
|
|
From: John R. <jr...@bi...> - 2013-06-03 20:20:14
|
[[Inconsistently quoted, for brevity.]]
> The actual source of memcheck's complaint is coregrind/m_redir.c:
> void VG_(redir_initialise) ( void )
> <<snip>>
> # elif defined(VGP_arm_linux)
> /* If we're using memcheck, use these intercepts right from
> the start, otherwise ld.so makes a lot of noise. */
> if (0==VG_(strcmp)("Memcheck", VG_(details).name)) {
> add_hardwired_spec(
> "ld-linux.so.3", "strlen",
> (Addr)&VG_(arm_linux_REDIR_FOR_strlen),
> complain_about_stripped_glibc_ldso
> );
> //add_hardwired_spec(
> // "ld-linux.so.3", "index",
> // (Addr)&VG_(arm_linux_REDIR_FOR_index),
> // NULL
> //);
> add_hardwired_spec(
> "ld-linux.so.3", "memcpy",
> (Addr)&VG_(arm_linux_REDIR_FOR_memcpy),
> complain_about_stripped_glibc_ldso
> );
> }
> I finally got around to trying this. I used 'trunk' in the svn command,
> which I hope is what you meant by top-of-trunk. It had both the strlen
> and memcpy sections that you mention above uncommented, so I tried
> commending out the memcpy secion. I then got an error just like the one
> I originally described, except it referred to strlen. So I tried again
> with that section commented out as well. Then the program ran, but I
> got some scary messages:
>
> root@bboneumh2:~/software# ~/local/bin/valgrind --leak-check=yes
> ./clock_gettime CLOCK_MONOTONIC
> ==28151== Memcheck, a memory error detector
> ==28151== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==28151== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
> ==28151== Command: ./clock_gettime CLOCK_MONOTONIC
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151== at 0x400B308: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151== at 0x400B344: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151== at 0x400C0C8: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151== at 0x400B1C0: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> ==28151== Conditional jump or move depends on uninitialised value(s)
> ==28151== at 0x400B1C8: ??? (in /lib/ld-2.12.2.so)
> ==28151==
> 234081.669967
> ==28151==
> ==28151== HEAP SUMMARY:
> ==28151== in use at exit: 0 bytes in 0 blocks
> ==28151== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==28151==
> ==28151== All heap blocks were freed -- no leaks are possible
> ==28151==
> ==28151== For counts of detected and suppressed errors, rerun with: -v
> ==28151== Use --track-origins=yes to see where uninitialised values come from
> ==28151== ERROR SUMMARY: 17 errors from 5 contexts (suppressed: 0 from 0)
>
> I haven't seen anything like those messages before. Are they likely
> related to the commented-out sections?
Very probably these are due to calls on strlen() or memcpy()
which have been expanded inline because of aggressive optimization
("#include <string.h>" compiled with -O2 or -O3.)
You can check this by examining the generated assembly code
which surrounds the addresses mentioned (0x400B308, 0x400B344, 0x400C0C8, etc.,
which are runtime addresses that are 0x4000000 higher than the addresses
in the filesystem copy of ld-2.12.2.so [or 0x0 higher in case ld-linux
has been prelinked.]) It should look like strlen or memcpy.
Assuming that it does look like strlen or memcpy, then it is safe to construct
and use one or more suppression rules in order to hide these complaints
in the future. (We know [assume] that it is safe because other platforms
have hit this problem before, and the code is "the same". In any event,
you as a "mere" user of ld-linux cannot do anything about that code, so don't
listen to those complaints.) Invoke valgrind using the additional argument
"--gen-suppressions=yes" and see the documentation about adding the output
to the default suppressions for your platform.
The other choice is to ask the supplier of your glibc for a version of ld-linux
that is compiled without -O2 and without -O3. [ld-linux is a part of glibc]
Your supplier of ld-linux is acting unfriendly to developers by not making
such a version readily available. This problem has been known generally
for several years by embedded developers on many platforms. You should
raise your voice and complain somewhat forcefully to your supplier of ld-linux.
[Of course, this being open source, in theory you could re-compile ld-linux
yourself. But it is somewhat difficult, cumbersome, and long.]
--
|
|
From: John R. <jr...@bi...> - 2013-06-05 15:45:09
|
On 06/04/2013, Britton Kerin wrote about "Beagleboard white" ARM using Angstrom Linux:
>>> root@bboneumh2:~/software# ~/local/bin/valgrind --leak-check=yes
>>> ./clock_gettime CLOCK_MONOTONIC
>>> ==28151== Memcheck, a memory error detector
>>> ==28151== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
>>> ==28151== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
>>> ==28151== Command: ./clock_gettime CLOCK_MONOTONIC
>>> ==28151==
>>> ==28151== Conditional jump or move depends on uninitialised value(s)
>>> ==28151== at 0x400B308: ??? (in /lib/ld-2.12.2.so)
>>> ==28151==
> I'll attach the output of 'objdump -d -S /lib/ld-2.12.2.so' as well. In
> case I'm misunderstanding things.
The addresses such as
==28151== at 0x400B308: ??? (in /lib/ld-2.12.2.so)
are "in /lib/ld-2.12.2.so", so the code at that location is what matters.
Looking at those addresses (0x4000000 less because of runtime placement
in the process versus no prelinking in the file):
$$$ b1b4: e0828001 add r8, r2, r1
b1b8: e5970008 ldr r0, [r7, #8]
b1bc: e3500000 cmp r0, #0
%%% b1c0: 0a00011f beq b644 <_dl_rtld_di_serinfo+0x2fbc>
b1c4: e1520008 cmp r2, r8
%%% b1c8: 2a00000d bcs b204 <_dl_rtld_di_serinfo+0x2b7c>
b2bc: e30a0aab movw r0, #43691 ; 0xaaab
b2c0: e595c004 ldr ip, [r5, #4]
b2c4: e34a0aaa movt r0, #43690 ; 0xaaaa; 0xaaaaaaab = (2<<32)/3
b2c8: e0815190 umull r5, r1, r0, r1 ### (r5=hi, r1=lo) = r0 * r1; 32x32==>64
b2cc: e1a011a1 lsr r1, r1, #3 ### r1 = original_r1 / 12;
b2d0: e151000c cmp r1, ip
b2d4: 21a0100c movcs r1, ip ### minimum
b2d8: e0811081 add r1, r1, r1, lsl #1 ### r1 = r1 + (r1<<1); // * 3
b2dc: e1a05101 lsl r5, r1, #2
b2e0: e51b7070 ldr r7, [fp, #-112] ; 0x70
$$$ b2e4: e0825005 add r5, r2, r5
b2e8: e08f1007 add r1, pc, r7
b2ec: e2811e51 add r1, r1, #1296 ; 0x510
b2f0: e2811008 add r1, r1, #8
b2f4: e1540001 cmp r4, r1
b2f8: 0a00000a beq b328 <_dl_rtld_di_serinfo+0x2ca0>
b2fc: e35a0000 cmp sl, #0
b300: 0a000239 beq bbec <_dl_rtld_di_serinfo+0x3564>
b304: e1520005 cmp r2, r5
%%% b308: 2a000006 bcs b328 <_dl_rtld_di_serinfo+0x2ca0>
b30c: e5931008 ldr r1, [r3, #8]
b310: e5932000 ldr r2, [r3]
b314: e283300c add r3, r3, #12
b318: e1550003 cmp r5, r3
b31c: e081100a add r1, r1, sl
b320: e782100a str r1, [r2, sl]
b324: 8afffff8 bhi b30c <_dl_rtld_di_serinfo+0x2c84>
b328: e59430e4 ldr r3, [r4, #228] ; 0xe4
b32c: e3530000 cmp r3, #0
b330: 0a000362 beq c0c0 <_dl_rtld_di_serinfo+0x3a38>
b334: e51b0064 ldr r0, [fp, #-100] ; 0x64
b338: e5933004 ldr r3, [r3, #4]
b33c: e1500005 cmp r0, r5
b340: e50b3068 str r3, [fp, #-104] ; 0x68
%%% b344: 9a000088 bls b56c <_dl_rtld_di_serinfo+0x2ee4>
c0c0: e51bc064 ldr ip, [fp, #-100] ; 0x64
c0c4: e15c0005 cmp ip, r5
%%% c0c8: 9afffd27 bls b56c <_dl_rtld_di_serinfo+0x2ee4>
we see that the complaints are about comparisons such as
b1c4: e1520008 cmp r2, r8
b304: e1520005 cmp r2, r5
where one of the operands was an addend for the other:
$$$ b1b4: e0828001 add r8, r2, r1 ### r8 = r2 + r1;
$$$ b2e4: e0825005 add r5, r2, r5 ### r5 += r2;
This looks like [I saw this a decade ago]:
----- glibc-2.12/elf/do-rel.h
auto inline void __attribute__ ((always_inline))
elf_dynamic_do_rel (struct link_map *map,
ElfW(Addr) reladdr, ElfW(Addr) relsize,
int lazy)
{
const ElfW(Rel) *r = (const void *) reladdr;
const ElfW(Rel) *end = (const void *) (reladdr + relsize);
ElfW(Addr) l_addr = map->l_addr;
#if (!defined DO_RELA || !defined ELF_MACHINE_PLT_REL) && !defined RTLD_BOOTSTRAP
/* We never bind lazily during ld.so bootstrap. Unfortunately gcc is
not clever enough to see through all the function calls to realize
that. */
if (lazy)
{
/* Doing lazy PLT relocations; they need very little info. */
for (; r < end; ++r)
elf_machine_lazy_rel (map, l_addr, r);
}
-----
----- glibc-2.12/elf/dynamic-link.h
# define _ELF_DYNAMIC_DO_RELOC(RELOC, reloc, map, do_lazy, test_rel) \
do { \
struct { ElfW(Addr) start, size; int lazy; } ranges[2]; \
ranges[0].lazy = 0; \
ranges[0].size = ranges[1].size = 0; \
ranges[0].start = 0; \
...
{ \
int ranges_index; \
for (ranges_index = 0; ranges_index < 2; ++ranges_index) \
elf_dynamic_do_##reloc ((map), \
ranges[ranges_index].start, \
ranges[ranges_index].size, \
ranges[ranges_index].lazy); \
} \
-----
Note that ranges[1].start never is initialized in dynamic-link.h,
while elf_dynamic_do_rel() computes the sum
const ElfW(Rel) *r = (const void *) reladdr;
const ElfW(Rel) *end = (const void *) (reladdr + relsize);
and then compares
for (; r < end; ++r)
which relies on
(uninit + 0) == the_same_uninit
Thus glibc violates the C standard, because an operation on an uninitialized
value is totally undefined. Memcheck complains correctly; glibc stubbornly
HAS REFUSED (!!!!!) the trivial fix "ranges[1].start = 0;" which costs *1* CPU cycle.
Glibc uses this code on all platforms, so why doesn't memcheck complain everywhere?
Actually memcheck does notice, but the default suppressions hide the complaint.
Why don't the default suppressions work here?
File valgrind/glibc-2.X.supp contains various suppressions such as:
{
dl-hack3-cond-0
Memcheck:Cond
fun:_dl_start
fun:_start
}
{
dl-hack3-cond-1
Memcheck:Cond
obj:*/lib*/ld-2.12*.so*
obj:*/lib*/ld-2.12*.so*
obj:*/lib*/ld-2.12*.so*
}
which suppress "Cond" complaints ("Conditional jump or move depends on uninitialised value(s)")
in the context of a particular traceback (_dl_start called from _start) or a pattern
of any three nested routines within ld-2.12*.so*.
THE PROBLEM with Angstrom ld-2.12.2.so is that there are so few symbols
that the traceback is only the *one* routine
==28151== at 0x400B308: ??? (in /lib/ld-2.12.2.so)
whose name memcheck does not know. [The only name that objdump discovers is
_dl_rtld_di_serinfo, which is highly suspect.] Thus the known suppressions
do not match the traceback.
Therefore Angstrom should provide better debugging info for developers.
[And glibc should fix its outright error.]
--
|
|
From: John R. <jr...@bi...> - 2013-06-05 17:57:23
|
> is it certain, based on what you've seen, that I actually am using the debug > package? I installed it, which apparently is all that is required to cause > it to get used when compiled for debugging? There is a chance of pathname mixup: installing into the "wrong" directory. The way to tell is to run valgrind under strace: $ strace -f -o strace.out -e trace=file ~/local/bin/valgrind --leak-check=yes ./clock_gettime CLOCK_MONOTONIC and afterwards look in strace.out for any open() on the debug symbol file(s). -- |
|
From: John R. <jr...@bi...> - 2013-06-05 19:09:44
|
>> is it certain, based on what you've seen, that I actually am using the debug >> package? I installed it, which apparently is all that is required to cause >> it to get used when compiled for debugging? > There is a chance of pathname mixup: installing into the "wrong" directory. > > The way to tell is to run valgrind under strace: > > $ strace -f -o strace.out -e trace=file ~/local/bin/valgrind --leak-check=yes ./clock_gettime CLOCK_MONOTONIC > > and afterwards look in strace.out for any open() on the debug symbol file(s). > Also try $ ~/local/bin/valgrind -d -d -d -v -v -v --leak-check=yes ./clock_gettime CLOCK_MONOTONIC and look for debug symbol loading such as: ----- --25057:1:main Load initial debug info --25057-- Reading syms from /usr/bin/date --25057-- svma 0x0000401ad0, avma 0x0000401ad0 --25057-- Considering /usr/lib/debug/.build-id/08/884e015589393715fa4c5d3e9a4ab0d1541e99.debug .. --25057-- .. build-id is valid ----- -- |
|
From: John R. <jr...@bi...> - 2013-06-22 00:10:14
|
> $ ~/local/bin/valgrind -d -d -d -v -v -v --leak-check=yes ./clock_gettime CLOCK_MONOTONIC
> It looks like this might be the problem. The only section I'm getting
> that starts with teh Load initial debug info looks like this:
>
> --1688:1:main Load initial debug info
> --1688-- Reading syms from /home/root/software/clock_gettime
> --1688-- svma 0x00000084ac, avma 0x00000084ac
> --1688-- Reading syms from /lib/ld-2.12.2.so
> --1688-- svma 0x0000000790, avma 0x0004000790
> --1688-- Considering /lib/ld-2.12.2.so ..
> --1688-- .. CRC mismatch (computed ebfc32b7 wanted 596e7f90)
> --1688-- Considering /lib/.debug/ld-2.12.2.so ..
> --1688-- .. CRC mismatch (computed 4cc18107 wanted 596e7f90)
> --1688-- object doesn't have a symbol table
>
> The open() syscalls in the strace out I got from the approach you
> described in your other email didn't seem like they were mentioning a
> debug library either (I've attached that output).
>
> The stuff in the debug output sounds like its saying the library is
> there but is corrupt (or possibly the wrong version or something)?
The correct debug info cannot be found. The first attempted location was inside
the ld-2.12.2.so itself:
> --1688-- Considering /lib/ld-2.12.2.so ..
> --1688-- .. CRC mismatch (computed ebfc32b7 wanted 596e7f90)
but the debuginfo was not there. (Perhaps it was empty, such as removed
by "strip" or "ld -S".)
The second attempted location was:
> --1688-- Considering /lib/.debug/ld-2.12.2.so ..
> --1688-- .. CRC mismatch (computed 4cc18107 wanted 596e7f90)
and that file does have debuginfo, but it does not match.
The third attempted location was (from the strace.out):
1412 open("/usr/lib/debug/lib/ld-2.12.2.so", O_RDONLY) = -1 ENOENT (No such file or directory)
but that file was not found.
So /lib/ld-2.12.2.so does not match /lib/.debug/ld-2.12.2.so.
Either the wrong version was installed in the first place, or an update
was performed on one file but not the other. Check the dates via "ls -l"
(and follow symlinks until you get to regular files.)
They should be close to each other: no more than about a minute apart.
Try a re-install of *both* files.
|
Thanks for helping keep SourceForge clean.
X