Re: Version mismatch libpthread/libthread_db [SOLVED]

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Jul 13, 2009 at 10:01 AM, Martin
Gebert<martin.gebert@alpha-bit.de> wrote:
>
>> This isn't the usual name for a native gdb, but as long as it's native
>> and you're on the target then you're OK.
>> [...]
>>
>> You are starting to confuse people here. Which gdb, cross-gdb running
>> on the host, or native-gdb examining the running gdbserver on the
>> target?
>>
>
> That may be because I'm confused myself about the meaning of "native" in
> this context. From the start: I use the above mentioned cross-compiled
> mipsel-linux-gnu-gdb which runs on my host/workstation and debugs the
> remote target's binaries via gdbserver on the target machine. Is that
> what you asked me to do? If not, what is the native gdb (BTW, using the
> hosts default gdb fails on "target remote ..." with an unknown
> architecture error)?

The mipsel-linux-gnu-gdb is not native because the host and the target
for that binary do not match i.e. host = Some x86 system, but target =
mipsel-linux-gnu.

The mipsel-linux-gnu-gdb is known as a cross gdb.

The native gdb would be a gdb running on the target, installed in the
targets root filesystem.

The native gdb on your host is built to debug some x86 system, and not
your target, which is why it gives an "unknown architecture error."

I suggest you read up on the differences between target, host, and
build systems, and what constitutes a cross or native configuration.

Read:
http://www.gnu.org/software/autoconf/manual/autoconf.html#Specifying-Names

and:
http://www.gnu.org/prep/standards/html_node/Configuration.html#Configuration

>> In general solib-absolute-prefix is only used if you have a multiple
>> sets of libraries on the host and you want the cross-gdb to select a
>> different set to debug with.
>>
>
> Well, in the end that's what seemed to be causing my problems, if I
> understood you and Ryan correctly? Namely that the cross-gdb was
> searching for the shared libraries in the hosts root dir instead of the
> target's libs that have been used by cross-gcc/ld, finding a libc and
> libpthread that didn't match the target files and therefor the version
> check and even stepping over calls into libc failed.



> Currently it looks
> like setting solib-absolute-prefix, or better yet using the correct
> --with-sysroot in configure (which somehow was left out from cross-gdb
> configuration, as I figured out this afternoon) solves my problem entirely.

Upstream gdb should support "set sysroot" and you should use that.

(gdb) help set sysroot
Set an alternate system root.
The system root is used to load absolute shared library symbol files.
For other (relative) files, you can add directories using
`set solib-search-path'.

> So I would like to apologize for the fuss, which in the end seems to be
> a GDB configuration problem. I simply wasn't able to connect the version
> mismatch error showing up on the target with a possible problem in the
> cross-gdb setup on my workstation, and was looking for the solution in
> libc's configuration. (Who would have thought that apparently the
> cross-gdb sends the version of the libpthread found locally to
> gdbserver, so it is compared and reclaimed on the target?) Thanks to
> Carlos, Ryan and Mike for taking the time, providing me useful hints and
> increasing my know-how!

Yes, this is a common gdb error which looks like a library problem.
GDB tries hard to make sure things match, but in the end, it does give
you flexibility.

Cheers,
Carlos.